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.
I've attached the .s file it produces in case you want to file a bug against grep. On Tue, Dec 30, 2008 at 10:36 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> 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. >-------------- next part -------------- A non-text attachment was scrubbed... Name: bugingrep Type: application/octet-stream Size: 6702 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/8b7d1b2c/attachment.obj>
Also, it only happens with the locale set to en_US.UTF-8 (default on ubuntu 8.04), but it's still a bug even in a utf-8 locale since both shlh's are followed immediately by i, which are not "non-word constituent characters". On Tue, Dec 30, 2008 at 10:38 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> I've attached the .s file it produces in case you want to file a bug > against grep. > > On Tue, Dec 30, 2008 at 10:36 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> 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. >> >
>> >> 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.Thanks DannyB! Scott, I guess this means we should avoid grep -w :( -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/26b8bfb0/attachment.html>
I reckon that's probably a good idea. I haven't filed a bug report against a GNU tool in years. -scooter On Dec 30, 2008, at 7:38 PM, Daniel Berlin wrote:> I've attached the .s file it produces in case you want to file a bug > against grep.