[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

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