similar to: [LLVMdev] Miscompilation on MingW32

Hello, Julien > Any idea why this is happening ? I think I fixed this. Please verify. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Julien > First issue is that unittests don't build for MingW, the attached > patch > should fix it. Looks ok for me, however, use __MINGW32__ - this is how it's in all LLVM tree nowadays. > working) and 61242 (first known non working). Are you running bootstrap build? --- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

I'm looking forward to your patches and bug reports. I really want to get this going myself. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: Wednesday, May 10, 2006 1:22 PM To: LLVM Developers Mailing List Subject: [LLVMdev] Successfulyl bootsrapped llvm-gcc4 on mingw32 Hello, Everyone. Today

Hello, Everyone. All blackmagic (playing with pwd, etc) in my build description has gone with patched bash (pwd builtin was just hardly disabled). It's not good, I myself prefer modifying libstdc++ configure script to use PWD_CMD environmental variable as main gcc ones. I'm working on this feature. -- With best regards, Anton mailto:asl at math.spbu.ru

Hello, Julien > Anybody had this problem before ? Is this a proper fix ? Applied, thanks! -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

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

Hello, Henrik. You wrote Thursday, May 11, 2006, 5:13:06 AM: HB> Thanks Anton. Nice Job. There was at least one thing I miss in the description: In the step 3 you should unpack runtime libraries from mingw32 distribution into "prefix" (say, w32api and mingw-runtime) before starting configure for GCC. BTW, maybe it will be better just use patched bash (with "pwd" builtin

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 >

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

Hello, I have this simple IR: ------------------------------------------------------------------------ define internal i32 @tmp(i32 %x) { entry: br label %entry2 entry2: %x1 = alloca i32 %x2 = alloca i32 %retval = alloca i32 %dummy = alloca i32 store i32 %x, i32* %x1 store i32 %x, i32* %x2 %tmp1 = load i32* %x1 %tmp2 = add i32 %tmp1, %tmp1

Hello, Everyone. Today I've finished digging into llvm-gcc4 in order to build in under mingw32. The most trickiest was to make libstdc++ build, since its configure & makefiles are not so perfect as main gcc ones. There are several problems with inline assemler (in two places at least), but both of them are easily seen. Also, there are some compiler crashes while compiling libiberty (with

Hello, Greg. You wrote Sunday, May 14, 2006, 5:21:49 PM: GP> Do I still need to do the "black magic"? In fact, yes. GP> What is this patched version of bash (do you have a patch, where do I get GP> it?) What does "pwd builtin was just hardly disabled" mean? There are some set of built-in commands in bash (they are called "builtins"). For example

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

> 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

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.

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,

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

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