search for: armv4

<div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><div> I’ve got an embedded development board with an ARMv4 chip that has no thumb support whatsoever. Given that lib/Target/ARM/ARM.td has no apparent option for ARMv4 without Thumb, can I still use clang for ARMv4, or am I out of luck? Can I expect to use clang in the future, or am I going to be stuck with the mess that is gcc?</div><div><b...

I’m tying to run a rust application on armv4 architecture (arm720tdmi). Rust is using llvm to generate native code. Some programs are running well on the target but for more complex applications I receive a Illegal instruction : gdb disassembling the core dump file gives : 0x401e41dc <+0>: push {r11, lr} 0x401e41e0 <+4>: mo...

Hi, I am getting this: ----- armv4-unknown-linux-gnu-ld -o tests/fcntl.shared -e main interp.o tests/fcntl.o -R libc.so /usr/lib/gcc-lib/armv4-unknown-linux-gnu/3.3.5/libgcc.a armv4-unknown-linux-gnu-ld: internal error: aborting at /space/var/tmp/portage/binutils-2.15.90.0.3-r4/work/binutils-2.15.90.0.3/ld/ldlang.c line 3835 in lan...

I’m using rust head version that currently use llvm 3.7 … Thanks. Frédéric. > On 11 Sep 2015, at 13:29, Bruce Hoult <bruce at hoult.org> wrote: > > What LLVM version are you using? > > There were some bugs around switching ARM/Thumb mode on ARMv4 fixed in 3.6. > > On Fri, Sep 11, 2015 at 1:20 PM, Frédéric Richez <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I’m tying to run a rust application on armv4 architecture (arm720tdmi). > Rust is using llvm to generate native code. > Some progr...

...v at cs.uiuc.edu Date: Saturday, January 16, 2010, 6:09 PM Hello > /tmp/ccm99Neh.s:711: Error: selected processor does not support `sxtb r1,r1' > make[3]: *** [libgcc/thumb/unwind-dw2-fde.o] Error 1 > > Any ideas? Yes. LLVM defaults to ARMv5 in codegeneration and does not support ARMv4. Without any extra option arm-elf-as assumes ARMv4 and thus gives you these errors. So: 1. If your desired target platform is ARMv4 and not newer - then you're out of luck 2. Otherwise - add --with-cpu or --with-arch to llvm-gcc configure to select the processor / arch desired. It seems that...

...v at cs.uiuc.edu Date: Saturday, January 16, 2010, 6:09 PM Hello > /tmp/ccm99Neh.s:711: Error: selected processor does not support `sxtb r1,r1' > make[3]: *** [libgcc/thumb/unwind-dw2-fde.o] Error 1 > > Any ideas? Yes. LLVM defaults to ARMv5 in codegeneration and does not support ARMv4. Without any extra option arm-elf-as assumes ARMv4 and thus gives you these errors. So: 1. If your desired target platform is ARMv4 and not newer - then you're out of luck 2. Otherwise - add --with-cpu or --with-arch to llvm-gcc configure to select the processor / arch desired. It seems that...

I encountered what I think is a bug in labFLAC_static release that's driving me nuts. I compile the FLAC libraries in debug mode on ARMV4 (ported) and it works fine I compile the FLAC libraries in release mode on ARMV4 (ported) and no FLAC files play >From what I can see, in metadata_callback, I get different values for channel and bitsperssample metadata->data.stream_info.bits_per_sample is 16 in debug mode, 1072 in release...

