http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-04 13:56:30 UTC --- > --- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 > 20:49:52 UTC --- > Actually, my previous successful bootstrap was for rev 180770. I happened to > catch you in the middle of your checkins, but before the libgcc changes. > > http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00246.html > > That was successful, so it either must be do to your patch or a later change. The following changes seem innocent to me, so this makes it highly probably that my gthr patch is the culprit, too. Which rev was the first one to fail bootstrap for you? > Is there some logic about which include directories implicitly are C++ vs C > header files? It now is finding gthr.h, gthr-default.h and gthr-posix.h in > libstdc++ include/bits. libstdc++ needs the ones in include/<target>/bits, for they are slighly mangled copies of the libgcc ones. The C files live either below $srcdir/libgcc, and those runtime libs that need them were modified to add appropriate -I flags, or in $objdir/<target>/libgcc (for gthr-default.h). I think we need to start from the beginning: * include/<target>/bits/gthr-default.h should be a modified copy of gthr-aix.h, right? * What's the exact command line for the failing atomic.cc compile? In particular, is -pthread included? That would lead to gthr-default.h including gthr-posix.h, which again includes <pthread.h>. * Perhaps repeat the command with -g3 -save-temps and check for a pthread_once declaration. * If I were to debug this myself, the quickest way (given enough CPU power) is usually to have a succeeding and failing build in parallel and compare command lines and -g3 -save-temps output. Rainer