https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #20 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Rainer Orth from comment #17)
> (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
I'd like to propose an alternative patch. The testsuite harness should simply
ask libstdc++ for correct include paths, like in the to be attached patch.
(This is how libstdc++ testsuite determines correct include flags.)
