similar to: [LLVMdev] Problem compiling llvm-gcc

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, llvm-dev. thank you for your interest in my question. Currently, I compiled simple c source code (hello.c) in lunux and windows, and I tried to simple test . first case: hello.bc (compiled with "-emit-llvm" on windows) -> lli.exe(linux). second case: hello.bc (compiled with "-emit-llvm" on linux) -> lli.exe(windows). second case return good result. but First case

Hello, Prakash > I tried with --enable-languages=java and it still fails with the same > error: gcj is not supported by llvm-gcc (and even with build w/o LLVM, as you're doing) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Holger. > You can find out what exactly leaks with the help of valgrind. It seems, that Paolo is on Mac OS X. No valgrind there :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

I tried to ask for 32 and that didn't seem to help. MallocInst also seemed to ignore the 16 byte directive. For now, I'm just issuing all my loads as unaligned and that's working ok. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 10:35 AM To: asl at

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem

Hello, Daniel. > glibc < 2.4 don't reliably keep stack at 16 bytes through some calls > (qsort, etc), but otherwise, it stays 16 byte aligned. Interesting, but why in this case stuff like 'force_align_arg_pointer' required? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

> Ah, got it. > Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. No, we should not. It should be properly expanded in frontend. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

my g++-cross was configured with following parameters: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home/arm_v7_vfp_le/target/ --with-build-sysroot=/home/arm_v7_vfp_le/target/ --enable-shared --enable-languages=c,c++ --with-as=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-as

Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI<bits<6> op, dag outs, dag ins, string asmstr, list<dag> pattern, InstrItinClass itin>: FI<op, outs, ins, asmstr, pattern, itin> { let isBarrier = 1; // or call,

Did you mean ld-new ? ld-new -v GNU gold (GNU Binutils 2.20.51.20100707) 1.9 ld-new --help ./ld-new: supported targets: elf32-i386 elf32-i386-freebsd elf64-x86-64 elf64-x86-64-freebsd elf64-sparc elf32-sparc elf64-powerpcle elf64-powerpc elf32-powerpcle elf32-powerpc elf32-bigarm elf32-littlearm On Mon, Jul 12, 2010 at 6:52 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote:

Should be there On Fri, Nov 16, 2012 at 3:00 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Anton, please add release_32 also in; > > clang-tools-extra > compiler-rt > dragonegg > libcxxabi > lldb > > They have release_32 in svn. I don't know they might be released, though. > > And, could you suppress generating refs/heads/svn-tags and prune them

You can always ask for > 16 byte stack alignment. :-) Evan On Sep 30, 2007, at 10:47 AM, Anton Korobeynikov wrote: > Hello, Daniel. > >> glibc < 2.4 don't reliably keep stack at 16 bytes through some calls >> (qsort, etc), but otherwise, it stays 16 byte aligned. > Interesting, but why in this case stuff like 'force_align_arg_pointer' > required? >

No, I'm using the latest binutils. On Mon, Jun 28, 2010 at 1:14 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > Any help would b appreicated. This is one of my critical assignment. > Well, as was already indicated - make sure that you're using the > latest binutils (2.20 is not fresh enough, btw). > > -- > With best regards, Anton Korobeynikov

Sorry about that. As you can see, I'm using binutils (ld & as ) from arm toolchain we use to build things for our target. arm_a_b_c_ld -v gives 2.17.50.20070611 arm_a_b_c_as -v gives 2.17.50.20070611 Do you belive that older binaries of (linker & assembler) can cause performance drop ? Unfortunately I'm not in a position to update the arm compiler for my company :) On Mon, Jun

Thanks, last doubt :) But I wanted to say is using these binutils I have built a llvm compiler for our ARM target. Now our libraries which are either compiled with native ARM or with this llvm compiler gives same performance numbers. However this only llvm compiler if compared with x86 compiler gives huge performance gain. Any idea why this might be happening ? On Mon, Jun 28, 2010 at 1:57 PM,

exactly On Mon, Jun 28, 2010 at 2:11 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > > But I wanted to say is using these binutils I have built a llvm compiler > for > > our ARM target. > That's correct. Mostly because gcc is using pre-UAL ARM assembler syntax > and LLVM switched fully to UAL one. Also, UAL is needed for correct Thumb-2 > support,

Hello, Since, I cudn't get performance gain using llvm compiler, I've tried to use gold linker instead of going through these following steps. a) 'llvm-gcc -c -flo -O2' to generate the .bc files. b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a. c) 'llc' to turn your combined .bc into a .s d) 'as' to turn your .s into a .o I followed