[llvm-testresults] buildbot failure in llvm on llvm-gcc-x86_64-linux-selfhost

[Jakob Stoklund Olesen]

On Jan 9, 2011, at 11:37 PM, Chris Lattner wrote:

> 
> On Jan 9, 2011, at 9:43 PM, Evan Cheng wrote:
> 
>> That didn't seem to help. :(
> 
> I've disabled all of the commits that were included in this build:
> http://google1.osuosl.org:8011/builders/llvm-gcc-i386-linux-selfhost/builds/554
> 
> Still no go.  I'm pretty sure that the current part is a Jakob issue.  The llvm-gcc-i386-linux-selfhost has been consistently failing.

The llvm-gcc-x86_64-linux-selfhost bot is failing with the same sched-vis.o miscompare, but it is not as frequently. I think both failures are stochastic, but with different probabilities.

>  Here's the series of events as I see it:
> 
> Build 554: has r123086,7,9.  These introduce a build failure causing an assertion:
> Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
> 
> Build 555: has 90,91.  These fix the build failure, but there is still a miscompile.  With the miscompile I get a *stage 2* miscomparison of sched-vis.o
> 
> Build 556: Has a strongphi patch, a clang patch, and a bunch of Jakob patches.  With these patches we still have a sched-vis.o miscompare, but now it is in *stage 1*, which is earlier.
> 
> Build 582 and other recent ones: I've disabled the patches from r123086,7,9 because I assume that they either include or expose a latent miscompile that the fixes in 555 weren't enough to cover for.  Despite that, we still have the sched-vis.o in *stage 1*.
> 
> Jakob, are you sure that none of the patches in 556 could have caused an issue?  While I agree that there is weirdness on some builders, the llvm-gcc-i386-linux-selfhost builder has been really consistent.

It is certainly possible that I introduced a miscompilation.

Those patches we not supposed to change code generation at all, so I would have expected more spectacular failures from them. A miscompare is quite subtle.

I would have preferred miscompilations from r123137 where I actually changed the virtual register numbering. That could shake things up.

This is only happening on Linux, right? Is that because of ASLR?

Anyway, I will try to reproduce. I think we need to look at those differing .o files.

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-testresults/attachments/20110110/22c2cacc/attachment.bin>