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
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
--- 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
--- 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
--- 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=gccview=revrev=160457
Log:
config:
PR bootstrap/43170
* tls.m4
--- 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
--- 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
--- 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.
--
--- 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
--- 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
--- 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
--- 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.
--- 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).
--
--- 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
--- 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
--- 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
--- 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;
--- 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.orig2010-06-03 13:05:23.0 -0400
+++ gcc-4.5.0/libgomp/configure 2010-06-03
--- 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
--- 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
--- 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=20822action=view)
config patch for test
config/tls.m4 - modified as per Jakub's suggestion
*/configure regenerated as necessary.
--- 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=20822action=view) [edit]
config patch for test
config/tls.m4 - modified as per Jakub's suggestion
--- 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
--- 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*.
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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).
--
--- 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]
--- 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
--- 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
--- 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 |
--- 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
--- 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
--- 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
--- 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=20814action=view)
adds some TLS torture tests to gcc.dg
Hm - the placeholder, temporary fix for EMUTLS doesn't appear to work with
--- 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
--- 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.
--
--- 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
--- 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
--- 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=20814action=view) [edit]
adds some TLS torture tests to gcc.dg
Hm - the placeholder, temporary fix for EMUTLS doesn't appear to
--- 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=20814action=view) [edit]
adds some TLS torture tests to gcc.dg
Hm - the placeholder, temporary fix
--- 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
--- 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
|
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
--- 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'
--- 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?
--
--- 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
--- 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
--- 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
--- 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,
N1) try a bootstrap on x86_64-apple-darwin10 with non-parallel make from a
clean directory?
I don't
--- 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
--- 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
--- 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
--- 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
--- 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
78 matches
Mail list logo
