https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #17 from Rainer Orth <ro at gcc dot gnu.org> --- (In reply to Iain Buclaw from comment #6) [...] > > Running target unix > > FAIL: runnable/cppa.d execution test > > FAIL: runnable/cppa.d -g execution test > > FAIL: runnable/cppa.d -g -shared-libphobos execution test > > FAIL: runnable/cppa.d -shared-libphobos execution test > > Have now reproduced, the test checks old behaviour that I dropped support > for long ago. The first failed attempt to have a type that maps to C 'long' > and 'unsigned long' had a 'struct __c_long' type that expected the compiler > to magically pass it around as the correct integer type. This had > passed/gone unnoticed on x86_64 because 'struct{long}' and 'long' are passed > in the same way. > > Support should have been removed from the dmd front-end when it was dropped > from the library, but it still lives on in the testsuite. I'm seeing the same not only on Linux/x86_64, but also on Solaris/x86, only for the non-default multilib. The failure is the same however: In file included from runnable/extra-files/cppb.cpp:36:^M /vol/gcc/src/hg/trunk/dist/gcc/testsuite/../../libstdc++-v3/libsupc++/exception:37:10: fatal error: bits/c++config.h: No such file or directory^M Looking at the -I flags passed, it's obvious that they are wrong: on Linux/x86_64 there is -I/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/x86_64-pc-linux-gnu/32/libstdc++-v3/include/32 while on Solaris/x86 it's -I/var/gcc/regression/trunk/11.3-gcc-gas/build/i386-pc-solaris2.11/amd64/libstdc++-v3/include/amd64 neither of which exist: the last component should be $target_triplet instead of $target. Fixing this as in the attached patch lets the test PASS for me on both x86_64-pc-linux-gnu and i386-pc-solaris2.11 (32 and 64-bit each).