similar to: [LLVMdev] Standard output binary mode on windows

Hello, On windows, the standard output is not set to binary mode by default so all '\n' characters are replaced with '\r\n'. This is a pain for any command using stdout, like "llvm-as < input.ll > out.bc", because out.bc is then most likely corrupted. This is an old story, fixed a while ago: http://llvm.org/bugs/show_bug.cgi?id=787 And here is the thread on

Hello, Julien > Should I open a new PR to track this issue or reopen #787 ? Don't worry, I'll test your patches and include into mingw32 binaries. > I think the binary releases of llvm and llvm-gcc for MingW32 on > http://llvm.org/releases/download.html#2.2 have the problem, stdout > cannot be used. Yes, completely forgot to test this feature :( -- With best regards, Anton

Hello, Matthijs > why do you only set binary mode for stdout? Don't you have the same problem > when writing bitcode to file? No, all files are opened in binary mode. This is really ugly thing (stdout opened in text mode) which really hurt bunch of projects during porting, since fallout from such thing can be pretty subtle. -- With best regards, Anton Korobeynikov. Faculty of

Finally, I got my hands on Windows machine again today. I extracted llvm-2.1-x86-mingw32.tar.bz2 and llvm-gcc4.0-2.1-x86-mingw32.tar.bz2 to C:\llvm (It's a bare Windows Vista installation without MinGW) Added C:\llvm\bin;C:\llvm\libexec\gcc\i686-pc-mingw32\4.0.1 to PATH (C:\llvm\libexec\gcc\i686-pc-mingw32\4.0.1 was added for cc1.exe) Downloaded

Bill, > When I try to compile on Darwin now, I get this: Could you please provide LLVM bytecode, where bug is reproducible with llc? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Sam, > Am I supposed to install MinGW (maybe MSYS) and extract prebuilt > packages ( llvm-2.1-x86-mingw32.tar.bz2 and > llvm-gcc4.0-2.1-x86-mingw32.tar.bz2) to C:\MinGW ?? llvm-as != as. You'll need to have binutils installed in order to compile & link. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Aaron. > /usr/src/llvm-gcc4/gcc/libgcc2.c: In function '__eprintf': > /usr/src/llvm-gcc4/gcc/libgcc2.c:1832: internal compiler error: > Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. You should: 1. Try to emit bytecode with --emit-llvm compiler switch. 1.1

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

> Sorry, this wasn't mentioned in documentation. llvm-gcc was built with > '--enable-threads' flag, thus it requires win32 pthread port. Keith have > already given a right link for dlls download. Just to make stuff clear: you'll have to download pthreadGC1.dll, rename it to pthreadGC.dll and put it somewhere in your PATH. All try to build all future versions of binaries

According to the instruction manual of this target machine, 'goto' should not be used in C code. :-/ Could you tell me a little more about your advice as to using 'reg2mem', if you're fine? Thank you so much, Anton. Best, Seung J. Lee ---- Original message ---- >Date: Sun, 15 Jul 2007 02:23:27 +0400 >From: Anton Korobeynikov <asl at math.spbu.ru> >Subject:

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

Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack

Hi Anton, Is the patch going to be uploaded to the CVS source? Ashwin On 5/24/06, Evan Cheng <evan.cheng at apple.com> wrote: > > > 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

The patch is now in. Sorry about the delay! Evan On May 25, 2006, at 10:20 AM, Ashwin Chandra wrote: > Hi Anton, > Is the patch going to be uploaded to the CVS source? > > Ashwin > > > On 5/24/06, Evan Cheng <evan.cheng at apple.com> wrote: > > On May 24, 2006, at 5:03 AM, Anton Korobeynikov wrote: > > > Hello, Ashwin. > > > > You wrote

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

The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using

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, 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, Rafael > With this patch I was able to bootstrap gcc in linux x86-64 with > shared libraries enabled :-) Awesome! But... -ENOPATCH :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.