...4 deletions(-) diff --git a/silk/arm/arm_silk_map.c b/silk/arm/arm_silk_map.c index 53a60a0..04767b5 100644 --- a/silk/arm/arm_silk_map.c +++ b/silk/arm/arm_silk_map.c @@ -48,7 +48,7 @@ void (*const SILK_BIQUAD_ALT_STRIDE2_IMPL[OPUS_ARCHMASK + 1])( silk_biquad_alt_stride2_c, /* ARMv4 */ silk_biquad_alt_stride2_c, /* EDSP */ silk_biquad_alt_stride2_c, /* Media */ - MAY_HAVE_NEON(silk_biquad_alt_stride2), /* Neon */ + silk_biquad_alt_stride2_neon, /* Neon */ }; opus_int32 (*const SILK_LPC_INVERSE_PRED_GAIN_IMPL[OPUS_ARCHMA...

...libc mailinglist, both are looked and watched. The second one is usually preferred as more people look at the klibc patches on ml. > BTW, do you have any idea why the build process forces such odd and > very old toolchain flags instead of just using the defaults? > (it forces -march=armv4 -mtune=strongarm) what do you expect currently? thank you. -- maks P.S. adding Arnaud as new debian linux-2.6 arm guy on cc

...rx r0,r0" and "mov r0, r0, rrx" result in same opcode: 0xe1a00060. Problem is that in case when old binutils are used (in my case freebsd is using old one due to license upgrade to GPLv3) AS doesn't understand new mnemonics and fails. Can we change to old mnemonic at least when ARMv4 and ARMv5 code is generated? Thanks,

Thank Jonathan! I'll fix the MAY_HAVE_NEON() in silk/arm/arm_silk_map.c Linfeng On Thu, Jun 1, 2017 at 3:34 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > Semantically, OPUS_ARM_MAY_HAVE_NEON is supposed to mean the compiler > supports, and the CPU may support, Neon assembly code, which isn’t > necessarily the same thing as the compiler supporting Neon intrinsics. >

...nclude -Iusr/include -I/build/buildd/klibc-1.5.20/linux/include -Ilinux/include -I/build/buildd/klibc-1.5.20/linux/arch/arm/include -Ilinux/arch/arm/include -D__KLIBC__=1 -D__KLIBC_MINOR__=5 -D_BITSIZE=32 -fno-stack-protector -fwrapv -fno-exceptions -mabi=aapcs-linux -mno-thumb-interwork -Os -march=armv4 -mtune=strongarm -W -Wall -Wno-sign-compare -Wno-unused-parameter -D__ASSEMBLY__ -nostdinc -iwithprefix include -I/build/buildd/klibc-1.5.20/usr/include/arch/arm -Iusr/include/arch/arm -I/build/buildd/klibc-1.5.20/usr/include/bits32 -Iusr/include/bits32 -I/build/buildd/klibc-1.5.20/usr/klibc/../inc...

...mjan.marion at gmail.com> wrote: > Problem is that in case when old binutils are used (in my case freebsd is using old one due to license upgrade to GPLv3) AS doesn't understand new mnemonics and fails. Indeed, this is new in ARM ARM v7. > Can we change to old mnemonic at least when ARMv4 and ARMv5 code is generated? We definitely should. Feel free to send a patch if you already have, or create a bug in bugzilla. Shouldn't be too hard to add it. cheers, --renato

Hello, At this moment I have built from scratch a gcc compiler for ARM and I have in the classpath the binaries. arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: ../gcc-4.3.3/configure --target=arm-elf --prefix=/tmp/arm-cortex-toolchain --enable-interwork --enable-multilib --enable-languages=c,c++ --with-newlib --disable-shared --with-gnu-as --with-gnu-ld Thread model:

Hello, I'm trying to evaluate the performance improvement of instruction scheduling on one of the inorder ARM processor, I was looking for ARM simulator and I found two (Simplescalar/ARM and SimIt-ARM) The code generated using llvm-2.9 and llvm-gcc and gcc 3.2. I used these command : $ llvm-gcc -O3 -o test1.bc -c --emit-llvm test1.c $ llc -O3 -o test1.s -march=arm test1.bc -mcpu=strongarm110

Hello, I want to compile MiBench by clang, and the target-ISA is armv4. The code generated using llvm-2.9, clang-2.9, and arm-linux-gcc (gcc version 2.95.2), simulator is sim-panalyzer 2.0.3 . I use these commends: $ clang -O3 -o hello.ll -c -emit-llvm hello.c $ llc -O3 -o hello.s -march=arm -mcpu=strongarm1100 hello.ll $ arm-linux-gcc -O3 -march=armv4 -mcpu=stronga...

...oronix.com/scan.php?page=news_item&px=MTA5OTM I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are apparently compiled without -mcpu=cortex-a9, I suspect LLVM ended up generating code for "generic" ARMv4 cpu. This article makes me sick in my stomach. Thanks, Evan

...ndif > (*const CELT_PITCH_XCORR_IMPL[OPUS_ARCHMASK+1])(const opus_val16 *, > const opus_val16 *, opus_val32 *, int, int); Shouldn't the first case have a corresponding update in the #else clause for the !defined(FIXED_POINT) case? > celt_pitch_xcorr_c, /* ARMv4 */ > diff --git a/celt/arm/pitch_arm.h b/celt/arm/pitch_arm.h > index eaf61c9..bd41774 100644 > --- a/celt/arm/pitch_arm.h > +++ b/celt/arm/pitch_arm.h > @@ -46,7 +46,13 @@ opus_val32 celt_pitch_xcorr_edsp(const opus_val16 *_x, const opus_val16 *_y, > opus_val32 *xcorr, int...

...ased wince device. (39fps if audio sync is sacrificed). * With post processing (deblocking/deringing) enabled, this drops to 23fps. * Uses no hardware acceleration features (e.g. dithered YUV2RGB is done in software, so on devices with such features available, it could go even faster). * Uses ARMv4 instructions only (no reliance on Xscale SIMD or ARMv5/v6/v7/NEON). * Compatible with films encoded with the latest encoder versions. For more information, see the website above, or contact me. Robin -- Robin Watts, Email: <mailto:Robin.Watts at wss.co.uk> Warm Silence Softwa...

...wrote: >> Problem is that in case when old binutils are used (in my case freebsd is using old one due to license upgrade to GPLv3) AS doesn't understand new mnemonics and fails. > > Indeed, this is new in ARM ARM v7. > > >> Can we change to old mnemonic at least when ARMv4 and ARMv5 code is generated? > > We definitely should. Feel free to send a patch if you already have, > or create a bug in bugzilla. Shouldn't be too hard to add it. LLVM always uses unified syntax, including updated mnemonics for older instructions. Older binutils aren't support...