search for: armv4t

...tool chain, "/home/hum/Documents/Projects/arm_toolchain/arm-2010.09/bin/arm-none-linux-gnueabi-ld". [Output] clang version 3.2 (trunk 158784) Target: arm-none-linux-gnueabi Thread model: posix "/home/hum/Documents/Projects/clang_llvm/build/Debug+Asserts/bin/clang" -cc1 -triple armv4t-none-linux-gnueabi -E -disable-free -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm7tdmi -mfloat-abi soft -target-feature +soft-float-abi -target-linker-version 2.22 -momit-leaf-frame-pointer -v -resource...

Hello > ./clang -v -emit-llvm -ccc-host-triple arm-none-linux-gnueabi > -I/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/include > -L/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c You forgot about sysroot here. > /home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin/ld: > unrecognised emulation mode: armelf_linux_eabi >

I don't know if this is the right place to ask but is there any timetable for thumb mode support on sub-ARMv6 processors? The exact processor support what i'm interested in is arm7tdmi. -Waltteri

I think Thumb support is more or less there (but performance is not wonderful). If you run into issues, feel free to file bugs. Or even better, please contribute patches! :-) Evan On Apr 7, 2008, at 2:59 AM, Waltteri.Kaikkonen at teleste.com wrote: > I don't know if this is the right place to ask but is there any > timetable for thumb mode support on sub-ARMv6 processors? The

...e 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 unable to find any values for CPU which are accepted (it just says 'unknown target CPU'. I've tried arm, armv7, armv7a, armv7l, arm7, armv4t... Any suggestions? Is there a way to get clang and llc to emit a list of what triples they support? Since I posted my message I notice that clang 3.2 has hit Debian experimental. This no longer produces the warning about an unrecognised platform, but it still generates softfloat code --- I've...

Jim/Tim/Renato, A few days ago (has it been weeks now?) we discussed a codegen problem on armv4t having to do with lo->lo register copies. I'd like to start that discussion again, this time with a patch. A brief summary of the problem for folks who didn't catch the discussion earlier, and those like me who forget what they ate for breakfast: ;] The mov instruction on armv4t (speci...

...ocuments/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c 5. Received an output and an error message shown below. clang version 3.2 (trunk 158657) Target: arm-none-linux-gnueabi Thread model: posix "/home/hum/Documents/Projects/llvm_clang/build/Debug+Asserts/bin/clang" -cc1 -triple armv4t-none-linux-gnueabi -emit-llvm-bc -disable-free -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-abi aapcs-linux -target-cpu arm7tdmi -mfloat-abi soft -target-feature +soft-float-abi -target-linker-version 2.21.53.20110810 -momit-leaf-fra...

Targetting the raspberry pi, what triple/flags should I set? I tried triple: armv4t-unknown-linux-gnueabi and ld fails with: a.out uses VFP register arguments if i set hardfloat (using optdata.FloatABIType = FloatABI::Hard), ld fails with an assertion: 2.22 assertion fail ../../bfd/elf32-arm.c:11477 what am I missing?

...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, arm7, > armv4t... Any suggestions? Is there a way to get clang and llc to emit a > list of what triples they support? > armv7 and armv7a should default to Cortex-A8, "arm" will default to 7TDMI. Target: arm-unknown-linux-gnueabihf > Auto-detected wrongly (as expected), > "/usr/bi...

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

It depends, of course, what operating system you have installed on the RPi, but given that it's an ARM1176JZFS (ARMv6) chip, I would expect to see armv6, not armv4t, in the CPU part of the triple. It has a VFP unit, so I'd assume that you'd want to set hardfp (unless you installed an OS that doesn't support hardfp in its standard library), but if ld is complaining then you almost certainly have a mismatch. David On 30 Dec 2012, at 10:42, Carlo K...

...passed to LTO seems to: - Escape all the existing warnings about nonsensical triples [*]. - On Arm targets at least; having a final link step without a cpu is likely to be quite common so I don't think that this will be a corner case. - The Build Attributes of the output ELF file get the triple ARMv4t from -mcpu=arm7tdmi which is lying to the linker as the file contains ARMv7a instructions. My personal preference is that we shouldn't pass an implicit CPU derived from the triple, at least for Arm targets. If that isn't possible I think that we should make sure we detect inappropriate cpu...

...the existing warnings about nonsensical triples [*]. >> - On Arm targets at least; having a final link step without a cpu is >> likely to be quite common so I don't think that this will be a corner >> case. >> - The Build Attributes of the output ELF file get the triple ARMv4t >> from -mcpu=arm7tdmi which is lying to the linker as the file contains >> ARMv7a instructions. > > > Having ARMv7a instructions in an ARMv4t file shouldn't be a problem: a > function should be allowed to override the CPU attributes to generate code > for a newer tar...

...ry details: http://bugs.debian.org/515949 which follows on into the xiph tracker https://trac.xiph.org/ticket/1526 It's also compiler and floating-point-implementation dependent: 6456040 Happy.wav 346624 Happy-x86.ogg (x86, gcc-4.3, correct output) 186510 Happy-xscale (Debian, armv5te chip, armv4t code, 64-bit softfloat, gcc-4.3) 253029 Happy-gcc55 (Gentoo, armv5te chip, armv5t code, 64-bit softfloat, gcc-4.1.2) 166377 Happy-gcc-4.1 (Debian, armv5te chip, armv4t code, 64-bit softfloat, gcc-4.1) If I compile it to use the MaverickCrunch FPU on the ep9312 armv4t chip, which doesn't hand...

...gt; - Escape all the existing warnings about nonsensical triples [*]. > - On Arm targets at least; having a final link step without a cpu is > likely to be quite common so I don't think that this will be a corner > case. > - The Build Attributes of the output ELF file get the triple ARMv4t > from -mcpu=arm7tdmi which is lying to the linker as the file contains > ARMv7a instructions. Having ARMv7a instructions in an ARMv4t file shouldn't be a problem: a function should be allowed to override the CPU attributes to generate code for a newer target.  This is generally done u...

On 16 March 2018 at 10:38, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: >> Having ARMv7a instructions in an ARMv4t file shouldn't be a problem: a >> function should be allowed to override the CPU attributes to generate code >> for a newer target. This is generally done using the "target" function >> attribute. If this doesn't work correctly, we should fix it. It looks like...

Hello, Martin > llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc, > powerpc and ia64, only succeeding on i386 and amd64: > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable > so it looks like the 2.5 release was never properly tested before it > was published. Unfortunately, ia64 and sparc were never considered as a 'tier-1' targets

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 8/3/09, Anton Korobeynikov <anton at korobeynikov.info> wrote: > > Thanks. Do you have fixes for the other ARM bloopers? This is the > > forthcoming Debian version and it's now dying on arm-gnueabi when it > > links cc1-dummy saying > > Please use the current Top-of-the-Tree version. Sorry, that's not an option as I'm trying to fix the Debian

On 18 July 2012 15:24, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > I'm not sure how to interpret the above output, but I don't understand > why if say -triple armv4t-none--gnueabi . Ok, we're getting there... ;) I think these errors are due to Clang not finding the libraries/includes/etc for the target you're building. If you have CodeSourcery's GCC, use that (via --sysroot or -ccc-gcc-name I said earlier), it's by far the easiest way. I'...