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).
