[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yuri at tsoft dot com

--- Comment #78 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-21 05:42:47 UTC ---
*** Bug 46109 has been marked as a duplicate of this bug. ***

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org

--- Comment #79 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-28 20:09:48 UTC ---
*** Bug 45285 has been marked as a duplicate of this bug. ***

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #77 from iains at gcc dot gnu dot org  2010-06-11 08:38 -------
no new issues having been reported by the regression testers, closing this as
fixed.


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #76 from iains at gcc dot gnu dot org  2010-06-10 09:02 -------
committed to the 4.5 branch as r160526.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #75 from iains at gcc dot gnu dot org  2010-06-09 09:27 -------
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


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #74 from iains at gcc dot gnu dot org  2010-06-06 13:35 -------
posted as
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00463.html


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #73 from iains at gcc dot gnu dot org  2010-06-04 00:40 -------
(In reply to comment #72)
> Created an attachment (id=20822)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822&action=view) [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).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #72 from iains at gcc dot gnu dot org  2010-06-03 20:06 -------
Created an attachment (id=20822)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822&action=view)
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[jakub at gcc dot gnu dot org]

------- Comment #71 from jakub at gcc dot gnu dot org  2010-06-03 19:02 -------
Yes.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #70 from dominiq at lps dot ens dot fr  2010-06-03 18:23 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[howarth at nitro dot med dot uc dot edu]

------- Comment #69 from howarth at nitro dot med dot uc dot edu  2010-06-03 18:20 -------
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);


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[jakub at gcc dot gnu dot org]

------- Comment #68 from jakub at gcc dot gnu dot org  2010-06-03 16:58 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #67 from iains at gcc dot gnu dot org  2010-06-03 16:12 -------
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.. 


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[howarth at nitro dot med dot uc dot edu]

------- Comment #66 from howarth at nitro dot med dot uc dot edu  2010-06-03 13:46 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #65 from iains at gcc dot gnu dot org  2010-06-03 13:17 -------
*** Bug 44304 has been marked as a duplicate of this bug. ***


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doc0 dot delphin at voila
                   |                            |dot fr


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[howarth at nitro dot med dot uc dot edu]

------- Comment #64 from howarth at nitro dot med dot uc dot edu  2010-06-03 13:03 -------
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).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #63 from iains at gcc dot gnu dot org  2010-06-03 12:50 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #62 from iains at gcc dot gnu dot org  2010-06-03 10:59 -------
(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)


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[jakub at gcc dot gnu dot org]

------- Comment #61 from jakub at gcc dot gnu dot org  2010-06-03 10:47 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #60 from rwild at gcc dot gnu dot org  2010-06-03 10:33 -------
(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?


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[jakub at gcc dot gnu dot org]

------- Comment #59 from jakub at gcc dot gnu dot org  2010-06-03 09:10 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #58 from iains at gcc dot gnu dot org  2010-06-03 07:57 -------
(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).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #57 from rwild at gcc dot gnu dot org  2010-06-03 05:53 -------
(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;

?


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #56 from iains at gcc dot gnu dot org  2010-06-02 22:07 -------
(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).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #55 from dominiq at lps dot ens dot fr  2010-06-02 20:59 -------
> 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)


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #54 from iains at gcc dot gnu dot org  2010-06-02 20:44 -------
(In reply to comment #53)
> > Created an attachment (id=20814)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20814&action=view) [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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #53 from dominiq at lps dot ens dot fr  2010-06-02 20:39 -------
> Created an attachment (id=20814)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20814&action=view) [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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #52 from iains at gcc dot gnu dot org  2010-06-02 20:32 -------
(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)).
> 


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #51 from iains at gcc dot gnu dot org  2010-06-02 20:28 -------
(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)).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #50 from dominiq at lps dot ens dot fr  2010-06-02 20:19 -------
> 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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #49 from iains at gcc dot gnu dot org  2010-06-02 20:13 -------
(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


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #48 from iains at gcc dot gnu dot org  2010-06-02 20:09 -------
Created an attachment (id=20814)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20814&action=view)
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #47 from dominiq at lps dot ens dot fr  2010-06-02 20:08 -------
> 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?


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #46 from iains at gcc dot gnu dot org  2010-06-02 19:42 -------
(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).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #45 from iains at gcc dot gnu dot org  2010-06-02 19:15 -------
(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 ;))


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #44 from dominiq at lps dot ens dot fr  2010-06-02 19:06 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #43 from dominiq at lps dot ens dot fr  2010-06-02 18:36 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #42 from dominiq at lps dot ens dot fr  2010-06-02 18:22 -------
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


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[Ralf dot Wildenhues at gmx dot de]

