On Dec 30, 2008, at 4:55 PM, Misha Brukman wrote:> 2008/12/30 Scott Michel <scottm at aero.org> > Not entirely sure how to categorize this particular problem, but it's > clearly platform test related: "grep -w" appears to operate > differently on the x86_64 linux buildbot versus my local Mac OS > 10.4.11 and Ubuntu x86_64. In the CellSPU's shift_ops.ll test case, > "grep -w shlh" returns the correct 9 expected occurances, whereas the > x86_64 buildbot finds 10. > > Does the asm output differ, or does grep output itself differ on > these two platforms, with the same asm input file? I just took > the .s output file from a run on an x86/Linux box, and tested it > with grep on multiple systems, including the ones you list, and they > all agree the answer is 9. > > Can you diff the assembly files generated on those two platforms > (though they should be identical, since llc specifies the > architecture)?Also, it's possible that you have a 32/64-bit issue in the CellSPU backend. Have you tried running llc built for a 64-bit host? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/7b6d4965/attachment.html>
Chris: No. It's a difference between grep on the x86_64 buildbot vs. the rest of the world, apparently. -scooter On Dec 30, 2008, at 5:12 PM, Chris Lattner wrote:> > On Dec 30, 2008, at 4:55 PM, Misha Brukman wrote: > >> 2008/12/30 Scott Michel <scottm at aero.org> >> Not entirely sure how to categorize this particular problem, but it's >> clearly platform test related: "grep -w" appears to operate >> differently on the x86_64 linux buildbot versus my local Mac OS >> 10.4.11 and Ubuntu x86_64. In the CellSPU's shift_ops.ll test case, >> "grep -w shlh" returns the correct 9 expected occurances, whereas the >> x86_64 buildbot finds 10. >> >> Does the asm output differ, or does grep output itself differ on >> these two platforms, with the same asm input file? I just took >> the .s output file from a run on an x86/Linux box, and tested it >> with grep on multiple systems, including the ones you list, and >> they all agree the answer is 9. >> >> Can you diff the assembly files generated on those two platforms >> (though they should be identical, since llc specifies the >> architecture)? > > Also, it's possible that you have a 32/64-bit issue in the CellSPU > backend. Have you tried running llc built for a 64-bit host? > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/d530f1fb/attachment.html>
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. 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. -scooter On Dec 30, 2008, at 5:12 PM, Chris Lattner wrote:> > On Dec 30, 2008, at 4:55 PM, Misha Brukman wrote: > >> 2008/12/30 Scott Michel <scottm at aero.org> >> Not entirely sure how to categorize this particular problem, but it's >> clearly platform test related: "grep -w" appears to operate >> differently on the x86_64 linux buildbot versus my local Mac OS >> 10.4.11 and Ubuntu x86_64. In the CellSPU's shift_ops.ll test case, >> "grep -w shlh" returns the correct 9 expected occurances, whereas the >> x86_64 buildbot finds 10. >> >> Does the asm output differ, or does grep output itself differ on >> these two platforms, with the same asm input file? I just took >> the .s output file from a run on an x86/Linux box, and tested it >> with grep on multiple systems, including the ones you list, and >> they all agree the answer is 9. >> >> Can you diff the assembly files generated on those two platforms >> (though they should be identical, since llc specifies the >> architecture)? > > Also, it's possible that you have a 32/64-bit issue in the CellSPU > backend. Have you tried running llc built for a 64-bit host? > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081230/2d9f7b69/attachment.html>
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
* Scott Michel:> 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.There have been issues the GNU libc regular expression code. Try running with "unset LANG" (or "LC_ALL=C") and see if it improves things. The problem is that the regexp code used to be unacceptably slow in multi-byte locales such as UTF-8, and the patch Debian applied to improve its speed wasn't 100% correct.