Re: bootstrap failure on darwin, compare stages

Re: bootstrap failure on darwin, compare stages

[mike stump]

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

Re: bootstrap failure on darwin, compare stages

[mike stump]

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

Re: bootstrap failure on darwin, compare stages

[Andreas Tobler]

"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

Re: bootstrap failure on darwin, compare stages

[Billinghurst, David (CRTS)]

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

Re: bootstrap failure on darwin, compare stages

[Andreas Tobler]

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

Re: bootstrap failure on darwin, compare stages

[Andreas Tobler]

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

Re: bootstrap failure on darwin, compare stages

[Dale Johannesen]

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

Re: bootstrap failure on darwin, compare stages

[Dale Johannesen]

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.

Re: bootstrap failure on darwin, compare stages

[Andreas Tobler]

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

Re: bootstrap failure on darwin, compare stages

[Andreas Tobler]

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

Re: bootstrap failure on darwin, compare stages

[Dale Johannesen]

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.

Re: bootstrap failure on darwin, compare stages

[David Edelsohn]

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

bootstrap failure on darwin, compare stages

[Andreas Tobler]

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