similar to: [LLVMdev] Build problems, LLVM 2.0's GCC front-end.

I'm getting behaviour I don't understand from my attempt to build the GCC front end under Ubuntu Edgy. Everything seems to work fine until I hit this: stage1/xgcc -Bstage1/ -B/home/michael/software/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic

Hello, Scott > Thanks, I am making some progress. The latest from svn (for llvm and > llvm-gcc) built successfully. I built everything without adjusting the > PATH, so I guess I used gcc 4.1.2. Even if you'll succeed, most probably LLVM will be miscompiled. gcc 4.1.2 is known buggy: http://llvm.org/docs/GettingStarted.html#brokengcc --- With best regards, Anton Korobeynikov.

Hello, Scott > Yes, so I have read -- which is why I initially installed gcc-4.2.4. > My original post was looking for help on how to use gcc-4.2.4. Some > suggestions were made, but I was not able to get everything built. It > seems that despite attempting to configure with everything pointing to > gcc-4.2.4 (and not the system gcc 4.1.2), at some point in the build, >

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.

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, Bernardo > > My host OS is Ubunut 8.04. "make install" completed sucessfully, > but I do not see a file called libstdc++.dylib in the `pwd`/../ > install/lib/libstdc++.dylib area. In fact, I can't find any file > with an extension .dylib. > > Have I done something wrong or is this a known issue with a > workaround? You won't have any

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, Nicolas > Thanks a lot for the heads up. I hadn't run into any problems yet with my > hack because I haven't used other callee-saved registers so far. Anyway, I'm > looking forward to your fix! I've commited the first series of patches to ToT to unbreak win64, basically: 1. Honour register save area 2. Enable proper passing of __m128 and __m64 arguments 3. Minor

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

Thanks! What revision is your commit? I'd like to have a closer look at your patch in an attempt to understand the issue better, and maybe try fixing the callee-saved problem. Cheers, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: woensdag 5 augustus 2009 9:35 To: LLVM Developers Mailing

Hello, Argiris > Can you please try out the steps I mentioned before with the linux > binaries ? I just want to make sure that there's not something wrong > with my setup. Here they are: $ cat dbg.c int main() { return 0; } $ gdb a.out GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

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

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.

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.

> 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

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

Chris Lattner wrote: > On Thu, 16 Mar 2006, Vladimir Prus wrote: >> Ah, hell, as soon as I've send this email I've updated from CVS to find >> that the issue was fixed by Jim several hours after I reported the crash, >> by making MachineDebugInfo don't check for empty name of type. > > :) > >> Here's what I get now: >> >>

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,