------- Comment #41 from Ralf dot Wildenhues at gmx dot de  2010-06-02 17:40 -------
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").


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #40 from dominiq at lps dot ens dot fr  2010-06-02 17:09 -------
> 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).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #39 from rwild at gcc dot gnu dot org  2010-06-02 17:04 -------
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;
}


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #38 from dominiq at lps dot ens dot fr  2010-06-02 10:16 -------
> make -jN all 
> or make -jn bootstrap?

make -j2 >>& log_file &


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #37 from iains at gcc dot gnu dot org  2010-06-02 10:06 -------
(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 .. ;) ...


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #36 from dominiq at lps dot ens dot fr  2010-06-02 09:53 -------
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?!-).


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #35 from iains at gcc dot gnu dot org  2010-06-02 09:44 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #34 from dominiq at lps dot ens dot fr  2010-06-02 09:35 -------
> 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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #33 from iains at gcc dot gnu dot org  2010-06-02 09:24 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #32 from dominiq at lps dot ens dot fr  2010-06-02 08:59 -------
> 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!-(


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

------- Comment #31 from iains at gcc dot gnu dot org  2010-05-29 07:47 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #30 from dominiq at lps dot ens dot fr  2010-05-28 12:16 -------
pr44304 may a duplicate of this one.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[danp57 at optonline dot net]

------- Comment #29 from danp57 at optonline dot net  2010-04-16 17:06 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[danp57 at optonline dot net]

------- Comment #27 from danp57 at optonline dot net  2010-04-16 15:27 -------
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.


------- Comment #28 from danp57 at optonline dot net  2010-04-16 15:27 -------
Created an attachment (id=20399)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20399&action=view)


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[howarth at nitro dot med dot uc dot edu]

------- Comment #25 from howarth at nitro dot med dot uc dot edu  2010-04-16 13:52 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[danp57 at optonline dot net]

------- Comment #24 from danp57 at optonline dot net  2010-04-16 13:26 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[danp57 at optonline dot net]

------- Comment #22 from danp57 at optonline dot net  2010-04-16 09:49 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[danp57 at optonline dot net]

------- Comment #20 from danp57 at optonline dot net  2010-04-16 01:06 -------
PS> This will block any direct or first attempt to build gcc by Mac owners
unless they try builds of intermediate versions of gcc.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[danp57 at optonline dot net]

------- Comment #19 from danp57 at optonline dot net  2010-04-16 00:44 -------
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


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[steven at gcc dot gnu dot org]

------- Comment #18 from steven at gcc dot gnu dot org  2010-04-15 22:18 -------
*** Bug 43761 has been marked as a duplicate of this bug. ***


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danp57 at optonline dot net


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2010-04-15 22:16 -------
pr43761 is a duplicate of this one.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #16 from dominiq at lps dot ens dot fr  2010-03-13 10:56 -------
>  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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #15 from rwild at gcc dot gnu dot org  2010-03-13 09:14 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #14 from rwild at gcc dot gnu dot org  2010-03-13 09:12 -------
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?


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2010-03-12 10:38 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #12 from rwild at gcc dot gnu dot org  2010-02-28 18:14 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2010-02-28 15:39 -------
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


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2010-02-28 12:32 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #9 from rwild at gcc dot gnu dot org  2010-02-28 12:22 -------
(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.)


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2010-02-28 11:59 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #7 from rwild at gcc dot gnu dot org  2010-02-28 11:42 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2010-02-28 11:29 -------
> 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?


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[rwild at gcc dot gnu dot org]

------- Comment #5 from rwild at gcc dot gnu dot org  2010-02-28 11:15 -------
(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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2010-02-28 10:59 -------
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 .


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ralf dot Wildenhues at gmx
                   |                            |dot de


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2010-02-24 23:07 -------
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.


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[hal at oz dot net]

------- Comment #2 from hal at oz dot net  2010-02-24 22:06 -------
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".


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-24 21:55 -------
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.


-- 


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