similar to: [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.ll It is interesting that I don't see this on my ARM box. Instead I see these: Failing

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

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/4312 Thanks!! > 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

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 ::

On Tue, Jan 8, 2013 at 8:31 PM, David Tweed <David.Tweed at arm.com> wrote: > 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

You can compare your configure/build arguments + environment with the build bot: http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4313/steps/configure/logs/stdio I'll check how I built my LLVM on Chromebook tomorrow, but it didn't look too different to yours. --renato On 8 January 2013 19:08, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Tue, Jan 8,

Moving to llvm-dev... On Jan 21, 2013, at 9:07 AM, Manish Verma <manish.verma at arm.com> wrote: > Hi Andy, > > I have been able track down the reason for the difference in output > generated by > opt. The difference is caused when the target triple specified in the > test-case > is not a supported target for opt/clang/llvm. In this case, opt doesn't thow > an

Moving to llvmdev... On Jan 21, 2013, at 11:37 AM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Manish, > > Thank you for looking at this. Recently opt started using the "-mtriple" command line flag to initialize the TargetMachine for IR-level transformations that use it. Currently only the following passes are using this feature: LSR, LowerSwitch, BBVectorizer and

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

CC llvm-dev ---------- Forwarded message ---------- Hello Duncan The size of ARM binaries created by clang has increased after r236642. Would you be able to find some time to look at my findings and share your thoughts about the problem, please? r236642 prevents emitting of temp label names into object files to save memory. This is fine, the label names do not appear in the resulting binaries.

On Jan 21, 2013, at 12:37 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 21, 2013 at 11:49 AM, Andrew Trick <atrick at apple.com> wrote: > Moving to llvmdev... > > On Jan 21, 2013, at 11:37 AM, Nadav Rotem <nrotem at apple.com> wrote: > > > Hi Manish, > > > > Thank you for looking at this. Recently opt started using the

Hi, I am new to LLVM I want to use llvm and clang on Android, I have downloaded android toolchain and did the configure for llvm using the following commad ./configure --build=arm-linux-androideabi --host=arm-linux-androideabi --target=arm-linux-androideabi --with-float=hard --with-fpu=neon --enable-targets=arm --enable-optimized --enable-assertions and was getting the error "checking

On 8 February 2013 14:28, David Given <dg at cowlark.com> wrote: > Debian's clang packages are totally broken on armhf --- the compiler > emits a confused warning about the platform being unrecognised, and then > generates softfloat code --- so I was wondering about LLVM itself. I'm using Ubuntu on Pandas and Chromebooks and LLVM itself behaves well, with the right set of

On 08/02/13 14:42, Renato Golin wrote: [...] > Can you paste the result of a "clang -v -mcpu=CPU file.c" on your box? I > want to see what are the arguments and the assembler/linker it's > choosing to use. What CPU are we talking about? The box itself is an Allwinner A10; armv7l. /proc/cpuinfo says it's got swp half thumb fastmult vfp edsp neon vfpv3. I've been

>> However, because the DefaultTargetTriple is armv6l-unknown-linux-gnueabihf, >> and llvm didn’t know about v6l, it would fail to match and canonicalize to armv6. >> I added the notion of v6l to llvm to address this. > > ARMv6l was definitely there once. I'm not sure what happened. > > I'm copying the ARM folks that did most of the recent changes in hope

A few days ago, I tried to change the optimization flag from -O0 to -O2 to speed up the execution of the application on Ubuntu/ARM 14.04 32 bit. When I compiled the source code with -O2 flag instead of -O0 flag, I could not run the application normally by getting always the segmentation fault. Here is debugging information with GDB command in case of that. As you can see, we could not execute

Renato Golin wrote: [...] > Try setting armv7a-unknown-linux-gnueabihf and see if it works better. No, that doesn't work either. [...] > JIT was never the forte of ARM and I haven't tried yet, but I doubt > it'll be any Debian misconfiguration. The whole architecture > configuration is a bit odd... Debian's clang packages are totally broken on armhf --- the compiler

On 28-04-13 13:23, LRN wrote: > On 28.04.2013 13:38, Erik de Castro Lopo wrote: >> I have tagged 1.3.0pre4 in git and provided a tarball here: >> >> http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz >> >> I have built and tested the git tree on: >> >> linux-x86_64 openbsd5-i386 freebsd5-i386 > i686-w64-mingw32 - builds correctly,

Viswanath Puttagunta wrote: > Can we please have review on RFCv2? We have quite a few optimizations > (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward > etc) that are in my pipeline that depend on this patch series being > accepted. So, trying to make progress on this... On an armv7l board running Ubuntu, you've broken the build with just --enable-intrinsics

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 ::