similar to: [LLVMdev] llvm-gcc configure options for ARM target at llvm-gcc build time

Hi, I noticed that there is some kind of reference to Symbian support in LLVM-GCC, and I'm trying to find out more about it. I configured llvm- gcc-4.2-2.5 using: > ../configure --prefix=/opt/stow/llvm-gcc-2.5/ --enable-llvm=/home/wim/Documents/Sources/llvm-2.5/OBJ_ROOT/ --disable-bootstrap --disable-multilib --enable-checking --target arm-none-symbianelf --enable-languages=objc,c,c++

Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:

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

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

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

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,

Hi All, Can someone comment below question whether it is wrong or not please? 2016-06-25 7:52 GMT+01:00 jingu kang <jaykang10 at gmail.com>: > Hi All, > > I have a problem with VectorLegalizer::ExpandStore() with v4i1. > > Let's see a example. > > * LLVM IR > store <4 x i1> %edgeMask_for.body1314, <4 x i1>* %27 > > * SelectionDAG before vector

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

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

On Tue, Jun 28, 2016 at 2:45 AM, jingu kang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi All, > > Can someone comment below question whether it is wrong or not please? > > 2016-06-25 7:52 GMT+01:00 jingu kang <jaykang10 at gmail.com>: >> Hi All, >> >> I have a problem with VectorLegalizer::ExpandStore() with v4i1. >> >> Let's

On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at>wrote: > On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't

On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).

Attached is the patch I've been building arm-eabi with, which might help with linux-gnueabi. I disable multilib to get around several bugs with thumb. I build cross binutils first, then llvm, then llvm-gcc with newlib merged in. The following bugs need to be addressed for these non-Darwin ARM targets: 1388 2313 2545 2985 deep On Fri, Mar 13, 2009 at 12:30 AM, Misha Brukman <brukman at

Can someone with llvm-gcc/ARM expertise (Dale?) please review Sandeep's patch? The patch works for me in building an LLVM-based cross-compiler from x86_64/Linux to ARM/Linux. I have been able to build without the patch to the asm file, but several people have reported needing the asm patch on http://llvm.org/PR2545 . On Thu, Mar 12, 2009 at 8:39 PM, Sandeep Patel <deeppatel1987 at

Hi All, I have a problem with VectorLegalizer::ExpandStore() with v4i1. Let's see a example. * LLVM IR store <4 x i1> %edgeMask_for.body1314, <4 x i1>* %27 * SelectionDAG before vector legalization ch = store<ST1[%16](align=4), trunc to v4i1> t0, t128, t32, undef:i64 * SelectionDAG after vector legalization ch = store<ST1[%16](align=4), trunc to i1> t0, t133, t32,

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

Jin-Gu Thanks for your suggestion. Using liveness information for virtual register is a good idea, but what I am working on is a source-to-source compiler, so I prefer to use FunctionPass instead of MachineFunctionPass. Interestingly I found a FunctionPass example for classic liveness data flow equation. http://cs.pub.ro/~cpl/wiki/images/1/15/Hello.txt

Guys, you can exclude me (dyatkovskiy) from this list, since I reverted my changes in r162354. -Stepan. llvm.buildmaster at lab.llvm.org wrote: > The Buildbot has detected a new failure on builder clang-native-mingw64-win7 while building cfe. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-native-mingw64-win7/builds/876 > > Buildbot URL:

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