#include <iostream>
#include <cilk/cilk.h>
int fib(int n)
{
if (n < 2)
return n;
int x = cilk_spawn fib(n-1);
int y = fib(n-2);
cilk_sync;
return x + y;
}
int main(int argc, char ** argv)
{
for (int i = 0; i != 20; ++i)
{
std::cout << "fib(i)=" << fib(i) << std::endl;
}
}
compiled like so can't find the library
$ g++ -Wall -O3 -fcilkplus fib.cpp -o fib
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: cannot find -lcilkrts
collect2: error: ld returned 1 exit status
So I try find and adding it with the -L switch
$ find /opt/rh/devtoolset-4 -name "cilkrts"
/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32/libcilkrts.a
/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32/libcilkrts.so
/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/libcilkrts.spec
$ g++ -Wall -O3 -fcilkplus fib.cpp -o fib -L/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: skipping incompatible /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32/libstdc++.so when searching for -lstdc++
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: skipping incompatible /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32/libcilkrts.so when searching for -lcilkrts
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: cannot find -lcilkrts
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: skipping incompatible /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32/libgcc_s.so when searching for -lgcc_s
/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/ld: skipping incompatible /opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.2.1/32/libgcc.a when searching for libgcc.a
collect2: error: ld returned 1 exit status
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-4/root/usr/libexec/gcc/x86_64-redhat-linux/5.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-4/root/usr --mandir=/opt/rh/devtoolset-4/root/usr/share/man --infodir=/opt/rh/devtoolset-4/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-5.2.1-20150902/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.2.1 20150902 (Red Hat 5.2.1-2) (GCC)
Pointers appreciated
If I asked it I guess I should post the answer when I work it out:
sudo yum install devtoolset-4-libcilkrts-devel
is the missing piece.
Related
I'm testing the following piece of code
#include <string>
int main(int argc, const char *argv[])
{
const size_t size = strtoull(argv[1], nullptr, 10);
for (int i = 0; i < 100000000; ++i)
{
std::string str;
str.reserve(size);
for (size_t j = 0; j < size; ++j)
{
str += 'x';
}
}
return 0;
}
I compile it with -O3
g++ string-append.cpp -O3 -o string-append
Now when running with parameter 15 the program appears slower then when running with parameter 16.
$ time ./string-append 15
real 0m4.342s
user 0m4.342s
sys 0m0.000s
$ time ./string-append 16
real 0m3.112s
user 0m3.112s
sys 0m0.000s
I have verified with valgrind that:
15: no allocations for the string
16: 100M allocations and 100M deallocations
Using printouts I verified that:
15: str.c_str() returns always the same address
16: str.c_str() returns different address every time
Using perf I verified that 16 gives more:
L1 cache loads
L1 cache stores
L1 cache misses
branches
branches misses
instructions (almost twice more)
What is the reason that the code works faster for size 16?
Compiler is gcc version 9.4.0.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
Checked on Clang13 - it does not seem to have this problem.
I try to compile this code from cppreference.com:
#include <iostream>
#include <tuple>
#include <utility>
int add(int first, int second) { return first + second; }
template<typename T>
T add_generic(T first, T second) { return first + second; }
auto add_lambda = [](auto first, auto second) { return first + second; };
int main()
{
// OK
std::cout << std::apply(add, std::make_pair(1, 2)) << '\n';
// Error: can't deduce the function type
// std::cout << std::apply(add_generic, std::make_pair(2.0f, 3.0f)) << '\n';
// OK
std::cout << std::apply(add_lambda, std::make_pair(2.0f, 3.0f)) << '\n';
}
And I get this error:
toy.cpp: In function ‘int main()’:
toy.cpp:15:18: error: ‘apply’ is not a member of ‘std’
std::cout << std::apply(add, std::make_pair(1, 2)) << '\n';
^~~
toy.cpp:21:18: error: ‘apply’ is not a member of ‘std’
std::cout << std::apply(add_lambda, std::make_pair(2.0f, 3.0f)) << '\n';
I compile with this command:
g++ -std=c++17 toy.cpp -o toy
Here is my version of g++:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
I also tried with clang but I have the same error. My version of clang is:
clang version 8.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /etc/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.3.0
Candidate multilib: .;#m64
Candidate multilib: 32;#m32
Candidate multilib: x32;#mx32
Selected multilib: .;#m64
What is the problem?
You have to upgrade your G++ compiler to at least 7 version, or use
#include <experimental/tuple>
then call
std::cout << std::experimental::apply(add, std::make_pair(1, 2)) << '\n';
Live
#include <functional>
#include <stdio.h>
int main()
{
std::function<void(int)> func;
int capture = 1234;
printf("outside capture=%d\n", capture);
if (capture) {
func =
[capture](int x) {
printf("inside capture=%d\n", capture);
};
func(0);
}
}
Compile (with -Os, -O2 or -O3) and execute it, result is
outside capture=1234
inside capture=67213
Compile with -O1 or without -O?, the result is (this is what I expect)
outside capture=1234
inside capture=1234
Is there any thing wrong? I doubt this is compiler or C++ standard library bug.
Could you give me some comments?
$ gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/opt/arm/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/6.1.1/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/snapshots/gcc-linaro-6.1-2016.08/configure SHELL=/bin/bash --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap --with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-c99 --enable-gnu-indirect-function --with-tune=cortex-a9 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-multilib --enable-multiarch --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/sysroots/arm-linux-gnueabihf --enable-lto --enable-linker-build-id --enable-long-long --enable-shared --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran,lto --enable-checking=release --disable-bootstrap --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu
Thread model: posix
gcc version 6.1.1 20160711 (Linaro GCC 6.1-2016.08)
This issue also can be verified on x86_64 by following shell commands
sudo apt-get -y install qemu-user
wget https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/arm-linux-gnueabihf/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz
tar -xf gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz
cat <<EOF > test.cpp
#include <functional>
#include <stdio.h>
int main()
{
std::function<void(int)> func;
int capture = 1234;
printf("outside capture=%d\n", capture);
if (capture) {
func =
[capture](int x) {
printf("inside capture=%d\n", capture);
};
func(0);
}
}
EOF
gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -Os test.cpp
qemu-arm gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/ld-linux-armhf.so.3 --library-path gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib ./a.out
The result is
outside capture=1234
inside capture=-161318064
#include <leveldb/status.h>
#include <leveldb/db.h>
#include <leveldb/write_batch.h>
...
int arg_offset = 0;
leveldb::DB* db1;
leveldb::Options options;
options.error_if_exists = true;
options.create_if_missing = true;
options.write_buffer_size = 268435456;
leveldb::WriteBatch* batch;
...
if (db_backend == "leveldb")
{
// leveldb
LOG(INFO) << "Opening leveldb " << argv[arg_offset+2];
leveldb::Status status1 = leveldb::DB::Open(options, argv[arg_offset+2], &db1);
CHECK(status1.ok()) << "Failed to open leveldb " << argv[arg_offset+2];
batch = new leveldb::WriteBatch();
}
The above code snippet generates the following errors
$ g++ tools/convert_imageset_and_disparity.cpp -MMD -MP -pthread -fPIC -DCAFFE_VERSION=1.0.0-rc5 -DNDEBUG -O2 -DUSE_OPENCV -DUSE_LEVELDB -DUSE_LMDB -DWITH_PYTHON_LAYER -I/usr/include/python3.5m -I/usr/lib/python3.5/dist-packages/numpy/core/include -I/usr/local/include -I/usr/include/hdf5/serial -I/usr/include -I.build_release/src -I./src -I./include -I/usr/local/cuda-9.0/include -Wall -Wno-sign-compare -c -o .build_release/tools/convert_imageset_and_disparity.o 2> .build_release/tools/convert_imageset_and_disparity.o.warnings.txt \
|| (cat .build_release/tools/convert_imageset_and_disparity.o.warnings.txt; exit 1)
error: expected unqualified-id before ‘int’
leveldb::Status status1 = leveldb::DB::Open(options, argv[arg_offset+2], &db1);
-----------------^
error: ‘status1’ was not declared in this scope
CHECK(status1.ok()) << "Failed to open leveldb " << argv[arg_offset+2];
---------------^
Compiler version :
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
LevelDB is installed using sudo apt-get install libleveldb-dev
The same library is compiling a similar call to leveldb in another cpp file and it gets compiled successfully
void LevelDB::Open(const string& source, Mode mode) {
leveldb::Options options;
options.block_size = 65536;
options.write_buffer_size = 268435456;
options.max_open_files = 100;
options.error_if_exists = mode == NEW;
options.create_if_missing = mode != READ;
leveldb::Status status = leveldb::DB::Open(options, source, &db_);
CHECK(status.ok()) << "Failed to open leveldb " << source
<< std::endl << status.ToString();
LOG(INFO) << "Opened leveldb " << source;
}
Can someone help me to debug this error: expected unqualified-id ?
An excellent tutorial on How to use LevelDB is listed here.
Finally I was able to (atleast) resolve the compilation error. Here are the changes that I made:
changed leveldb::Status status1 = leveldb::DB::Open(options, argv[arg_offset+2], &db1) to auto status1 = leveldb::DB::Open(options, argv[arg_offset+2], &db1) Thanks #ZivS for pointing it out.
changed Makefile from LIBRARIES += glog gflags protobuf leveldb snappy \
lmdb boost_system boost_filesystem hdf5_hl hdf5 m \
opencv_core opencv_highgui opencv_imgproc opencv_imgcodecs opencv_videoio to LIBRARIES += glog gflags protobuf leveldb snappy \
lmdb boost_system boost_filesystem hdf5_hl hdf5 m \
opencv_core opencv_highgui opencv_imgproc opencv_imgcodecs opencv_videoio X11
Then finally compiled with -std=c++11 flag
The code was able to compile. Will update once I load the LevelDB using the built object.
Edit 2 Compiled code is running successfully.
I noted that a regular expression, containing two patterns with OR condition, do not match a sample string if the first pattern is a beginning part of the second pattern (tested on clang 3.5 and clang 3.8):
std::regex_match("ab", std::regex("(ab|a)")) == true
but
std::regex_match("ab", std::regex("(a|ab)")) == false
I think true is logically correct in both cases.
Clang & OSX:
$ cat > test.cpp
#include <string>
#include <regex>
#include <iostream>
int main() {
std::cout << std::regex_match("ab", std::regex("(a|ab)")) << std::endl;
std::cout << std::regex_match("ab", std::regex("(ab|a)")) << std::endl;
return 0;
}
^C
$ clang++ -v
Apple LLVM version 8.1.0 (clang-802.0.41)
Target: x86_64-apple-darwin16.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ clang++ ./test.cpp -o test
$ ./test
0
1
Clang & FreeBSD:
$ cat > test.cpp
#include <string>
#include <regex>
#include <iostream>
int main() {
std::cout << std::regex_match("ab", std::regex("(a|ab)")) << std::endl;
std::cout << std::regex_match("ab", std::regex("(ab|a)")) << std::endl;
return 0;
}
^C
$ clang++ -v
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
$ clang++ ./test.cpp -o test
$ ./test
0
1
Linux & GCC:
$ cat > test.cpp
#include <string>
#include <regex>
#include <iostream>
int main() {
std::cout << std::regex_match("ab", std::regex("(a|ab)")) << std::endl;
std::cout << std::regex_match("ab", std::regex("(ab|a)")) << std::endl;
return 0;
}
^C
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.1-2ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.1 20160904 (Ubuntu 5.4.1-2ubuntu1~16.04)
$ g++ -std=gnu++11 ./test.cpp -o test
$ ./test
1
1
ECMAScript (the default regex syntax) attempts to match the alternatives in order, stopping at the first success, which means that in ordinary searching (a la regex_search) the regex a|ab never matches the whole ab; it always matches just the a part.
The standard was ambiguous about what regex_match was supposed to do in this case, leading to implementation divergence. See LWG issue 2273 for the competing interpretations. Eventually the standard was amended (see the resolution of that issue) to make clear that regex_match only considers potential matches that match the entire input sequence, as the example added to the standard makes clear:
std::regex re("Get|GetValue");
std::cmatch m;
regex_search("GetValue", m, re); // returns true, and m[0] contains "Get"
regex_match ("GetValue", m, re); // returns true, and m[0] contains "GetValue"
The original <regex> implementation in libc++ used the other interpretation, however, and it simply wasn't updated to match the resolution until recently. Clang 4.0 now prints 1 1.