SPECjbb X86 validation failures

SPECjbb X86 validation failures

[Boehm, Hans]

I'm unfortunately still seeing problems with SPECjbb on X86 with gcc3.1.
These are apparently optimization failures.  They don't seem to be
correlated with the reload1.c ICEs that I mentioned earlier.

I know that:

- They occur at -O1 and -O2, but not at -O0.

- The result is incorrect code, which is detected by the SPECjbb validation
test.

- More than one file in SPECjbb is misoptimized as a result.

- They do not occur on IA64.

I've identified one file that's definitely being misoptimized (by binary
search).  Are there known techniques for systematically narrowing this down
further?  I'm looking for something like a list of optimization flags
implied by -O1 that I can toggle individually, and ideally a flag to turn
off optimization in all functions past line N, or something similar.

The underying problem here is that this is a fairly large body of code,
which I don't understand well.  Thus tracking down a bug is hard, and
tracking down a misoptimization is harder.

Thanks.

Hans

SPECjbb X86 validation failures

[Andrew Haley]

Boehm, Hans writes:
 > I'm unfortunately still seeing problems with SPECjbb on X86 with gcc3.1.
 > These are apparently optimization failures.  They don't seem to be
 > correlated with the reload1.c ICEs that I mentioned earlier.
 > 
 > I know that:
 > 
 > - They occur at -O1 and -O2, but not at -O0.
 > 
 > - The result is incorrect code, which is detected by the SPECjbb validation
 > test.
 > 
 > - More than one file in SPECjbb is misoptimized as a result.
 > 
 > - They do not occur on IA64.
 > 
 > I've identified one file that's definitely being misoptimized (by binary
 > search).  Are there known techniques for systematically narrowing this down
 > further?  I'm looking for something like a list of optimization flags
 > implied by -O1 that I can toggle individually, 

Use -fverbose-asm.  A list of all the optimizations applies is in the
asm file.

 > and ideally a flag to turn off optimization in all functions past
 > line N, or something similar.

Ah, that's much harder.  I guess you have a licence for SPECjbb and we
don't, so I can't look at it?

 > The underying problem here is that this is a fairly large body of code,
 > which I don't understand well.  Thus tracking down a bug is hard, and
 > tracking down a misoptimization is harder.

It is, and it takes time to understand how to fix optimizer bugs.

Andrew.