similar to: [LLVMdev] 2.0 Release Process

Le Tue, May 08, 2007 at 10:17:41PM -0700, Tanya M. Lattner écrivait/wrote: > > Here is the schedule: > > May 7th - Release branch created. Developers should begin reviewing > all documentation. > > May 14th - Tar balls and binaries are released for general testing. I'll > also need volunteers to create additional llvm-gcc binaries that I have > not provided.

Dear All, according to http://llvm.org/SVNMigration.html the repository migrated to SubVersion (svn) on june 5th 2007 (almost 10 days ago). Did the migration happened as expected? http://llvm.org/releases/ still mention CVS, and nothing on http://llvm.org/docs/GettingStarted.html#checkout suggest to switch to svn instead of cvs. What is the current best way to download the latest snapshot:

The release branch has been created and the llvm-gcc mirror updated (thanks Bill!). I will be doing some preliminary testing before I request the help of the community to test the release. During this time, I ask that developers only commit documentation changes to the release branch and email the list with any bug fixes that need to be merged into the release branch. Bug fixes have to be

Basile STARYNKEVITCH wrote: > Dear All, > > according to http://llvm.org/SVNMigration.html the repository migrated to SubVersion (svn) > on june 5th 2007 (almost 10 days ago). > The migration was delayed. The subversion software was supposed to be configured this week by our IT department, but I have not heard from them yet. I've fired off an email to see what the status

Hello Apparently the file llvm/examples/Fibonacci/fibonacci.cpp generate JIT code without explicitly doing any pass (but I suppose that internally, compiler passes are running!) - is there a dissymetry between JIT machine code generation in memory, and C or ELF shared object generation in files? I thought that all these shared a lot of LLVM infrastructure and happen similarily! Also, the

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 >

All LLVM Developers: This is your notice that the LLVM project is converting from CVS to Subversion for its software repository. The conversion will happen on June 5th, 2007 unless otherwise notified. Please see http://llvm.org/SVNMigration.html for full details. We had hoped to have the conversion done by now, but a number of factors made it prudent for us to delay for a few more weeks. There

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

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

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.

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.

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,

> 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, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

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.

> 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 "msvc-compabile" - isTargetWin32() which means "everything on windows", so

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