The following failures are consistent on buildbot (and my local box). The Clang one I think it's assuming an Intel box, the other two look like the FileCheck are not good enough. http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 Clang :: CodeGen/compound-assign-overflow.c LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/f0cea63a/attachment.html>
On Tue, Jan 8, 2013 at 5:04 AM, Renato Golin <renato.golin at linaro.org> wrote:> The following failures are consistent on buildbot (and my local box). > > The Clang one I think it's assuming an Intel box, the other two look like > the FileCheck are not good enough. > > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 > > Clang :: CodeGen/compound-assign-overflow.c > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.llUsually the best way to get traction on such things is to reply to the commit that caused the regression. Whoever broke things is usually more invested in making sure the change is solid (& doesn't get reverted). [slightly ranting point: Whoever owns this builder should be in a position of authority/autonomy with the project to be able to maintain their passing status. That means someone who cares about this bot should have the rights (both technically & culturally) to revert patches if it becomes necessary (an unco-operative committer). That's not to say that patches should be reverted without consideration or taking steps to help the author reproduce the issue. In the case of a test that's not platform agnostic & needs a triple, that should be easy/obvious & once notified the committer should be able to make the change quickly (or the bot maintainer can make such a commit (simply adding the triple that was assumed, or even generalizing the test to be neutral if that looks viable) & leave it to the original committer to choose an alternative fix when they have time.] - David
On 8 January 2013 16:44, David Blaikie <dblaikie at gmail.com> wrote:> Usually the best way to get traction on such things is to reply to the > commit that caused the regression. Whoever broke things is usually > more invested in making sure the change is solid (& doesn't get > reverted).Hi David, Good point. The build bot is broken for a while and I assumed the person who did that commit would spot it better than I would, but I shouldn't have assumed that the person would receive my email. I'll try to point the commit and re-send, copying the author. Sorry for the noise. --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/51df9b96/attachment.html>
On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote:> The following failures are consistent on buildbot (and my local box). > > The Clang one I think it's assuming an Intel box, the other two look like > the FileCheck are not good enough. > > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 > > Clang :: CodeGen/compound-assign-overflow.cr171853 for this one. Build not finished yet. http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4312> LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.llLooks like a better regex can fix this. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
On 8 January 2013 17:01, Dmitri Gribenko <gribozavr at gmail.com> wrote:> r171853 for this one. Build not finished yet. > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4312Thanks!!> LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > > Looks like a better regex can fix this. >I think both of them are just bad FileChecks... This is the first build that fails: http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4294 And they haven't introduced the tests... Most of them are debug, there's a mips change, and one "test" change: http://llvm.org/viewvc/llvm-project/?view=rev&revision=171705 --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130108/bf757378/attachment.html>
On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote:> The following failures are consistent on buildbot (and my local box).[...]> LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.llIt is interesting that I don't see this on my ARM box. Instead I see these: Failing Tests (5): LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/pr13727.ll LLVM :: ExecutionEngine/MCJIT/test-common-symbols.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs.ll LLVM :: ExecutionEngine/MCJIT/test-fp.ll I configure with: --build=armv7l-unknown-linux-gnueabihf --host=armv7l-unknown-linux-gnueabihf --target=armv7l-unknown-linux-gnueabihf --with-cpu=cortex-a9 --with-fpu=neon --with-float=hard --enable-optimized $ cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS : 1992.29 processor : 1 BogoMIPS : 1992.29 Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 0 Any ideas? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
The obvious difference is that you're using --enable-optimized and implicitly --disable-assertions. If you run the tests with make check-all VERBOSE=1 'LIT_ARGS=-v ' > logfile and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in a Release-Asserts build it might not.) Cheers, Dave -----Original Message----- From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Dmitri Gribenko Sent: 08 January 2013 18:16 To: Renato Golin Cc: Clang Dev; LLVM Dev Subject: Re: [cfe-dev] [LLVMdev] ARM failures On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote:> The following failures are consistent on buildbot (and my local box).[...]> LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.llIt is interesting that I don't see this on my ARM box. Instead I see these: Failing Tests (5): LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/pr13727.ll LLVM :: ExecutionEngine/MCJIT/test-common-symbols.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs.ll LLVM :: ExecutionEngine/MCJIT/test-fp.ll I configure with: --build=armv7l-unknown-linux-gnueabihf --host=armv7l-unknown-linux-gnueabihf --target=armv7l-unknown-linux-gnueabihf --with-cpu=cortex-a9 --with-fpu=neon --with-float=hard --enable-optimized $ cat /proc/cpuinfo Processor : ARMv7 Processor rev 0 (v7l) processor : 0 BogoMIPS : 1992.29 processor : 1 BogoMIPS : 1992.29 Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 0 Any ideas? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ _______________________________________________ cfe-dev mailing list cfe-dev at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.