similar to: [LLVMdev] LLVM on OpenBSD

Hello, Edd > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node > > type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function > > "ApplyTypeConstraints" Could you please try with gcc 4.x and check, whether

Hello, Edd > I am a student considering a compiler design based dissertation with > llvm. I am having problems building llvm on OpenBSD-current. I hope to > make a port of llvm for OpenBSD once I have figured out how to build What is the gcc version used there? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi, Edd > Are you aware of this? Is there a fix? gcc 3.3 ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and 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

3.3 has been unsupported since late 2005 .... On Fri, Nov 14, 2008 at 6:42 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> Im guessing I need 4 then :) > I think we need to explicitly document 3.4+ as a prerequisite. I bet > nobody will ever care about 3.3, sorry. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics,

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

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

Hello, Paolo. > I hope this is usefull, I'm pretty new to OS X. Well. From your example you have got the only valgrind results: ==28336== 58 bytes in 2 blocks are possibly lost in loss record 70 of 127 ==28336== at 0x4020A92: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==28336== by 0x410010B: std::string::_Rep::_S_create(unsigned, unsigned,

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

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

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

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.

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.