similar to: [LLVMdev] lli supports different targets than llc?

Hi, Is it normal/expected for `llc` to support a different set of targets than `lli`? I have a hello.ll on which this works: $ llc -mtriple=armv7a-linux-gnueabihf hello.ll # OK, generates hello.s But this doesn't: $ lli -mtriple=armv7a-linux-gnueabihf hello.ll # lli: error creating EE: No available targets are compatible with this triple, see -version for the available targets. I'm

On Thu, Jul 23, 2015 at 10:31 AM Débora Setton Sanches < setton.debora at gmail.com> wrote: > Hi, > > Is it normal/expected for `llc` to support a different set of targets > than `lli`? > I have a hello.ll on which this works: > > $ llc -mtriple=armv7a-linux-gnueabihf hello.ll > # OK, generates hello.s > > But this doesn't: > > $ lli

s/pretty much/definitely/ Even then, “works” is too strong a word. Caveat emptor and all that. > On Jul 23, 2015, at 1:20 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu, Jul 23, 2015 at 10:31 AM Débora Setton Sanches <setton.debora at gmail.com <mailto:setton.debora at gmail.com>> wrote: > Hi, > > Is it normal/expected for `llc`

But I am running it on the host, as a kind of intermediate step in the cross-compilation, just to check if everything still works after the frontend step. Shouldn't it work then? I don't know much about how everything works yet, sorry if it's a silly question. What I thought was also weird is that the exact same example works if I use the OpenMP/Clang fork

Hi, Is it normal/expected for `llc` to support a different set of targets than `lli`? I have a hello.ll on which this works: $ llc -mtriple=armv7a-linux-gnueabihf hello.ll # OK, generates hello.s But this doesn't: $ lli -mtriple=armv7a-linux-gnueabihf hello.ll # lli: error creating EE: No available targets are compatible with this triple, see -version for the available targets. I'm

Hi, You're asking lli to create a JIT for ARM code on an Intel platform... That's not realistically going to be achievable :) Cross compilation is easy, cross execution requires an emulator. Cheers, James On Mon, 27 Jul 2015 at 23:13, Débora Setton Fernandes <debora.setton at usp.br> wrote: > Hi, > > Is it normal/expected for `llc` to support a different set of targets

Hi renato, 1. The command above is followed by the guide[ HowToCrossCompileLLVM.rst ] and I specify some path(ex. <path-to-host-bin>). 2. The including x86_64 libraries is added because of some missing libraries(ex. "error: Host compiler appears to require libatomic, but cannot find it"). As I have found that the bugs needed to dealt with is some ARM-dependent libraries, I

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,

Hello All, I am building llvm-clang cross tool chain for arm target, after successful build for Linux host now I am now building toolchain for *arm target*. However, I am getting below error message which seems to be confusing and not getting any idea how to resolve this issue. *Command :* #CC='clang' CXX='clang++' cmake -G Ninja /home/iiita/crossbuild/llvm

On 8 February 2013 11:01, David Given <dg at cowlark.com> wrote: > I've tried overriding the triple to arm-unknown-linux-gnueabihf and > arm-linux-gnueabihf (via module->setTargetTriple), and while the triples > are accepted, the actual generated code doesn't change with either. > Hi David, If you set the triple to arm it won't help, since it'll default to

Hi i am wondering if someone could give me some tips on how to debug/solve this problem. I am trying to use LLI on Windows. I build llvm and clang using cmake. clang -c hello.c -emit-llvm -o hello.bc lli hello.bc D:\llvm\examples\helloworld>lli hello.bc LLVM ERROR: Program used external function '___stdio_common_vsprintf' which could not be resolved! But, I can generate the exe though

Hello All, I am building llvm-clang tool chain for *arm target* by following the steps from http://clang.llvm.org/docs/CrossCompilation.html *However when I tried following cmake command for build tool chain it gives the error message :* #CC='clang' CXX='clang++' cmake -G Ninja /home/iiita/llvm-exp/llvm -DCMAKE_CROSSCOMPILING=True

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

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

Dear Samba experts, Since a couple of days I am trying to fix my domain. I have each two ADDCs on raspis on two sites. One is running on Raspian and works fine. The other three are on Gentoo and something is broken there. When I point the name resolution in resolv.conf to the Raspian machine the dynamic updates are just working fine: # horus /srv/samba/demoshare # samba_dnsupdate --verbose

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

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

thank you! yes, i guess that is the problem. unfortunately libcmt doesn't work. could it have another name for lli? The function missing seems to be part of libcmt since i get a similar error on linking if i remove the libcmt D:\llvm\examples\helloworld>lli -load=libcmt hello.bc Error opening 'libcmt': libcmt: Can't open: The specified module could not be found. (0x7E)

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

On Sun, Jul 3, 2011 at 11:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM >