similar to: [LLVMdev] Building uclibc ...

On Sep 12, 2007, at 3:56 PM, Dound wrote: > > > On 9/12/07, Chris Lattner <sabre at nondot.org > wrote: > On Wed, 12 Sep 2007, Dound wrote: > > I am trying compile a libc with llvm (currently uclibc). I am > able to > > compile uclibc by changing the Rules.mak to use llvm-gcc, llvm- > ar, llvm-ad, > > and not using strip. (I also use the --emit-llvm

On Wed, 12 Sep 2007, Dound wrote: > I am trying compile a libc with llvm (currently uclibc). I am able to > compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar, llvm-ad, > and not using strip. (I also use the --emit-llvm flag for llvm-gcc). When > I run llvm-nm on libc.a (or try to use libc.a) I run into problems. For > example, strlen is not defined -- llvm-nm

On 9/12/07, Chris Lattner <sabre at nondot.org> wrote: > > On Wed, 12 Sep 2007, Dound wrote: > > I am trying compile a libc with llvm (currently uclibc). I am able to > > compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar, > llvm-ad, > > and not using strip. (I also use the --emit-llvm flag for > llvm-gcc). When > > I run llvm-nm on

I am trying compile a libc with llvm (currently uclibc). I am able to compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar, llvm-ad, and not using strip. (I also use the --emit-llvm flag for llvm-gcc). When I run llvm-nm on libc.a (or try to use libc.a) I run into problems. For example, strlen is not defined -- llvm-nm shows that strlen.os has __GI_strlen while if I compile with

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

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 >

Hello Anton Thu, 3 Aug 2006 23:13:52 +0400 you wrote: > I won't be available for the next 10-12 hours if you'll need some more > files. Well. I have one idea. Could you please execute "sort --version" from your cygwin shell and let me know, whether it's GNU one (it should reply with the words "textutils") or windows-supplied one (it should just give you 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

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,

Hello everyone. The bug in ld prevented release build of LLVM on Mingw & Cygwin is fixed by now. You might get the patch for binutils sources at http://sourceware.org/bugzilla/show_bug.cgi?id=2659 Hope, this fix will be included in the next binutils release. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi, Chris > Can you please send in a patch so we can fix this on mainline? This known problem: stdint.h on cygwin declares {u}int32_t type to be 'long', not 'int'. And this causes problems with APInt's uint32_t => unsigned casts. I myself don't know good direct fix except patching Cygwin's stdint.h itself. -- With best regards, Anton Korobeynikov. Faculty of

Hello Anton Thu, 3 Aug 2006 15:06:56 +0400 you wrote: > here it is in the attachment :) Ok. Could you also send LibDeps.txt file? It should be in /obj/tools/llvm-config directory -- 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

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.

On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > Hello, Ashwin. > > You wrote Wednesday, May 24, 2006, 11:25:11 AM: > > AC> "Pass::getClassPassInfo<PassClass>() "Pass class not > AC> registered!"" failed: file > AC> "/cygdrive/c/llvm/llvm/include/llvm/PassAnalysisSupport.h", > line 76 > AC> Aborted > Same

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

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

2013/3/27 Anton Korobeynikov <asl at math.spbu.ru>: > Hi Eric, > >> From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs > No. They are using Windows Platform ABI for almost everything (e.g. > calling API, C runtime, etc.). At least mingw does. The differences > are exactly in unspecified area (e.g. passing / returning structs by >

What if it's already broken? 2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> A more specific question is - if I fix some Clang i686-pc-win32 >> compatibility issue with MSVC for some language feature (e.g. >> returning a struct), >> should I make sure Clang i686-pc-mingw32 behavior is not changed by my >> patches (a) >> or should I make sure