* bootstrap failure on darwin, compare stages @ 2001-09-21 12:47 Andreas Tobler 2001-09-21 12:56 ` David Edelsohn 2001-09-21 12:57 ` Dale Johannesen 0 siblings, 2 replies; 13+ messages in thread From: Andreas Tobler @ 2001-09-21 12:47 UTC (permalink / raw) To: GCC Hi all, since yesterday bootstrapping fails on darwin. My question is not 'what is the fix' I'd like to know how to track down the problem. Unfortunately the trapping fails in the stage of comparing the stage 1 with 2. The failing part is insn-emit.o which differs. How can I find out what's going wrong? Any advice is highly appreciated. Thanks Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 12:47 bootstrap failure on darwin, compare stages Andreas Tobler @ 2001-09-21 12:56 ` David Edelsohn 2001-09-21 13:21 ` Andreas Tobler ` (2 more replies) 2001-09-21 12:57 ` Dale Johannesen 1 sibling, 3 replies; 13+ messages in thread From: David Edelsohn @ 2001-09-21 12:56 UTC (permalink / raw) To: toa; +Cc: GCC >>>>> Andreas Tobler writes: Andreas> since yesterday bootstrapping fails on darwin. My question is not 'what Andreas> is the fix' I'd like to know how to track down the problem. Andreas> Unfortunately the trapping fails in the stage of comparing the stage 1 Andreas> with 2. The failing part is insn-emit.o which differs. How can I find Andreas> out what's going wrong? The first thing is to disassemble the object files or recompile the source into assembly output with the two different stage compilers. Then see what differs between the two files. I have been seeing stage compare failures for GCC on AIX ever since the conversion of HOST_WIDE_INT to "long long" for 64-bit targets built on 32-bit hosts. The problem never produces incorrect code, but something non-deterministic is occurring in the compiler. The example of the comparison failure on AIX is one assembly file duplicating a TOC entry while the other file re-uses the old entry through an alias. It seems like something not hashing to the same value or some wild write, but I and others have not been able to track it down after looking all Summer. David ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 12:56 ` David Edelsohn @ 2001-09-21 13:21 ` Andreas Tobler 2001-09-21 14:06 ` Dale Johannesen 2001-09-22 11:16 ` Andreas Tobler 2 siblings, 0 replies; 13+ messages in thread From: Andreas Tobler @ 2001-09-21 13:21 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC David Edelsohn wrote: > The first thing is to disassemble the object files or recompile > the source into assembly output with the two different stage compilers. > Then see what differs between the two files. David, others I'd thank you for the direction. Sometimes I'm jealous that you got a job covering topics on gcc and others. I go on tomorrow. Including my shity ASN1 stuff. BTW, ASN1 is also mentioned on gnu. still alive? > I have been seeing stage compare failures for GCC on AIX ever > since the conversion of HOST_WIDE_INT to "long long" for 64-bit targets > built on 32-bit hosts. The problem never produces incorrect code, but > something non-deterministic is occurring in the compiler. The example of > the comparison failure on AIX is one assembly file duplicating a TOC entry > while the other file re-uses the old entry through an alias. It seems > like something not hashing to the same value or some wild write, but I and > others have not been able to track it down after looking all Summer. Maybe you need the 'herbst' as well ;-)) CHeers & thx Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 12:56 ` David Edelsohn 2001-09-21 13:21 ` Andreas Tobler @ 2001-09-21 14:06 ` Dale Johannesen 2001-09-22 11:16 ` Andreas Tobler 2 siblings, 0 replies; 13+ messages in thread From: Dale Johannesen @ 2001-09-21 14:06 UTC (permalink / raw) To: David Edelsohn; +Cc: Dale Johannesen, toa, GCC On Friday, September 21, 2001, at 12:56 PM, David Edelsohn wrote: > I have been seeing stage compare failures for GCC on AIX ever > since the conversion of HOST_WIDE_INT to "long long" for 64-bit targets > built on 32-bit hosts. The problem never produces incorrect code, but > something non-deterministic is occurring in the compiler. The example of > the comparison failure on AIX is one assembly file duplicating a TOC entry > while the other file re-uses the old entry through an alias. It seems > like something not hashing to the same value or some wild write, but I and > others have not been able to track it down after looking all Summer. FWIW, I've never seen this on Darwin (32/32), and nobody else has reported it. So it's in the 64-bit-specific part, but you probably knew that. Could be you're treating a 32-bit value as 64 somewhere, thus picking up 32 random bits. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 12:56 ` David Edelsohn 2001-09-21 13:21 ` Andreas Tobler 2001-09-21 14:06 ` Dale Johannesen @ 2001-09-22 11:16 ` Andreas Tobler 2 siblings, 0 replies; 13+ messages in thread From: Andreas Tobler @ 2001-09-22 11:16 UTC (permalink / raw) To: David Edelsohn; +Cc: GCC David Edelsohn wrote: > > >>>>> Andreas Tobler writes: > > Andreas> since yesterday bootstrapping fails on darwin. My question is not 'what > Andreas> is the fix' I'd like to know how to track down the problem. > Andreas> Unfortunately the trapping fails in the stage of comparing the stage 1 > Andreas> with 2. The failing part is insn-emit.o which differs. How can I find > Andreas> out what's going wrong? > > The first thing is to disassemble the object files or recompile > the source into assembly output with the two different stage compilers. > Then see what differs between the two files. Well, I built the failing file with different cc's and I get a diff. Now I'm stuck, how to go on? I used the -S switch to produce assembly output. Then I diffed. Here an excerpt: --- insn-emit.s.s1 Sat Sep 22 19:58:23 2001 +++ insn-emit.s.s2 Sat Sep 22 20:00:16 2001 @@ -18255,13 +18255,13 @@ .stabs "operand2:P(10,1)",64,0,7288,29 .stabs "_val:r(10,1)",64,0,7290,30 .stabn 192,0,0,LBB230 - .stabs "operands:(0,28)",128,0,7293,56 + .stabs "operands:(0,30)=ar(14,33);0;2;(10,1)",128,0,7293,56 .stabn 192,0,0,LBB231 .stabn 224,0,0,LBE231 .stabn 224,0,0,LBE230 .stabs "_val:r(10,1)",64,0,7290,30 .stabn 192,0,0,LBB232 - .stabs "operands:(0,28)",128,0,7293,56 + .stabs "operands:(0,30)",128,0,7293,56 It goes on, the pattern is always the same: either the operand is 1 or 2 digits up or it uses 'ar'. Sorry if too basic.... Thanks, Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 12:47 bootstrap failure on darwin, compare stages Andreas Tobler 2001-09-21 12:56 ` David Edelsohn @ 2001-09-21 12:57 ` Dale Johannesen 2001-09-21 13:21 ` Andreas Tobler 1 sibling, 1 reply; 13+ messages in thread From: Dale Johannesen @ 2001-09-21 12:57 UTC (permalink / raw) To: toa; +Cc: Dale Johannesen, GCC On Friday, September 21, 2001, at 12:37 PM, Andreas Tobler wrote: > Hi all, > > since yesterday bootstrapping fails on darwin. My question is not 'what > is the fix' I'd like to know how to track down the problem. > Unfortunately the trapping fails in the stage of comparing the stage 1 > with 2. The failing part is insn-emit.o which differs. How can I find > out what's going wrong? I usually approach it this way: Get a "good" compiler (built with cc, usually) and the "bad" (stage2) compiler. Compile the file that differs with both compilers using -da. Compare the dump files to get some idea what phase the problem is in. Step through the compilers in parallel with the debugger, to find the place where the bad code is. I haven't bootstrapped recently, I'll try it now. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 12:57 ` Dale Johannesen @ 2001-09-21 13:21 ` Andreas Tobler 2001-09-21 14:37 ` Dale Johannesen 0 siblings, 1 reply; 13+ messages in thread From: Andreas Tobler @ 2001-09-21 13:21 UTC (permalink / raw) To: Dale Johannesen; +Cc: GCC Dale Johannesen wrote: > I usually approach it this way: > Get a "good" compiler (built with cc, usually) and the "bad" (stage2) > compiler. > Compile the file that differs with both compilers using -da. -da ? > Compare the dump files to get some idea what phase the problem is in. -v 'make -s file with asm output' (don't know the switch right now.)? > Step through the compilers in parallel with the debugger, to find the place > where the bad code is. I don't like to say this, but with gdb I have my probs, I remember vc++, sorry. I find it easier to dbg a file which fails than a comparison stage. Here I'm unsure who/what is responsible for. > I haven't bootstrapped recently, I'll try it now. Good luck Andreas and thx!! ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 13:21 ` Andreas Tobler @ 2001-09-21 14:37 ` Dale Johannesen 2001-09-22 6:27 ` Andreas Tobler 0 siblings, 1 reply; 13+ messages in thread From: Dale Johannesen @ 2001-09-21 14:37 UTC (permalink / raw) To: toa; +Cc: Dale Johannesen, GCC > Dale Johannesen wrote: > >> I usually approach it this way: >> Get a "good" compiler (built with cc, usually) and the "bad" (stage2) >> compiler. >> Compile the file that differs with both compilers using -da. > > -da ? Creates a bunch of dump files containing rtl of intermediate stages. >> Compare the dump files to get some idea what phase the problem is in. > > -v 'make -s file with asm output' (don't know the switch right now.)? -S >> Step through the compilers in parallel with the debugger, to find the >> place >> where the bad code is. > > I don't like to say this, but with gdb I have my probs, I remember vc++, > sorry. > I find it easier to dbg a file which fails than a comparison stage. Here > I'm unsure who/what is responsible for. Your choice, I'm happy with gdb. Yes, you have to walk through a lot of code where you don't understand what's going on, but that's how you learn :) >> I haven't bootstrapped recently, I'll try it now. Bad news: it works fine for me. (I've got a couple of local modifications involving scheduling, but it's wildly unlikely that fixed the bootstrap.) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-21 14:37 ` Dale Johannesen @ 2001-09-22 6:27 ` Andreas Tobler 0 siblings, 0 replies; 13+ messages in thread From: Andreas Tobler @ 2001-09-22 6:27 UTC (permalink / raw) To: Dale Johannesen; +Cc: GCC Dale Johannesen wrote: > >> I haven't bootstrapped recently, I'll try it now. > > Bad news: it works fine for me. (I've got a couple of local > modifications involving scheduling, but it's wildly unlikely that fixed > the bootstrap.) The gnu one? Not for me, now parse.o from java and the insn-emit.o differs. The switches mentioned above spit very much code to investigate .... Thanks, Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages @ 2001-09-22 20:25 Billinghurst, David (CRTS) 2001-09-23 4:52 ` Andreas Tobler 0 siblings, 1 reply; 13+ messages in thread From: Billinghurst, David (CRTS) @ 2001-09-22 20:25 UTC (permalink / raw) To: 'toa@pop.agri.ch'; +Cc: 'gcc@gcc.gnu.org' Andreas, I see a similar problem on irix6.5 and i686-pc-cygwin. See http://gcc.gnu.org/ml/gcc-bugs/2001-09/msg00636.html . You could confirm that the same patch triggers your problem. If so, the code that it touches may be responsible for the problem. Of course, they problem may be a latent bug elsewhere. +++++++++++++++++++++++++++++++++++++++++ (Mr) David Billinghurst Comalco Research Centre PO Box 316, Thomastown, Vic, Australia, 3074 Phone: +61 3 9469 0642 FAX: +61 3 9462 2700 Email: David.Billinghurst@riotinto.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages 2001-09-22 20:25 Billinghurst, David (CRTS) @ 2001-09-23 4:52 ` Andreas Tobler 0 siblings, 0 replies; 13+ messages in thread From: Andreas Tobler @ 2001-09-23 4:52 UTC (permalink / raw) To: Billinghurst, David (CRTS); +Cc: 'gcc@gcc.gnu.org' "Billinghurst, David (CRTS)" wrote: > I see a similar problem on irix6.5 and i686-pc-cygwin. See > http://gcc.gnu.org/ml/gcc-bugs/2001-09/msg00636.html . You could confirm > that the same patch triggers your problem. If so, the code that it touches > may be responsible for the problem. Of course, they problem may be a latent > bug elsewhere. Yup, I can confirm! Reverting this patch makes my todays sinced cvs bootstrap again. Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages @ 2001-09-24 13:30 mike stump 0 siblings, 0 replies; 13+ messages in thread From: mike stump @ 2001-09-24 13:30 UTC (permalink / raw) To: David.Billinghurst, toa; +Cc: gcc > Date: Sun, 23 Sep 2001 13:50:35 +0200 > From: Andreas Tobler <toa@pop.agri.ch> > "Billinghurst, David (CRTS)" wrote: > > > I see a similar problem on irix6.5 and i686-pc-cygwin. See > > http://gcc.gnu.org/ml/gcc-bugs/2001-09/msg00636.html . You could confirm > > that the same patch triggers your problem. If so, the code that it touches > > may be responsible for the problem. Of course, they problem may be a latent > > bug elsewhere. > Yup, I can confirm! Reverting this patch makes my todays sinced cvs > bootstrap again. Just a quick note. Any internal piece of data that can vary between hosts cannot be used to make code decisions in the compiler. For example, you cannot use the address of a piece of data (rtx) to compute a value in a hash table and then use the `first' entry in the hash table to canonicalize the value. This would be wrong. One _can_ take the CODE and/or the value of a CONST_INT and use those to build a hash table index however. Only `new' code in the compiler is so broken, as in the past, we have ensured that this was not the case. Any code like this needs to be tracked down, understood and fixed. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bootstrap failure on darwin, compare stages @ 2001-09-24 14:56 mike stump 0 siblings, 0 replies; 13+ messages in thread From: mike stump @ 2001-09-24 14:56 UTC (permalink / raw) To: gcc, toa > Date: Fri, 21 Sep 2001 21:37:15 +0200 > From: Andreas Tobler <toa@pop.agri.ch> > since yesterday bootstrapping fails on darwin. My question is not > 'what is the fix' I'd like to know how to track down the problem. > Unfortunately the trapping fails in the stage of comparing the stage > 1 with 2. The failing part is insn-emit.o which differs. How can I > find out what's going wrong? One tool that can be used, no matter the problem difficultly or user experience is cvs binary searching. One can do a dated checkout and then move forwards for backwards in time to try and find the transition points for the problem they are interested in. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2001-09-24 14:56 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-09-21 12:47 bootstrap failure on darwin, compare stages Andreas Tobler 2001-09-21 12:56 ` David Edelsohn 2001-09-21 13:21 ` Andreas Tobler 2001-09-21 14:06 ` Dale Johannesen 2001-09-22 11:16 ` Andreas Tobler 2001-09-21 12:57 ` Dale Johannesen 2001-09-21 13:21 ` Andreas Tobler 2001-09-21 14:37 ` Dale Johannesen 2001-09-22 6:27 ` Andreas Tobler 2001-09-22 20:25 Billinghurst, David (CRTS) 2001-09-23 4:52 ` Andreas Tobler 2001-09-24 13:30 mike stump 2001-09-24 14:56 mike stump
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).