similar to: [LLVMdev] long double type on ARM

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in

Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin

Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,

Dear LLVM members. I am building llvm-gcc in version 2.5 for ARM target. I used command line option as following: >../src/configure --prefix=/home/jaykang10/Projects/LLVM/front_end_test/bin/ --enable-languages=c,c++ --enable-checking --enable-llvm=/home/jaykang10/Projects/LLVM/bin/ --disable-bootstrap --disable-multilib --target=arm-eabi And I got a error message as following: ... gcc -c -g

Hi Duncan, I made a patch for dragonegg. This patch is for dragonegg to generate arm assembly code. Dragonegg is compiled with this patch after building gcc-4.6 as cross compiler for arm and then dragonegg can generate arm assembly code. It currently makes errors to build dragonegg and llvm from svn. so I made a patch using dragonegg-3.0 source code. (This patch doesn't support

Hi Jin-Gu, > I made a patch for dragonegg. This patch is for dragonegg to generate arm > assembly code. thanks for working on this. > > Dragonegg is compiled with this patch after building gcc-4.6 as cross compiler > for arm and > > then dragonegg can generate arm assembly code. > > It currently makes errors to build dragonegg and llvm from svn. so I made a > patch

Hola LLVMers, One of the corner-case features of the Hydra language I work on are Boolean vectors of length 2, 3, or 4 which I've been representing as either <2 x i1> or <4 x i1>. I picked up the latest LLVM about a week back and since then I've been unable to compile things using this construct. It asserts in TargetData::getAlignmentInfo since it doesn't have

Duncan, could this be related to your recent work? Chuck, this is unlikely to be a x86 specific problem. Please file a bug. Thanks! Evan On Dec 6, 2007, at 5:06 PM, Chuck Rose III wrote: > Hola LLVMers, > > One of the corner-case features of the Hydra language I work on are > Boolean vectors of length 2, 3, or 4 which I’ve been representing as > either <2 x i1> or

Hi Duncan, I appreciate your kind review. I'd like to help you to build an ARM cross compiler. I built GCC as following. 1. Download "arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2" You can find this file on https://sourcery.mentor.com/sgpp/lite/arm/portal/release1600. (Please click "IA32 GNU/Linux TAR" on Packages.) 2. Extract this file on your linux

Thanks for applying this patch. I really appreciate that. Sincerely, Jin-Gu Kang

Hi Renato, First, I appreciate your answer again. :) >> %Char = type { c3, c4, c3, c2 } >> %Short = type { s3, s4, s3, s2 } >> %Int = type { i3, i4, i3, i2 } > See, i is not for int (the C data type) but for every integer type on > any language/platform combination. Normally, booleans are i1 and char > i8, in ARM short is 16 and int is 32, and all of them use the

Hi renato, First, I really appreciate your answer. :) The IR in an previous e-mail is incomplete so far and I am converting it to various shape. My team members decided to add new types to solve the bitfield's alignment problem. Let's consider your previous examples: struct testChar { char a:3; char b:4; char c:3; char d:2; }; struct testShort { short a:3; short b:4; short c:3;

I am pleased to discuss probleams with you. :) (Your answer is really helpful to me). If you don't mind I would often like to ask you a question. Thanks, Jin-Gu Kang

All, I should have chimed in earlier, but have been working on two more side-channel variants of this conversation. At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all platforms while taking one portable bitcode stream as input. During the discussions we've had over the past few weeks it became obvious that that is simply not tractable,

Hi LLVM members, I have been working to make target independent memory layout for struct type(Aggregate type) in my team. I think that struct type has different memory layouts according to each target system in current LLVM. To implement target dependent concept for struct type, Frist, I have been implementing common type for struct type on bitcode at compilation time using llvm-gcc and then

On 20 October 2010 06:22, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote: > The IR in an previous e-mail is incomplete so far and > I am converting it to various shape. Hi Jin, No worries. I'm interested in the outcome, so I'm playing the devil's advocate to make sure your proposal is consistent with the rest of LLVM. > %Char = type { c3, c4, c3, c2 } > %Short =

On 19 October 2010 07:57, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote: > Frist, I have been implementing common type for struct type on bitcode > at compilation time using llvm-gcc and then changing common type to target > specific types at code generation time using llc (reconstruct StructLayout). Hi Jin, Apart from bitfields and unions, the struct type is pretty much target

On 21 October 2010 08:26, Jin Gu Kang <jaykang10 at imrc.kist.re.kr> wrote: > I think you misunderstood our type notation. > By using your suggetion, "s4" means "i4 align short" in our notation. > In "i4 align 2" for "short a:4", I think that "align 2" is already target dependent > because short can be 2 or 4 bytes according to

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------