http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #29 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-05-02
14:06:52 UTC ---
Author: uweigand
Date: Mon May 2 14:06:48 2011
New Revision: 173252
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173252
Log:
2011-05-02 Ulrich
--- Comment #27 from bernds at gcc dot gnu dot org 2010-04-29 11:04 ---
Subject: Bug 43858
Author: bernds
Date: Thu Apr 29 11:04:30 2010
New Revision: 158898
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158898
Log:
From Dominique d'Humieres domi...@lps.ens.fr
PR
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-04-29 15:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-28 08:50 ---
Two questions - are you sure you didn't reverse the _w and _f files (i.e.
maybe
_f is the working version and _w the failing one)?
I have looked at how I have generated the archive and I don't think so.
I'll
--- Comment #20 from dominiq at lps dot ens dot fr 2010-04-28 08:54 ---
I have forgotten to ask my question! Could it be a similar issue to that you
fixed for pr42220?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #21 from dominiq at lps dot ens dot fr 2010-04-28 13:19 ---
Two questions - are you sure you didn't reverse the _w and _f files (i.e.
maybe
_f is the working version and _w the failing one)?
I have double checked and I confirm that the *_f.* files are coming from the
--- Comment #22 from bernds at codesourcery dot com 2010-04-28 13:59
---
(In reply to comment #20)
I have forgotten to ask my question! Could it be a similar issue to that you
fixed for pr42220?
No, that looks completely unrelated at first glance.
--
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-04-28
16:50 ---
Dominique,
Are you saying you regression hunted and this was triggered by...
Author: bernds
Date: Thu Apr 22 11:47:52 2010
New Revision: 158643
URL:
--- Comment #24 from dominiq at lps dot ens dot fr 2010-04-28 17:07 ---
Are you saying you regression hunted and this was triggered by...
Author: bernds
Date: Thu Apr 22 11:47:52 2010
New Revision: 158643
No. If you read the thread, it was due to revision 158639 (see comment #6).
--- Comment #25 from dominiq at lps dot ens dot fr 2010-04-28 19:27 ---
The following change applied on top of revision 158827 is enough to reach stage
3 (and probably to bootstrap -answer tomorrow):
--- ../_gcc_clean/gcc/ifcvt.c 2010-04-22 13:23:31.0 +0200
+++
--- Comment #26 from bernds at codesourcery dot com 2010-04-28 19:33
---
Ah! I think that makes sense. For some reason I only looked at the other use of
df_simulate_find_noclobber_defs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #14 from dominiq at lps dot ens dot fr 2010-04-27 09:38 ---
If the testsuite run produces nothing, can you check the object files of the
two stage2 compilers (working and broken) for differences in code generation?
That could help narrow down which file is being
--- Comment #15 from bernds at gcc dot gnu dot org 2010-04-27 09:47 ---
Thanks. Could you attach those object files (ignoring ifcvt.o since it
obviously changes due to the source change)?
Even better would be if you could produce assembly output by finding the
command that produced
--- Comment #16 from dominiq at lps dot ens dot fr 2010-04-27 15:24 ---
Thanks. Could you attach those object files (ignoring ifcvt.o since it
obviously changes due to the source change)?
Even better would be if you could produce assembly output by finding the
command that
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-27 15:27 ---
Created an attachment (id=20499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20499action=view)
bziped tar file containing the *.i and *.s files
The *_f.* files corresponds to the failing bootstrap and the
--- Comment #18 from bernds at gcc dot gnu dot org 2010-04-27 22:27 ---
Thanks for all the information. However, I'm still puzzled. Here's the
situation.
Thanks to your information, I think I can reproduce how the assembly files are
generated:
./cc1 -feliminate-unused-debug-symbols
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-26 09:16 ---
This PR is likely due to revision 158639:
Author: bernds
Date: Thu Apr 22 10:42:21 2010 UTC (3 days, 22 hours ago)
Changed paths: 4
Log Message:
* ifcvt.c (dead_or_predicable): Use
--- Comment #7 from bernds at codesourcery dot com 2010-04-26 12:11 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs in
ifcvt.c with a call to df_simulate_find_defs? If that fixes the bootstrap, can
you find a testcase where this changes code generation?
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-26 12:28 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
the
--- Comment #9 from bernds at codesourcery dot com 2010-04-26 12:56 ---
One thing that would help would be to build just a stage1 compiler and target
libraries, then run the testsuite. That might give us a smaller testcase to
look at.
--
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-26 13:15 ---
Subject: Re: [4.6 Regression] Bootstrap failure for
powerpc-apple-darwin9: cannot compute suffix of object files
One thing that would help would be to build just a stage1 compiler and target
libraries, then run
--- Comment #11 from bernds at codesourcery dot com 2010-04-26 13:19
---
(In reply to comment #10)
Subject: Re: [4.6 Regression] Bootstrap failure for
powerpc-apple-darwin9: cannot compute suffix of object files
One thing that would help would be to build just a stage1 compiler
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-26 16:24 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs
in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
--- Comment #13 from bernds at codesourcery dot com 2010-04-26 22:54
---
I've tried the two versions of ifcvt.c with a powerpc-apple-darwin9 cross
compiler. Out of many megabytes of testcases, I can find only one code
generation difference with -O2 -fomit-frame-pointer for this
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-25 14:31 ---
can you provide a backtrace of this crash ?
Putting a breakpoint at fancy_abort is not enough to get a backtrace:
[karma] gcc/darwin_buildw% gdb /opt/gcc/darwin_buildw/./gcc/xgcc
GNU gdb 6.3.50-20050815 (Apple
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-25 14:39
---
Putting a breakpoint at fancy_abort is not enough to get a backtrace:
Because you aren't debugging the right executable (xgcc instead of cc1). Pass
-v to the driver to get the command line involving cc1 and
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-25 15:39 ---
Because you aren't debugging the right executable (xgcc instead of cc1). Pass
-v to the driver to get the command line involving cc1 and feed it to cc1
directly.
Thanks for the tip. The backtrace is
Program
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-23 22:08 ---
PR 43873 looks similar to this pr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #2 from lacombar at gmail dot com 2010-04-23 22:15 ---
can you provide a backtrace of this crash ? What is the version of the system
compiler used for that build ?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
30 matches
Mail list logo
