[LLVMdev] "grep -w" irregularity

[Daniel Berlin]

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>