Did you build in a clean directory?  How did you configure GCC and how did you invoke make?

libgomp should not be a target library in stage2 anyways.

The only configure option was --enable-languages=c,c++,fortran.  The configure and build were done in a clean, empty directory.  Make was invoked with "make -j4".

I have seen that also (the first time at revision 156585). In these cases I clean the directory and restart.
Note that I used 'make -j3' on a Core2 Duo, but switching to '-j2' did not help.

> libgomp should not be a target library in stage2 anyways.

I see

[macbook] gcc/build_w% lf prev-x86_64-apple-darwin10/
i386/  libgcc/  libgomp/

So apparently libgomp is built during stage 2.

Although this pr report a problem for parallel make without install it may be a duplicate of pr38388.
See also http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01236.html .

(In reply to comment #4)
> Although this pr report a problem for parallel make without install it may be a
> duplicate of pr38388.

That seems unlikely to me.  The cited PR does not change nor concern 'make all' semantics.  It would however be interesting to know whether this PR is reproducible with parallel make only.

Building libgomp in earlier stages was done for PR 36101 and PR 42813.

> It would however be interesting to know whether this PR is
> reproducible with parallel make only.

Indeed, but so far it is not (see comment #3). Do you have any idea of what I could do to make it reproducible?

(In reply to comment #6)
> > It would however be interesting to know whether this PR is
> > reproducible with parallel make only.
> 
> Indeed, but so far it is not (see comment #3).

What does your reply mean?  Does it mean "the comparison error is reproducible only when I use parallel make"?  Or does it mean "the comparison error is not reproducible with non-parallel make"?  Or do you make a statement about non-reproducibility of some sort?  These statements are all different, and comment #3 does not state anything that I can make sense of, except that the error has been seen to happen with both -j3 and with -j2.

Please do not answer with yes or no, make it easy for readers to follow you by formulating a full sentence statement as to what you mean.  Thank you.

(In reply to comment #7)
> Please do not answer with yes or no, make it easy for readers to follow you by
> formulating a full sentence statement as to what you mean.  Thank you.

On a Core2 Duo (x86_64-apple-darwin10), I see the libgomp comparison fails in a no reproducible way with both -j2 and -j3 (probability since the first occurrence at r 156585: 4 times for 9 full bootstraps). I have never seen this failure appearing twice in a raw, i.e., cleaning the build directory and restarting the bootstrap has always worked.

On a monoprocessor G5 (powerpc-apple-darwin9) on which I always do a non parallel build, I have never seen a libgomp comparison failure.

(In reply to comment #8)
> On a Core2 Duo (x86_64-apple-darwin10), I see the libgomp comparison fails in a
> no reproducible way with both -j2 and -j3 (probability since the first
> occurrence at r 156585: 4 times for 9 full bootstraps). I have never seen this
> failure appearing twice in a raw, i.e., cleaning the build directory and
> restarting the bootstrap has always worked.
> 
> On a monoprocessor G5 (powerpc-apple-darwin9) on which I always do a non
> parallel build, I have never seen a libgomp comparison failure.

Thank you, very well.  Can you (or somebody else who sees the failure with -jN, N>1) try a bootstrap on x86_64-apple-darwin10 with non-parallel make from a clean directory?

If that fails, that would be a pretty clear indication that this bug has nothing to do with make parallelism.  (There are lots of other reasons why bootstrap comparisons can fail, some of which are quite system-dependent, so a builds on darwin9 and on darwin10 may not both expose the issue.)

(In reply to comment #8)
> Thank you, very well.  Can you (or somebody else who sees the failure with -jN,
> N>1) try a bootstrap on x86_64-apple-darwin10 with non-parallel make from a
> clean directory?

I don't understand what you are expecting. Since the parallel bootstrap works most of the time, why are you expecting the non-parallel one to always fail? It seems to me highly unlikely. Note that a bootstrap with only gcc and gfortran takes about 1 hour in parallel, so probably ~2 hours in non-parallel.

I just completed successfully a clean non-parallel bootstrap at revision 157122 with

../p_work/configure --prefix=/opt/gcc/gcc4.5p --mandir=/opt/gcc/gcc4.5p/share/man --infodir=/opt/gcc/gcc4.5p/share/info --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 --enable-languages=c,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64

Thanks.  You are right that the chance for a non-parallelism-related failure was low, but comparison failures can be due to the phase of the moon literally.

Anyway, here's how I usually debug parallel build failures: rebuild until you have both a successful and failed build, moving prior build trees away like:
  for i in 1 2 3 4; do
    mv build build-$i && mkdir build && cd build &&
    ../gcc/configure ... && make -jN
  done

That way one can compare the trees afterward without spurious path name diffs.

Compare the contents of build-$i/stage-{1,2,3}-$host/libgomp with that of a bad build and in between the three stages.  Esp. the libgomp/.deps subdirs and the config.log and config.status files.  Chances are you will find suspect issues even when looking only at those of the different stages of a single build.

If that all doesn't lead anywhere, then posting the output from a failed build would be a good idea.  Sorry I can't help better.

I just got the failure today at revision 157401 on x86_64-apple-darwin10. I have saved the build directory and restarted for a successful bootstrap. Comparing the config.log files in x86_64-apple-darwin10/i386/libgomp/config.log and _fail/stage3-x86_64-apple-darwin10/i386/libgomp/config.log, I see

...
 configure:15406: $? = 0
 configure:15406: ./conftest
-configure:15406: $? = 0
-configure:15426: result: yes
+configure:15406: $? = 1
+configure: program exited with status 1
+configure: failed program was:
+| /* confdefs.h */
+| #define PACKAGE_NAME "GNU OpenMP Runtime Library"
+| #define PACKAGE_TARNAME "libgomp"
+| #define PACKAGE_VERSION "1.0"
+| #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0"
+| #define PACKAGE_BUGREPORT ""
+| #define PACKAGE_URL "http://www.gnu.org/software/libgomp/"
+| #define PACKAGE "libgomp"
+| #define VERSION "1.0"
+| #define STDC_HEADERS 1
+| #define HAVE_SYS_TYPES_H 1
+| #define HAVE_SYS_STAT_H 1
+| #define HAVE_STDLIB_H 1
+| #define HAVE_STRING_H 1
+| #define HAVE_MEMORY_H 1
+| #define HAVE_STRINGS_H 1
+| #define HAVE_INTTYPES_H 1
+| #define HAVE_STDINT_H 1
+| #define HAVE_UNISTD_H 1
+| #define HAVE_DLFCN_H 1
+| #define LT_OBJDIR ".libs/"
+| #define STDC_HEADERS 1
+| #define TIME_WITH_SYS_TIME 1
+| #define STRING_WITH_STRINGS 1
+| #define HAVE_UNISTD_H 1
+| #define HAVE_SEMAPHORE_H 1
+| #define HAVE_SYS_TIME_H 1
+| #define HAVE_SYS_TIME_H 1
+| #define HAVE_GETLOADAVG 1
+| #define HAVE_STRTOULL 1
+| #define HAVE_BROKEN_POSIX_SEMAPHORES 1
+| /* end confdefs.h.  */
+| #include <pthread.h>
+| 		__thread int a;
+| 		static int *a_in_other_thread;
+| 		static void *
+| 		thread_func (void *arg)
+| 		{
+| 		  a_in_other_thread = &a;
+| 		  return (void *)0;
+| 		}
+| int
+| main ()
+| {
+| pthread_t thread;
+| 		void *thread_retval;
+| 		int *a_in_main_thread;
+| 		if (pthread_create (&thread, (pthread_attr_t *)0,
+| 				    thread_func, (void *)0))
+| 		  return 0;
+| 		a_in_main_thread = &a;
+| 		if (pthread_join (thread, &thread_retval))
+| 		  return 0;
+| 		return (a_in_other_thread == a_in_main_thread);
+|   ;
+|   return 0;
+| }
+configure:15426: result: no
 configure:15436: checking whether the target supports hidden visibility
...

Note that I do not see that in the comparison with _fail/stage2-x86_64-apple-darwin10/i386/libgomp/config.log.

Thanks.  Is /usr/include/pthread.h or one of the headers it includes matched by a fixincludes rule?  I.e., does any of {stage{1,2,3}-,prev-,}gcc/include/fixed contain pthread.h or included headers, and if yes, what is their diff to their counterpart in /usr/include?

Another, but fairly unlikely, reason for an unstable test result could be that pthread_create fails due to exhausted resources.  Which was the log file in which the configure test failed?  Was it in the successful build?

(In reply to comment #14)
> a fixincludes rule?  I.e., does any of {stage{1,2,3}-,prev-,}gcc/include/fixed

That should be include-fixed at the end there.

>  Is /usr/include/pthread.h or one of the headers it includes matched by
> a fixincludes rule?  I.e., does any of {stage{1,2,3}-,prev-,}gcc/include/fixed
> contain pthread.h or included headers, and if yes, what is their diff to their
> counterpart in /usr/include?

As far as I can tell the answer is "NO".

> Another, but fairly unlikely, reason for an unstable test result could be that
> pthread_create fails due to exhausted resources.  

It may be a possibility: I had several applications opened (Mathematica, Safari, ...). Although they were in an "idle" state, they were using some RAM: several 100Mb out of 4Gb.

> Which was the log file in which the configure test failed?
>  Was it in the successful build?

The config failure was for the failing build. Looking at the log again, I noticed that the successful log contained several '#define HAVE_TLS 1' (6 occurrences) while there are none in the log for the failing build. I remember having seen some fix for tls issues on darwin, but I cannot find the relevant PR.

pr43761 is a duplicate of this one.

*** Bug 43761 has been marked as a duplicate of this bug. ***

On Apr 15, 2010, at 6:15 PM, dominiq at lps dot ens dot fr wrote:



>------- Comment #1 from dominiq at lps dot ens dot fr  2010-04-15 22:15 -------
>This is a duplicate of pr43170.

>A couple of questions:

>(1) have you use the terminal for a long time with multiple windows/tabs?

>(2) can you test gcc.c-torture/compile/limits-structnest.c  -O2? It should take
>a few seconds. If not, abort it after a couple minutes.

>(3) are you using Mathematica?

>The reasons of these questions, is that my macbook ended in a curious state in
>which gcc.c-torture/compile/limits-structnest.c was timed out while regtesting
>and I had several comparison failures for libgomp. All these disappeared when I
>had to reboot after the last security patches.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43761

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
You reported the bug, or are watching the reporter.

1)  I was using a fresh terminal session -- with path set to avoid my gcc build in /usr/local.  
3)  I do not have mathematica loaded on my systems.  I have a number of other packages, but most of them load their libraries in /usr/local  However, some of them were loaded from .dmgs so may have put other libraries in inconvenient places.  Examples include MySQL, R, etc.  I have a build of gsl, but know for sure this is in /usr/local.  I have not checked everything.

2)  Your path for item 2 was not complete: it was found in gcc-4.5.0/gcc/testsuite.  I tried to compile this into an executable using Apples native gcc, with optimization level -O2.  I completed quickly, but no main.  The calling routine appears associated with version crt1.10.6.o.


platt@mastodon.local:/Users/platt/install/GccSources/gcc-4.5.0/gcc/testsuite/gcc.c-torture/compile $ gcc -o xx -O2 limits-structnest.c 
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
platt@mastodon.local:/Users/platt/install/GccSources/gcc-4.5.0/gcc/testsuite/gcc.c-torture/compile $ 


Best,
Dan

PS> This will block any direct or first attempt to build gcc by Mac owners unless they try builds of intermediate versions of gcc.

(In reply to comment #20)
> PS> This will block any direct or first attempt to build gcc by Mac owners
> unless they try builds of intermediate versions of gcc.

A bootstrap comparison failure can easily be worked around by specifying --disable-bootstrap at configure time.

Subject: Re:  gcc 4.5 20100218 bootstrap compare fails on os x 10.6

At least I'll have a build, but no verification that at least the code I've written is expressed the same way as it would be if the build were made on another machine from a different version of gcc?

Best,
Dan




On Apr 16, 2010, at 1:17 AM, rwild at gcc dot gnu dot org wrote:

> 
> 
> ------- Comment #21 from rwild at gcc dot gnu dot org  2010-04-16 05:17 -------
> (In reply to comment #20)
>> PS> This will block any direct or first attempt to build gcc by Mac owners
>> unless they try builds of intermediate versions of gcc.
> 
> A bootstrap comparison failure can easily be worked around by specifying
> --disable-bootstrap at configure time.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

> PS> This will block any direct or first attempt to build gcc by Mac owners
> unless they try builds of intermediate versions of gcc.

Except for the "funny" state of my macbook before my last reboot, the failure is quite exceptional. My usual strategy, is to restart from a clean directory (the only time I have had two consecutive failures I removed the libgomp dirs in stage2 and 3 for both 32 and 64 bit modes and restarted from that state and it worked, modulo the "funny" state it regtested fine).

One possible temporary fix would be to retry the failing test while configuring libgomp.

Last thing I have forgotten to ask. Many failures occured while having Safari open and may browsing pages using Flash (I got intermittent messages asking to close Flash because it slows down the system).

Subject: Re:  gcc 4.5 20100218 bootstrap compare fails on os x 10.6

In this case, I have found the bug consistently repeatable on multiple machines, all running snow leopard up-to-date.  When built on my desk-top machine there were no other applications running except for "TeamViewer" (I built it from work).  The other builds were made without TeamViewer.  Browsers on/off, doesn't matter.

I *have* a build that works -- I built it with gcc-4.4.3 with no problem.  The difficulty is with Apple's gcc distribution.  As I pointed out earlier, I'd be struggling if I didn't have a new version of gcc on-board.  The only thing I did not try is to see if I used a gcc-4.5.0 build with --disable-bootstrap from Apple's gcc to rebuild gcc-4.5.0 with itself...  Even then, I'd be somewhat worried that the then consistent compiler might be producing code at variance with builds on other operating systems yielding inexplicable bugs or bugs that other people could not reproduce on their platforms.

Best,
Dan




On Apr 16, 2010, at 8:07 AM, dominiq at lps dot ens dot fr wrote:

> 
> 
> ------- Comment #23 from dominiq at lps dot ens dot fr  2010-04-16 12:07 -------
>> PS> This will block any direct or first attempt to build gcc by Mac owners
>> unless they try builds of intermediate versions of gcc.
> 
> Except for the "funny" state of my macbook before my last reboot, the failure
> is quite exceptional. My usual strategy, is to restart from a clean directory
> (the only time I have had two consecutive failures I removed the libgomp dirs
> in stage2 and 3 for both 32 and 64 bit modes and restarted from that state and
> it worked, modulo the "funny" state it regtested fine).
> 
> One possible temporary fix would be to retry the failing test while configuring
> libgomp.
> 
> Last thing I have forgotten to ask. Many failures occured while having Safari
> open and may browsing pages using Flash (I got intermittent messages asking to
> close Flash because it slows down the system).
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

Could you try installing fink and then the gcc44 package (which will build itself first). If this issue were really widespread, I would have had a ton of bug reports for that package. Fink may give you some clue as to what to astray on your Mac OS X installation. The only thing we run into on fink with the gcc4x packages is when users have extra installation of gmp, etc installed in /usr/local or MacPorts also installed.

First a Note for Ralf Wildenhues: I have seen somewhere that libgomp have been added to stage2 starting from some revision, but I am unable to find where. Do you have a better memory?
I think it is after 4.4 (so nothing can be infered from building 4.4.x).

> In this case, I have found the bug consistently repeatable on multiple
> machines, all running snow leopard up-to-date.  When built on my desk-top
> machine there were no other applications running except for "TeamViewer" (I
> built it from work).  The other builds were made without TeamViewer.  Browsers
> on/off, doesn't matter.

Can you 

(1) check that your builds fail as reported in comment #13 (you have to check
stageX-x86_64-apple-darwin10/YYY/libgomp/config.log with X in 2 or 3 and YYY in . or i386 assuming you build for x86_64-apple-darwin10)?

(2) provide your full configure line?

> I *have* a build that works -- I built it with gcc-4.4.3 with no problem.  The
> difficulty is with Apple's gcc distribution.  As I pointed out earlier, I'd be
> struggling if I didn't have a new version of gcc on-board.  The only thing I
> did not try is to see if I used a gcc-4.5.0 build with --disable-bootstrap from
> Apple's gcc to rebuild gcc-4.5.0 with itself...  Even then, I'd be somewhat
> worried that the then consistent compiler might be producing code at variance
> with builds on other operating systems yielding inexplicable bugs or bugs that
> other people could not reproduce on their platforms.

In my builds stage1 use Apple stock gcc: gcc version 4.2.1 (Apple Inc. build 5659).
The only way I know that can convince anybody that the build is sane is to run make check for 32 and 64 bit modes (though it's certainly not a proof!-).

Subject: Re:  gcc 4.5 20100218 bootstrap compare fails on os x 10.6



Answer to 2: /Users/platt/install/GccSources/gcc-4.5.0.build2 $ ../gcc-4.5.0/configure --enable-languages=c,c++,objc,obj-c++,fortran

Answer to 1: Configure line reported in stage 3/gomp (I'll try attaching the file and see if the post takes it).

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU OpenMP Runtime Library configure 1.0, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ../../../../gcc-4.5.0/libgomp/configure --with-multisubdir=i386 --with-multisrctop= --enable-multilib --cache-file=./config.cache --enable-multilib --enable-languages=c,c++,fortran,objc,obj-c++ --program-transform-name=s,y,y, --disable-option-checking --with-target-subdir=x86_64-apple-darwin10.3.0 --build=x86_64-apple-darwin10.3.0 --host=x86_64-apple-darwin10.3.0 --target=x86_64-apple-darwin10.3.0 --srcdir=../../../gcc-4.5.0/libgomp --with-build-libsubdir=. build_alias=x86_64-apple-darwin10.3.0 host_alias=x86_64-apple-darwin10.3.0 target_alias=x86_64-apple-darwin10.3.0 CPPFLAGS= LDFLAGS= CC=/Users/platt/install/GccSources/gcc-4.5.0.build2/./gcc/xgcc -B/Users/platt/install/GccSources/gcc-4.5.0.build2/./gcc/ -B/usr/local/x86_64-apple-darwin10.3.0/bin/ -B/usr/local/x86_64-apple-darwin10.3.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.3.0/include -isystem /usr/local/x86_64-apple-darwin10.3.0/sys-include  -m32 CXX=/Users/platt/install/GccSources/gcc-4.5.0.build2/./gcc/g++ -B/Users/platt/install/GccSources/gcc-4.5.0.build2/./gcc/ -nostdinc++ -L/Users/platt/install/GccSources/gcc-4.5.0.build2/x86_64-apple-darwin10.3.0/i386/libstdc++-v3/src -L/Users/platt/install/GccSources/gcc-4.5.0.build2/x86_64-apple-darwin10.3.0/i386/libstdc++-v3/src/.libs -B/usr/local/x86_64-apple-darwin10.3.0/bin/ -B/usr/local/x86_64-apple-darwin10.3.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.3.0/include -isystem /usr/local/x86_64-apple-darwin10.3.0/sys-include  -m32 F77= -m32 GCJ=-B/usr/local/x86_64-apple-darwin10.3.0/bin/ -B/usr/local/x86_64-apple-darwin10.3.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.3.0/include -isystem /usr/local/x86_64-apple-darwin10.3.0/sys-include  -m32 GFORTRAN=/Users/platt/install/GccSources/gcc-4.5.0.build2/./gcc/gfortran -B/Users/platt/install/GccSources/gcc-4.5.0.build2/./gcc/ -B/usr/local/x86_64-apple-darwin10.3.0/bin/ -B/usr/local/x86_64-apple-darwin10.3.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.3.0/include -isystem /usr/local/x86_64-apple-darwin10.3.0/sys-include  -m32 -srcdir=../../../../gcc-4.5.0/libgomp

Best,
Dan




On Apr 16, 2010, at 10:34 AM, dominiq at lps dot ens dot fr wrote:

> 
> 
> ------- Comment #26 from dominiq at lps dot ens dot fr  2010-04-16 14:34 -------
> First a Note for Ralf Wildenhues: I have seen somewhere that libgomp have been
> added to stage2 starting from some revision, but I am unable to find where. Do
> you have a better memory?
> I think it is after 4.4 (so nothing can be infered from building 4.4.x).
> 
>> In this case, I have found the bug consistently repeatable on multiple
>> machines, all running snow leopard up-to-date.  When built on my desk-top
>> machine there were no other applications running except for "TeamViewer" (I
>> built it from work).  The other builds were made without TeamViewer.  Browsers
>> on/off, doesn't matter.
> 
> Can you 
> 
> (1) check that your builds fail as reported in comment #13 (you have to check
> stageX-x86_64-apple-darwin10/YYY/libgomp/config.log with X in 2 or 3 and YYY in
> . or i386 assuming you build for x86_64-apple-darwin10)?
> 
> (2) provide your full configure line?
> 
>> I *have* a build that works -- I built it with gcc-4.4.3 with no problem.  The
>> difficulty is with Apple's gcc distribution.  As I pointed out earlier, I'd be
>> struggling if I didn't have a new version of gcc on-board.  The only thing I
>> did not try is to see if I used a gcc-4.5.0 build with --disable-bootstrap from
>> Apple's gcc to rebuild gcc-4.5.0 with itself...  Even then, I'd be somewhat
>> worried that the then consistent compiler might be producing code at variance
>> with builds on other operating systems yielding inexplicable bugs or bugs that
>> other people could not reproduce on their platforms.
> 
> In my builds stage1 use Apple stock gcc: gcc version 4.2.1 (Apple Inc. build
> 5659).
> The only way I know that can convince anybody that the build is sane is to run
> make check for 32 and 64 bit modes (though it's certainly not a proof!-).
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

Created attachment 20399 [details]
config.log

Subject: Re:  gcc 4.5 20100218 bootstrap compare fails on os x 10.6

I have one more comment to add.  Perusing the log file, I noticed that it was not building what I expected.  I was not looking for -m32's.  I re-ran configure with

configure ABI=64 --enable-languages=c,c++,objc,obj-c++,fortran

and the code built correctly!

I am aware that the sort of dual-personality 32bit/64bit character of Apple Leopards is a pain - but it strikes me that the configure is generating something that the rest of the build struggles with... why is this showing up in gomp?

Best,
Dan




On Apr 16, 2010, at 10:34 AM, dominiq at lps dot ens dot fr wrote:

> 
> 
> ------- Comment #26 from dominiq at lps dot ens dot fr  2010-04-16 14:34 -------
> First a Note for Ralf Wildenhues: I have seen somewhere that libgomp have been
> added to stage2 starting from some revision, but I am unable to find where. Do
> you have a better memory?
> I think it is after 4.4 (so nothing can be infered from building 4.4.x).
> 
>> In this case, I have found the bug consistently repeatable on multiple
>> machines, all running snow leopard up-to-date.  When built on my desk-top
>> machine there were no other applications running except for "TeamViewer" (I
>> built it from work).  The other builds were made without TeamViewer.  Browsers
>> on/off, doesn't matter.
> 
> Can you 
> 
> (1) check that your builds fail as reported in comment #13 (you have to check
> stageX-x86_64-apple-darwin10/YYY/libgomp/config.log with X in 2 or 3 and YYY in
> . or i386 assuming you build for x86_64-apple-darwin10)?
> 
> (2) provide your full configure line?
> 
>> I *have* a build that works -- I built it with gcc-4.4.3 with no problem.  The
>> difficulty is with Apple's gcc distribution.  As I pointed out earlier, I'd be
>> struggling if I didn't have a new version of gcc on-board.  The only thing I
>> did not try is to see if I used a gcc-4.5.0 build with --disable-bootstrap from
>> Apple's gcc to rebuild gcc-4.5.0 with itself...  Even then, I'd be somewhat
>> worried that the then consistent compiler might be producing code at variance
>> with builds on other operating systems yielding inexplicable bugs or bugs that
>> other people could not reproduce on their platforms.
> 
> In my builds stage1 use Apple stock gcc: gcc version 4.2.1 (Apple Inc. build
> 5659).
> The only way I know that can convince anybody that the build is sane is to run
> make check for 32 and 64 bit modes (though it's certainly not a proof!-).
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.

pr44304 may a duplicate of this one.

4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on trunk yesterday, with r159979) in which several t-make fragments are included twice on x86_64-*-darwin*.  
I wonder if this could be the origin of the problem?

If anyone is interested to try it out I could make you a patch for 4.5-branch to do the same fix.

> 4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on
> trunk yesterday, with r159979) in which several t-make fragments are included
> twice on x86_64-*-darwin*.  
> I wonder if this could be the origin of the problem?

I just had a libgomp bootstrap comparison failure with 4.6 trunk at revision 160142. So it is not fixed by r159979. Too bad!-(

(In reply to comment #32)
> > 4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on
> > trunk yesterday, with r159979) in which several t-make fragments are included
> > twice on x86_64-*-darwin*.  
> > I wonder if this could be the origin of the problem?
> 
> I just had a libgomp bootstrap comparison failure with 4.6 trunk at revision
> 160142. So it is not fixed by r159979. Too bad!-(

can you do me a favor?
(a) copy the config.{log,out} files.
(b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
.. I suspect a configure race condition - and would not be surprised if the second attempt works...
(it's essential to re-do the configure - not just to re-try the bootstrap).
(c) if it works we can compare the config files and try and figure out where the race is.

> can you do me a favor?
> (a) copy the config.{log,out} files.
> (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> .. I suspect a configure race condition - and would not be surprised if the
> second attempt works...
> (it's essential to re-do the configure - not just to re-try the bootstrap).
> (c) if it works we can compare the config files and try and figure out where
> the race is.

I am not sure to understand what you ask me to do in (b):

rm -r what?

should I run 'reconfigure' in the building directory?

Although I did not check that the failure is always due to the failing test spotted in comment #13, I am pretty confident that it is the case. A quick diagnostic is given in comment #3 of pr44304. I have seen the infamous "gcc_cv_have_tls=no" randomly at stage 2 or 3 and in libgomp or i386/libgomp.

(In reply to comment #34)
> > can you do me a favor?
> > (a) copy the config.{log,out} files.
> > (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> > .. I suspect a configure race condition - and would not be surprised if the
> > second attempt works...
> > (it's essential to re-do the configure - not just to re-try the bootstrap).
> > (c) if it works we can compare the config files and try and figure out where
> > the race is.
> 
> I am not sure to understand what you ask me to do in (b):
> 
> rm -r what?
> 
> should I run 'reconfigure' in the building directory?
> 
> Although I did not check that the failure is always due to the failing test
> spotted in comment #13, I am pretty confident that it is the case. A quick
> diagnostic is given in comment #3 of pr44304. I have seen the infamous
> "gcc_cv_have_tls=no" randomly at stage 2 or 3 and in libgomp or i386/libgomp.
> 

(In reply to comment #34)
> > can you do me a favor?
> > (a) copy the config.{log,out} files.
> > (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> > .. I suspect a configure race condition - and would not be surprised if the
> > second attempt works...
> > (it's essential to re-do the configure - not just to re-try the bootstrap).
> > (c) if it works we can compare the config files and try and figure out where
> > the race is.
> 
> I am not sure to understand what you ask me to do in (b):
> 
> rm -r what?

your failed build.

> should I run 'reconfigure' in the building directory?

do a clean configure & bootstrap without updating the source tree.
If it is a marginal race condition, it is likely to succeed.
I guess the other proof is a non-j<n> bootstrap (but that takes longer to prove).

I agree the tls variable is the likely culprit - perhaps there is a missing dependency on building libgomp.  I think that introduction of libgomp into all stages is recent-ish.

Since I had a new comparison failure before your answer, I did the following:

(1) delete the various libgomp folders,
(2) resume make.

Indeed the new libgomp were correctly built and I am now building libgfortran.

As hinted in some of my previous post, I have the filling that the failures in detecting gcc_cv_have_tls are related to the load of my macbook, in particular what kind of web sites I am browsing at that time (java applets or flash?!-).

(In reply to comment #36)
> Since I had a new comparison failure before your answer, I did the following:

yes, re-running bootstrap will make no difference if the race is in the configure... 

> (1) delete the various libgomp folders,

OK. that forces  libgomp config to run again...  

note that if the race is vs. libgcc_s (which is needed for emutls) then that is guaranteed to work.   

I'm guessing a libgcc_s/libgomp race is the origin since w/out the newly-built libgcc_s - the system one would be found - and that doesn't have emutls.

> (2) resume make.

make -jN all
or make -jn bootstrap?

(I guess there should be no difference - IIRC all->bootstrap if bootstrap is configured )

> Indeed the new libgomp were correctly built and I am now building libgfortran.
> 
> As hinted in some of my previous post, I have the filling that the failures in
> detecting gcc_cv_have_tls are related to the load of my macbook, in particular
> what kind of web sites I am browsing at that time (java applets or flash?!-).

well, I guess any load variation could cause it if there's a race .. ;) ...

> make -jN all 
> or make -jn bootstrap?

make -j2 >>& log_file &

Can you (someone with darwin) just take the configure test from comment #13, build it, and run it under various load on your system, to see whether it produces unstable results with a compiler from the previous stage?  Thanks.

Just to be sure, this is not just about the a_in_other_thread pointer lacking a volatile qualifier, or use of proper exclusion primitive?

Here's the source again, for reference:

#include <pthread.h>
             __thread int a; 
             static int *a_in_other_thread;
             static void *
             thread_func (void *arg)
             {
               a_in_other_thread = &a;
               return (void *)0;
             }
int
main ()
{
pthread_t thread;
             void *thread_retval;
             int *a_in_main_thread;
             if (pthread_create (&thread, (pthread_attr_t *)0,
                                 thread_func, (void *)0))
               return 0;
             a_in_main_thread = &a;
             if (pthread_join (thread, &thread_retval))
               return 0;
             return (a_in_other_thread == a_in_main_thread);
  ;
  return 0;
}

> Can you (someone with darwin)  ...

I have tried:

[macbook] f90/bug% gcc46 pthread_create.c
[macbook] f90/bug% a.out ; echo $?
0

Is it the correct way to do the test? (so far I only got zeros).

Subject: Re:  gcc 4.5 20100218 bootstrap compare fails
 on os x 10.6

* dominiq at lps dot ens dot fr wrote on Wed, Jun 02, 2010 at 07:09:42PM CEST:
> [macbook] f90/bug% gcc46 pthread_create.c
> [macbook] f90/bug% a.out ; echo $?
> 0
> 
> Is it the correct way to do the test? (so far I only got zeros).

Well you could try ...prev-gcc/xgcc -B... instead; see your respective
libgomp/config.log file, it lists the command line that is used for the
test (search for "thread-local storage").

I am using the following script:

#!/bin/sh
i=0
tls.ex
while [ $? == 0 ]
do
  i=`expr $i + 1`
  tls.ex
done
echo $i

tls.ex is generated by

/opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/ -g -O2 -pthread pthread_create.c -o tls.ex

If I did not make any mistake in the script, it loops until tls.ex fails. for an idle system with couple applications open, I get:

[macbook] f90/bug% tls.sh
26
[macbook] f90/bug% tls.sh
15
[macbook] f90/bug% tls.sh
150
[macbook] f90/bug% tls.sh
26
[macbook] f90/bug% tls.sh
157
[macbook] f90/bug% tls.sh
33
[macbook] f90/bug% tls.sh
68
[macbook] f90/bug% tls.sh
131

The following variant

#!/bin/sh
i=0
while [ $i != 1000 ]
do
  i=`expr $i + 1`
  tls.ex
  if [ $? != 0 ]
  then
    echo $i
  fi
done

gives

26
84
87
90
266
386
426
587
611
614
617
637
640
647
653
656
962

if the system is idle, but

2
13
14
16
17
20
23
24
26
32
33
35
40
47
50
53
54
56
58
...
900
901
903
906
910
913
914
917
958
961
987
990
996
999

if I am browsing the web site of a newspaper.

This seems linked to the optimization:

[macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/ -O2 -pthread pthread_create.c -o tls.ex
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       9
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       7
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
      26
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
     420
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
     266
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
     277
[macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/ -O1 -pthread pthread_create.c -o tls.ex
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
      11
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       9
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
      10
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
     357
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
     391
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
     376
[macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/ -pthread pthread_create.c -o tls.ex
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       0
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       1
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       0
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       1
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       0
[macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
       0

For each O level, the first 3 runs are for an idle system and the 3 others for a loaded one.

(In reply to comment #44)
> This seems linked to the optimization:
> 
> [macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/
> -O2 -pthread pthread_create.c -o tls.ex
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        9
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        7
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>       26
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>      420
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>      266
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>      277
> [macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/
> -O1 -pthread pthread_create.c -o tls.ex
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>       11
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        9
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>       10
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>      357
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>      391
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>      376
> [macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/
> -pthread pthread_create.c -o tls.ex
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        0
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        1
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        0
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        1
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        0
> [macbook] f90/bug% rm -f tmp ; tls_1.sh > tmp ; cat tmp | wc -l
>        0
> 
> For each O level, the first 3 runs are for an idle system and the 3 others for
> a loaded one.

hm.  that might be bad news :-( 

I've got a patch that puts some TLS tests into the torture tests  - I'll dig them out and see what happens on current trunk.

It's odd that this is only affecting x86_64-d10 tho, if it's an error of that nature....

1) have you got my 'proper' TLS patch to hand? (attached to PR44132).
2) do you have time to rebootstrap w that patch ?
3) what compiler do you use for stage1? 

(I saw in the related PR about 4.5.0 that the TLS stuff was looking enabled at stage1 - which is odd if the apple compiler is being used, since it doesn't have tls ;))

(In reply to comment #44)
> This seems linked to the optimization:

At the risk of stating the obvious - since there are no DYLD_LIBRARY_PATH in your posts... 

Are you doing this "uninstalled"?
I guess you have to be sure that the right libgcc_s is being found -- or emutls will not be present.

(this also applies to the config tests - which means the libgomp tests should depend on the early copy across of libgcc_s)

I assume that this is the case for any target lib (but I've not looked).

> At the risk of stating the obvious - since there are no DYLD_LIBRARY_PATH in
> your posts... 
>
> Are you doing this "uninstalled"?
> I guess you have to be sure that the right libgcc_s is being found -- or emutls
> will not be present.

This is certainly too obvious for me! how "emutls will not be present" and the test succeeds most of the time? I have checked it with gcc4.5 r156693 on i686-apple-darwin9 and the test always fails (1000 failures on 1000 attempts). What is the output of

grep -i tls your_paths/libgomp/config.log

on darwin9?

Created attachment 20814 [details]
adds some TLS torture tests to gcc.dg

Hm - the "placeholder, temporary" fix for EMUTLS doesn't appear to work with optimization on.. :(

The better news is that the 'proper' fix @PR44132 does ;)
(but there is still one "TODO" on that).

Having said that, the flags are consistently applied in building gcc - so it's not clear why we have a pseudo-random effect - and why it only manifests on x86_64-d10.

(In reply to comment #47)
> > At the risk of stating the obvious - since there are no DYLD_LIBRARY_PATH in
> > your posts... 
> >
> > Are you doing this "uninstalled"?
> > I guess you have to be sure that the right libgcc_s is being found -- or emutls
> > will not be present.
> 
> This is certainly too obvious for me! how "emutls will not be present" and the
> test succeeds most of the time? I have checked it with gcc4.5 r156693 on
> i686-apple-darwin9 and the test always fails (1000 failures on 1000 attempts).
> What is the output of
> 
> grep -i tls your_paths/libgomp/config.log
> 
> on darwin9?
> 

hm. if I do ./gcc/xgcc -B gcc tls-test.c -o tls
./tls 
it fails saying it can't find __emutls_getaddress () ... which is correct, since I don't have gcc > 4.5 installed

I have to do
DYLD_LIBRARY_PATH=./gcc ./tls

> What is the output of
>
> grep -i tls your_paths/libgomp/config.log
>
> on darwin9?

For me the answer is "gcc_cv_have_tls=no" for both powerpc-apple-darwin9 gcc 4.6 r160081 and i686-apple-darwin9 gcc 4.5 r156693.

(In reply to comment #50)
> > What is the output of
> >
> > grep -i tls your_paths/libgomp/config.log
> >
> > on darwin9?
> 
> For me the answer is "gcc_cv_have_tls=no" for both powerpc-apple-darwin9 gcc
> 4.6 r160081 and i686-apple-darwin9 gcc 4.5 r156693.

same  for me with the current tls implementation.

(and it's "YES" with the implementation @PR44132 (sorry for the confusion)).

(In reply to comment #51)
> (In reply to comment #50)
> > > What is the output of
> > >
> > > grep -i tls your_paths/libgomp/config.log
> > >
> > > on darwin9?
> > 
> > For me the answer is "gcc_cv_have_tls=no" for both powerpc-apple-darwin9 gcc
> > 4.6 r160081 and i686-apple-darwin9 gcc 4.5 r156693.

and on D10 - no @ stage1 (correct)
and YES on stage2 and stage3 - which may/may not be correct ... 

> 
> same  for me with the current tls implementation.
> 
> (and it's "YES" with the implementation @PR44132 (sorry for the confusion)).
> 

> Created an attachment (id=20814) [edit]
> adds some TLS torture tests to gcc.dg
>
> Hm - the "placeholder, temporary" fix for EMUTLS doesn't appear to work with
> optimization on.. :(

For make -k check-gcc RUNTESTFLAGS="tls.exp=* --target_board=unix'{-m32,-m64}'", I get

		=== gcc tests ===

Running target unix/-m32
Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/gcc.dg/tls/tls.exp ...
Running /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp ...
FAIL: gcc.dg/torture/tls/tls-test.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O3 -g  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -flto  compilation failed to produce executable
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  compilation failed to produce executable

		=== gcc Summary for unix/-m32 ===

# of expected passes		97
# of unexpected failures	4
# of unsupported tests		13
Running target unix/-m64
Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/gcc.dg/tls/tls.exp ...
Running /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp ...
FAIL: gcc.dg/torture/tls/thr-init-1.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/tls/thr-init-1.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -flto  compilation failed to produce executable
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  compilation failed to produce executable

		=== gcc Summary for unix/-m64 ===

# of expected passes		95
# of unexpected failures	6
# of unsupported tests		13

		=== gcc Summary ===

# of expected passes		192
# of unexpected failures	10
# of unsupported tests		26

or

Running target unix/-m32
Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/gcc.dg/tls/tls.exp ...
Running /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp ...
FAIL: gcc.dg/torture/tls/tls-test.c  -O2  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -flto  compilation failed to produce executable
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  compilation failed to produce executable

		=== gcc Summary for unix/-m32 ===

# of expected passes		97
# of unexpected failures	4
# of unsupported tests		13
Running target unix/-m64
Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/gcc.dg/tls/tls.exp ...
Running /opt/gcc/work/gcc/testsuite/gcc.dg/torture/tls/tls.exp ...
FAIL: gcc.dg/torture/tls/thr-init-1.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/tls/thr-init-1.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -O2 -fwhopr  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -flto  compilation failed to produce executable
FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  (test for excess errors)
WARNING: gcc.dg/torture/tls/tls-test.c  -O2 -fwhopr  compilation failed to produce executable

		=== gcc Summary for unix/-m64 ===

# of expected passes		94
# of unexpected failures	7
# of unsupported tests		13

		=== gcc Summary ===

# of expected passes		191
# of unexpected failures	11
# of unsupported tests		26
/opt/gcc/build_w/gcc/xgcc  version 4.6.0 20100602 (experimental) [trunk revision 160166p3] (GCC) 

with some random failures.

(In reply to comment #53)
> > Created an attachment (id=20814) [edit]
> > adds some TLS torture tests to gcc.dg
> >
> > Hm - the "placeholder, temporary" fix for EMUTLS doesn't appear to work with
> > optimization on.. :(

they fail consistently @ O> 0 on i686-darwin9 (m32 & m64)

so... something is not right with one or the other.. and it looks like it's the x86_64 that's dodgy.

> and on D10 - no @ stage1 (correct)

I see

[macbook] gcc/build_w% grep -i tls stage1-x86_64-apple-darwin10.3.0/libgomp/config.log
| #define HAVE_TLS 1
| #define HAVE_TLS 1
| #define HAVE_TLS 1
| #define HAVE_TLS 1
gcc_cv_have_tls=yes
#define HAVE_TLS 1
[macbook] gcc/build_w% grep -i tls stage1-x86_64-apple-darwin10.3.0/i386/libgomp/config.log
| #define HAVE_TLS 1
| #define HAVE_TLS 1
| #define HAVE_TLS 1
| #define HAVE_TLS 1
gcc_cv_have_tls=yes
#define HAVE_TLS 1

> so... something is not right with one or the other.. and it looks like it's the
> x86_64 that's dodgy.

I hope I don't have any leftover from previous patches!-) I think so, but I may have missed something.

> The better news is that the 'proper' fix @PR44132 does ;)

I have applied the 'proper' fix, the number of failures under load has been reduced from ~1/3 to ~1/2000, but still nonzero!-(

> (but there is still one "TODO" on that).

and I see the TODO:

FAIL: gcc.dg/tls/asm-1.c (internal compiler error)
FAIL: gcc.dg/tls/asm-1.c  (test for errors, line 7)
FAIL: gcc.dg/tls/asm-1.c (test for excess errors)

(In reply to comment #55)
> > and on D10 - no @ stage1 (correct)
> 
> I see
> 
> [macbook] gcc/build_w% grep -i tls
> stage1-x86_64-apple-darwin10.3.0/libgomp/config.log
> | #define HAVE_TLS 1
> | #define HAVE_TLS 1
> | #define HAVE_TLS 1
> | #define HAVE_TLS 1
> gcc_cv_have_tls=yes

then, I guess you are not bootstrapping from Apple's compiler - since that doesn't have TLS,.
You must have a gcc > 4.4 in your path (which might cause some confusion on ocassion).

> #define HAVE_TLS 1
> [macbook] gcc/build_w% grep -i tls
> stage1-x86_64-apple-darwin10.3.0/i386/libgomp/config.log
> | #define HAVE_TLS 1
> | #define HAVE_TLS 1
> | #define HAVE_TLS 1
> | #define HAVE_TLS 1
> gcc_cv_have_tls=yes
> #define HAVE_TLS 1
> 
> > so... something is not right with one or the other.. and it looks like it's the
> > x86_64 that's dodgy.
> 
> I hope I don't have any leftover from previous patches!-) I think so, but I may
> have missed something.
> 
> > The better news is that the 'proper' fix @PR44132 does ;)
> 
> I have applied the 'proper' fix, the number of failures under load has been
> reduced from ~1/3 to ~1/2000, but still nonzero!-(

It seems that we must have 
(a)  code-gen issue (OR
(b) a buggy pthreads implementation on D10 :(

I had a quick look at the asm out from O0 and O1 .. there's one odd instruction ..  but nothing leaps out at me yet,,,

> 
> > (but there is still one "TODO" on that).
> 
> and I see the TODO:
> 
> FAIL: gcc.dg/tls/asm-1.c (internal compiler error)
> FAIL: gcc.dg/tls/asm-1.c  (test for errors, line 7)
> FAIL: gcc.dg/tls/asm-1.c (test for excess errors)

Indeed, I am hoping for some help from Honza on that (I think it is actually exposing an assumption on the part of gimplify_asm() that is incorrect).

(In reply to comment #46)
> At the risk of stating the obvious - since there are no DYLD_LIBRARY_PATH in
> your posts... 

Ah, right, I forgot to remind you to set DYLD_LIBRARY_PATH correctly when doing the test (toplevel Makefile sets it).  Sorry about that.

Other than that, you guys manage to write a lot about this but still not answer all questions (both of which makes it unattractive for others to look at a PR).  What about missing volatile for comment #39, as in

  static int * volatile a_in_other_thread;

?

(In reply to comment #57)
> (In reply to comment #46)

> Other than that, you guys manage to write a lot about this but still not answer
> all questions (both of which makes it unattractive for others to look at a PR).
>  What about missing volatile for comment #39, as in
> 
>   static int * volatile a_in_other_thread;

sorry, I missed that.
That correction does _not_ make the tests behave deterministically on darwin10.
The tests behave deterministically with/without it on darwin9 (pass at O0, fail > O0).

Why would be volatile needed?  pthread_join returning guarantees that the other thread's thread function finished, and the variable is only written in that thread, there is no data race on it.

(In reply to comment #59)
> Why would be volatile needed?  pthread_join returning guarantees that the other
> thread's thread function finished, and the variable is only written in that
> thread, there is no data race on it.

Does pthread_join imply a memory barrier?  IOW, why can the read of a_in_other_thread not be reordered before that?
If I'm missing something obvious here, thanks for clarifying.

Is this bug just a dupe of PR 44132 now?

Of course pthread_join implies all outstanding memory stores of the dead thread complete before pthread_join returns.  And, pthread_join is a non-inlined function call, a_in_other_thread is a global variable, so the compiler has to assume the pthread_join call can modify it.

(In reply to comment #60)
> (In reply to comment #59)

> Is this bug just a dupe of PR 44132 now?

No, PR44132 applies to all darwin versions.

However, I think it *is* a dup of PR44304 (which relates to the fail of bootstrap on 4.5.0/Darwin10)

(In reply to comment #62)
> (In reply to comment #60)
> > (In reply to comment #59)
> 
> > Is this bug just a dupe of PR 44132 now?
> 
> No, PR44132 applies to all darwin versions.

OK, I need to refine that comment.  
Further testing this morning reveals that the code at comment #42 (modified to put in the DYLD_LIB)  does also fail on darwin9 (albeit much less frequently).  

However, PR44132 is a non-random problem that applies to all emutls targets and has a distinct solution.

==

It is not clear (yet) whether this (43170)  bug is in emutls or the platform. 

So, probably better to keep the bugs separate.

I've also had a report for the fink gcc45-4.5.0-1000 package of the boot strap comparison failure occuring (rarely) on a single processor PowerPC (building with make -j 1).

*** Bug 44304 has been marked as a duplicate of this bug. ***

At the risk of confusing the issues here, I would point out...

http://gcc.gnu.org/ml/gcc/2010-04/msg00044.html

where I observed that 20_util/shared_ptr/thread/default_weaktoshared.cc execution test rarely times out on darwin10. A standalone testcase which reproduces this bug (if executed enough times) is in http://gcc.gnu.org/ml/gcc/2010-04/msg00035.html.

I am puzzled by this apparent fail when the tests that depend on the variables being distinct are all passing.
So, I think I've got a hunch; 

If the spawned thread finishes before pthread_create () returns, then the allocation for the thread's version of 'a' will have been released.    

There is nothing to stop malloc from allocating the same block to the main thread version of 'a' when it is asked for.

I would be reluctant to draw too many conclusions from current trunk since the emutls has a "work-around" fix in it - but putting a usleep (1000) into the x86_64 spawned thread works.  

=== 

On darwin9 ppc/i686 with the patch @ comment #26 of PR44132 applied: 

using this driver to do uninstalled tests:
---
#!/bin/sh
i=0
while [ $(( $i < 1000000 )) ]
do
  i=`expr $i + 1`
  r=`DYLD_LIBRARY_PATH=./gcc ./tls.ex`
  if [ $? != 0 ]
  then
    printf "%7d : %s\n" $((i)) "$r"
  fi
done
-----
and this version of the test fragment:
-----
/* { dg-do run }  */
/* { dg-require-effective-target tls  }  */

#include <pthread.h>
extern int printf (char *,...);
extern int usleep (long);
__thread int a = 5 ; 
static int *a_in_other_thread;

static void *
thread_func (void *arg)
{
/*  usleep (1000);*/
  a_in_other_thread = &a;
  a += 5 ;
  *((int *) arg) = a ;
  return (void *)0;
}

int
main ()
{
  pthread_t thread;
  void *thread_retval;
  int *a_in_main_thread;
  int thrd_arg;

  a_in_main_thread = &a;

  if (pthread_create (&thread, (pthread_attr_t *)0, thread_func, &thrd_arg))
    return 0;

  if (pthread_join (thread, &thread_retval))
    return 0;

  if (a != 5 || thrd_arg != 10 || (a_in_other_thread == a_in_main_thread))
  {
     printf ("FAIL: a = %d thrd_a = %d address = 0x%0x\n", 
		    a, thrd_arg, a_in_main_thread);
     return 1 ;
  }
  return 0;
}

----
this has been running for 2hrs w/out a fail so far on both ppc and i686 d9.. 

That makes sense, so all we need to do in config/tls.m4 is probably:
1) move a_in_main_thread variable to file scope, and neither a_in_main_thread nor a_in_other_thread should be static
2) move a_in_main_thread = &a; before pthread_create
That should be IMHO all that is needed, the compiler can't then move a_in_main_thread assignment after pthread_create.  Or to be really sure make
a_in_main_thread and a_in_other_thread volatile too.

So the tls tests in the generated configure should be changed as follows?

--- gcc-4.5.0/libgomp/configure.orig    2010-06-03 13:05:23.000000000 -0400
+++ gcc-4.5.0/libgomp/configure 2010-06-03 13:41:14.000000000 -0400
@@ -15379,7 +15379,8 @@
 /* end confdefs.h.  */
 #include <pthread.h>
                __thread int a;
-               static int *a_in_other_thread;
+               int *a_in_other_thread;
+               int *a_in_main_thread;
                static void *
                thread_func (void *arg)
                {
@@ -15391,11 +15392,10 @@
 {
 pthread_t thread;
                void *thread_retval;
-               int *a_in_main_thread;
+               a_in_main_thread = &a;
                if (pthread_create (&thread, (pthread_attr_t *)0,
                                    thread_func, (void *)0))
                  return 0;
-               a_in_main_thread = &a;
                if (pthread_join (thread, &thread_retval))
                  return 0;
                return (a_in_other_thread == a_in_main_thread);

(In reply to comment #68)
> That makes sense, so all we need to do in config/tls.m4 is probably:
> 1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
> nor a_in_other_thread should be static
> 2) move a_in_main_thread = &a; before pthread_create
> That should be IMHO all that is needed, the compiler can't then move
> a_in_main_thread assignment after pthread_create.  Or to be really sure make
> a_in_main_thread and a_in_other_thread volatile too.

Does this code follow these instructions?

#include <pthread.h>
             __thread int a;
             int *a_in_main_thread;
             int *a_in_other_thread;
             static void *
             thread_func (void *arg)
             {
               a_in_other_thread = &a;
               return (void *)0;
             }
int
main ()
{
pthread_t thread;
             void *thread_retval;
             a_in_main_thread = &a;
             if (pthread_create (&thread, (pthread_attr_t *)0,
                                 thread_func, (void *)0))
               return 0;
             if (pthread_join (thread, &thread_retval))
               return 0;
             return (a_in_other_thread == a_in_main_thread);
  ;
  return 0;
}

I have compiled it with -O2 -g -pthread and ran it 10000 times on a loaded system without failure.

Yes.

Created attachment 20822 [details]
config patch for test

 config/tls.m4 - modified as per Jakub's suggestion
 */configure regenerated as necessary.

see how it works for you - I'm bootstrapping x86_64 with this at the moment.

(In reply to comment #72)
> Created an attachment (id=20822) [edit]
> config patch for test
> 
>  config/tls.m4 - modified as per Jakub's suggestion
>  */configure regenerated as necessary.
> 
> see how it works for you - I'm bootstrapping x86_64 with this at the moment.

successful bootstraps w/c #26 from PR44132 with tls showing enabled for each stage on i686-darwin9 and x86_64-darwin10.  

I don't expect tls to show without #26 from PR44132, because current trunk emutls solution is not working with optimization (one good reason for introducing a few tls tests into the torture suite).

posted as
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00463.html

Subject: Bug 43170

Author: iains
Date: Wed Jun  9 09:27:04 2010
New Revision: 160457

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160457
Log:

config:
	PR bootstrap/43170
	* tls.m4 (GCC_CHECK_TLS): Add volatile qualifier to the test 
	references.  Move the main () test reference ahead of 
	pthread_create().  Add a comment to explain the requirements
	of the test.
libgomp:
	PR bootstrap/43170
	* configure: Regenerate.
libjava:
	PR bootstrap/43170
	* configure: Regenerate.
libmudflap:
	PR bootstrap/43170
	* configure: Regenerate.
libstdc++-v3:
	PR bootstrap/43170
	* configure: Regenerate.


Modified:
    trunk/config/ChangeLog
    trunk/config/tls.m4
    trunk/libgomp/ChangeLog
    trunk/libgomp/configure
    trunk/libjava/ChangeLog
    trunk/libjava/configure
    trunk/libmudflap/ChangeLog
    trunk/libmudflap/configure
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/configure

committed to the 4.5 branch as r160526.

no new issues having been reported by the regression testers, closing this as fixed.

*** Bug 46109 has been marked as a duplicate of this bug. ***

*** Bug 45285 has been marked as a duplicate of this bug. ***