similar to: [LLVMdev] Clang incompatible with GCC on Linux + ARM Cortex-A9

Hello Irune, I tried to reproduce your command line options on a simple c file containing some floating point instructions using the clang-3.8 binary I have on my Ubuntu 16.04 machine with ARM_SYSROOT and ARM_GCC_TOOLCHAIN configured to point at a Linaro Hard float toolchain and clang used the hard float abi as expected. My clang-3.8 also accepted -mfloat-abi=hard. With my gcc toolchain the

Hello list, I have some problems using LLVM version 3.8.0 to cross-compile code for ARM Cortex-A9 on x86. I am trying to generate LLVM IR using Clang: clang -S --emit-llvm --target=armv7a-linux-gnueabihf --sysroot=$(ARM_SYSROOT) --gcc-toolchain=$(ARM_GCC_TOOLCHAIN) -c -o translated.ll But somehow clang it is trying to use soft-float and I get the following error: 'gnu/stubs-soft.h' file

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

On 8 February 2013 21:42, David Given <dg at cowlark.com> wrote: > The box itself is an Allwinner A10; armv7l. /proc/cpuinfo says it's got > swp half thumb fastmult vfp edsp neon vfpv3. > Yes, it's a Cortex-A8. I've been unable to find any values for CPU which are accepted (it just > says 'unknown target CPU'. I've tried arm, armv7, armv7a, armv7l,

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

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

Hello, I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have our own gcc compiler that we build with crosstools-ng (based on gcc 6.3.0) and I set my environment like this: CC=armv7a-plex-linux-gnueabihf-gcc CXX=armv7a-plex-linux-gnueabihf-g++ CFLAGS=-fPIC -DPIC -mfloat-abi=hard -march=armv7-a -Os -mfpu=vfpv3-d16 --sysroot=<path> CXXFLAGS=-fPIC -DPIC

Hello list I think I really finally found a way to crossbuild a binary for ARM using Clang/llvm. This message would be a documentation for someone who may concern for the same issue with me. - Target : TOSHIBA AC100 / Ubuntu 12.04 (https://wiki.ubuntu.com/ARM/** TEGRA/AC100 <https://wiki.ubuntu.com/ARM/TEGRA/AC100>) - Host : i386 Desktop PC / Ubuntu 12.04 - Toolchain on host : sudo

Hello Dimitry and thanks for your answer. I am pretty sure it does indeed support long double. It's configured with vfpv3-d16 - but I noticed that c++config.h in gcc has _GLIBCXX__HAS_FABSL and friends are undefined. I think I need to look deeper at the configuration of our toolchain. long double support is required in libc++ then I gather? -- Tobias On Tue, Feb 6, 2018 at 11:47 AM,

Hi Suyog, > I tested it on A15, i don't have access to A8 rightnow, but i intend to test > it for A8 as well. That's extremely dodgy, the two processors are very different. > I don't think i > will get A8 hardware soon, can someone please check it on A8 hardware as > well (Sorry for the trouble)? I've got a BeagleBone hanging around, and tested Clang against a

At first glance, it looks like long double functions (such as fabsl and friends) are missing from your sysroot's <math.h>. Does your target support long double at all? -Dimitry > On 6 Feb 2018, at 09:51, Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have

> I filled this problem a while ago here http://llvm.org/bugs/show_bug.cgi?id=13111 > Thinking it first was an LLVM opt bug. Shall I assign it to Nadav or create a new one ? IR is correct per se, so, backend should handle it (and it is w/o vector promotion). Everything was ok, because vector promotion was disabled by default on 3.0. You may try to check with llc -promote-elements=1 on llc

> 4. Testing program code: Please report a bug and attach the preprocessed source. Thanks. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi all, I've a .ll code that use double precision fmul/fadd or fmul/fsub. When I compile it using llc -mcpu=cortex-a9 I couldn't get vmla/vmls generated even using -fp-contract=fast, but when I use option -mtriple=armv7-eabi instead of -mcpu=cortex-a9 fused mac are generated. Can someone explain me why ? Thanks for your answers Seb -------------- next part -------------- An HTML

On 8 November 2012 13:56, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > > > > > I’ve a .ll code that use double precision fmul/fadd or fmul/fsub. When I > compile it using llc –mcpu=cortex-a9 I couldn’t get vmla/vmls generated even > using –fp-contract=fast, but when I use option –mtriple=armv7-eabi instead > of –mcpu=cortex-a9 fused mac

Hi all, Can someone explain me why is vmlx forwarding option enabled for cortex-a9 ? and what the purpose of it ? Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121205/6d6a7a03/attachment.html>

On 26 November 2013 17:40, Sean Silva <chisophugis at gmail.com> wrote: > As you can see, it chose the platform assembler, which is x86_64-only, not >> a cross-assembler. That's the hint that Clang didn't find your >> cross-binutils. >> > > Out of curiosity, can't clang do the assembly itself in this case? > It can, but you need to use

Here's where we left off: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059099.html In 3.4, I think the integrated assembler is in excellent shape and should be enabled by default for ARM ELF. I've been using it exclusively for at least 6 months now. -Greg On Tue, Nov 26, 2013 at 10:13 AM, Tim Northover <t.p.northover at gmail.com> wrote: >>> Out of

On 26 November 2013 18:13, Tim Northover <t.p.northover at gmail.com> wrote: > Do you remember what those features are Renato? MC has been around > years, we really should start sorting them now. > No. I remember there were issues, but I never catalogued them. I agree we should move as soon as possible, and there's nothing holding me of doing it. I think post-3.4 we can cope

On 26 November 2013 18:46, Greg Fitzgerald <garious at gmail.com> wrote: > Here's where we left off: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059099.html Back then you mentioned a Chromium build, are you still running that routinely with -integrated-as? That would give a reasonable reassurance about general-usage, if not weird features. Cheers. Tim.