On Dec 30, 2008, at 5:24 PM, Scott Michel wrote:> Chris: > > On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an > unexpected success (i.e., "grep -w shlh %t1.s | count 9" succeeds.) > > I get the same unexpected success on my x86_64 Mac 10.4.11. > > On the x86_64 buildbot, the same test fails. The culprit is grep, > evidently. It's just that simple.Not necessarily. That builder could be getting a different .s file from LLC.> I suspect there's not really an issue with endianness, since all the > test does is (a) generate code using the backend, (b) grep's for > certain instructions. Nothing is actually executed.LLC is still run. If there is a bug in the code generator, it could easily manifest itself this way. 32/64-bit portability issues, buffer overruns and other undefined behavior could easily cause this sort of thing. Please ask the owner of that builder nicely to send you the .s file that it is producing. If it is identical to the one you get then I'll believe it is a grep difference, but that doesn't sound like the most likely issue. -Chris
On Dec 30, 2008, at 5:47 PM, Chris Lattner wrote:> > On Dec 30, 2008, at 5:24 PM, Scott Michel wrote: > >> Chris: >> >> On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an >> unexpected success (i.e., "grep -w shlh %t1.s | count 9" succeeds.) >> >> I get the same unexpected success on my x86_64 Mac 10.4.11. >> >> On the x86_64 buildbot, the same test fails. The culprit is grep, >> evidently. It's just that simple. > > Not necessarily. That builder could be getting a different .s file > from LLC.Given that I have an x86_64 machine here and the buildbot is x86_64, and given that my local x86_64 machine "unexpectedly" succeeds, I'm less inclined to suspect LLC at this point. Granted, I'm probably not running the same Linux distribution that the buildbot is running. But still, my local Linux x86_64 box succeeds where the buildbot fails, using the same svn version (i.e., no diffs between the LLVM repo and my local copy.)>> LLC is still run. If there is a bug in the code generator, it could > easily manifest itself this way. 32/64-bit portability issues, buffer > overruns and other undefined behavior could easily cause this sort of > thing. Please ask the owner of that builder nicely to send you the .s > file that it is producing. If it is identical to the one you get then > I'll believe it is a grep difference, but that doesn't sound like the > most likely issue.I'd be completely shocked if llc were _not_ run, since the test invokes it. I'll contact the buildbot owner -- maybe it's something funky between Linux distributions (oh, now there's a total surprise!) -scooter
On Tue, Dec 30, 2008 at 8:59 PM, Scott Michel <scottm at aero.org> wrote:> On Dec 30, 2008, at 5:47 PM, Chris Lattner wrote: >> >> On Dec 30, 2008, at 5:24 PM, Scott Michel wrote: >> >>> Chris: >>> >>> On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an >>> unexpected success (i.e., "grep -w shlh %t1.s | count 9" succeeds.) >>> >>> I get the same unexpected success on my x86_64 Mac 10.4.11. >>> >>> On the x86_64 buildbot, the same test fails. The culprit is grep, >>> evidently. It's just that simple. >> >> Not necessarily. That builder could be getting a different .s file >> from LLC. > > Given that I have an x86_64 machine here and the buildbot is x86_64, > and given that my local x86_64 machine "unexpectedly" succeeds, I'm > less inclined to suspect LLC at this point. > > Granted, I'm probably not running the same Linux distribution that > the buildbot is running. But still, my local Linux x86_64 box > succeeds where the buildbot fails, using the same svn version (i.e., > no diffs between the LLVM repo and my local copy.)The buildbot is running 8.04 of ubuntu. This actually does appear to be a bug in grep. The grep -w command on the buildbot produces the following output: shlh $3, $3, $4 shlh $3, $4, $3 shlh $3, $3, $4 shlh $3, $4, $3 shlh $3, $3, $4 shlh $3, $4, $3 shlh $3, $4, $3 shlh $3, $4, $3 .size shlhi_i16_7,.-shlhi_i16_7 shlh $3, $4, $3 man grep says the following for -w: -w, --word-regexp Select only those lines containing matches that form whole words. The test is that the matching substring must either be at the beginning of the line, or preceded by a non-word constituent character. Similarly, it must be either at the end of the line or followed by a non-word constituent character. Word-constituent characters are letters, digits, and the underscore. Clearly, it does not match the ending criteria since neither of the matches on the .size line are followed by non-word constituent characters or eol.
On Dec 30, 2008, at 5:47 PM, Chris Lattner wrote:> > On Dec 30, 2008, at 5:24 PM, Scott Michel wrote: > >> Chris: >> >> On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an >> unexpected success (i.e., "grep -w shlh %t1.s | count 9" succeeds.) >> >> I get the same unexpected success on my x86_64 Mac 10.4.11. >> >> On the x86_64 buildbot, the same test fails. The culprit is grep, >> evidently. It's just that simple. > > Not necessarily. That builder could be getting a different .s file > from LLC.Even a broken clock is right twice a day? (Me being the broken clock. :-) -scooter