similar to: [LLVMdev] New llvm-gcc4 snapshot

Hi all, as suggested on the mailing list I have converted the updated LZO code into git, so please pull my "lzo-update" branch from git://github.com/markus-oberhumer/linux.git lzo-update You can browse the branch at https://github.com/markus-oberhumer/linux/compare/lzo-update I''d ask some official kernel maintainer for review and to push this into linux-next so that it

This changes the build to use llvm-config to figure out which llvm libraries to link in. This fixes build problems when libraries change from .a's to .o's (like yesterday) or when dependencies between libraries change. http://nondot.org/sabre/2006-06-01-llvm-gcc-4.tar.gz It also eliminates some warnings, which enables bootstrap, tested on Darwin PPC/X86. -Chris --

On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >

There was a patch that went thru for this recently from Rafael Espindola. The fix is on the mirror. Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 120589) +++ gcc/dwarf2out.c (working copy) @@ -14361,9 +14361,8 @@ s->refcount++; /* Avoid unnecessarily putting strings that are used less than twice in the hash

Dear LLVMers, If you live on the bleeding edge (i.e. CVS version), please read! On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Do you really want external patches for this ? A simple Perl script > that runs on all *.h and *.cpp files, and a local commit from your > side would be much simpler. I'm in the process of doing just this as we speak. What this

I'm getting a build error when trying to build gcc4 from sources. This is for the recent 1.9 release. How I built llvm-1.9: ----------------------------- tar zxf llvm-1.9.tar.gz cd llvm-1.9/ ./configure --prefix=/custom/llvm-1.9 make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION='-O2' tools-only make install How I built gcc4: ----------------------------- export

On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote: > sys::Program::ExecuteAndWait() requires that the first element in "args" > should be the name of the program, but (at least) llvm-ld.cpp and gccld.cpp > fail to do so, thereby effectively swallowing the first parameter. > This is the reason that -native-cbe has not working for some time - actually > I wonder why no

Markus F.X.J. Oberhumer schrieb: > The reason behind this is that llvm-gcc is based on a pre-3.4 snapshot > ("3.4-llvm 20030924") then it's not unlikely that these are llvm bugs since my code also compiles with gcc 3.3 filed PR 551 and 552 -- Stefan Strasser

On Thu, 2005-04-21 at 17:56 +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > If a specific value for these is > > needed on a given platform, then we need to implement something like > > "getDefaultUserId" and "getDefaultGroupId" functions in lib/System and > > use those in lib/Bytecode/Archive. > > That's probably the

On Thu, 5 May 2005, Markus F.X.J. Oberhumer wrote: > Chris, > Chris Lattner wrote: >> For anyone who is interested: >> http://llvm.cs.uiuc.edu/pubs/2005-05-04-LattnerPHDThesis.html > > many congrats, and best wishes for the future! Thanks all! > And I hope you still will have some time to look after LLVM and won't > get too distracted by some new exciting other

On Fri, 2005-05-13 at 08:06 +0200, Markus F.X.J. Oberhumer wrote: > Actually that's the only case I stumbled over this problem in a somewhat > larger C++ program, and it's clearly the wrong type in LowerInvoke.cpp - > it really should be IntPtrTy. But maybe we could use just IntTy here to > avoid target dependencies. Wait a minute. You want to lower a 64 bit thing to a 32

Why not put all this into a pre-commit filter in CVS and be done with it? We'd never be bothered with it again as it would never be committed again. Reid. On Thu, 2005-04-21 at 15:11 -0500, Misha Brukman wrote: > Dear LLVMers, > > If you live on the bleeding edge (i.e. CVS version), please read! > > On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote:

On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer wrote: > While trying to hunt down a codegen bug (not yet found) ... Have you considered using bugpoint for your codegen debugging needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > I've collected some small patches you might find useful. Sweet! > Please review and apply as you see fit. I've

On Thursday 10 February 2005 21:47, Markus F.X.J. Oberhumer wrote: > In order to get more familiar with the llvm sources I've recently > decided to try to add support for the always_inline and noline function > attributes. I believe it is better to let the compiler decide when or not to inline a function. Most of the times a developer goes overboard with inlining and ends up with a

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > I see that you are objecting explicit inline control. > > The main problem is that inlining is absolutely crucial for some > "modern" programming styles. E.g. we use a huge collection of small C++ > template classes and template metaclasses, most of which have very > trivial and limited functionality (think of it

Hi Markus, Thanks for this interesting patch! It looks okay to me, but our C/C++ Front End guru is away right now. I would rather defer to him on this patch. He might not get to it until next week so I just wanted to let you know that there might be a bit of a delay before this patch hits mainline. I've already committed your configure changes. Reid. On Wed, 2004-12-22 at 21:42, Markus

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very

There is one case where inlining/not-inlining affects correctness. A function which uses alloca() will behave differently in the two cases. You can argue one shouldn't write code like this, but it is legal. Chris Lattner wrote: > On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > >> I see that you are objecting explicit inline control. >> >> The main problem is

http://trac.xiph.org/cgi-bin/trac.cgi/ticket/583 looking at why gcc4 could increase vorbis so much, i first had a look at the compiler options, and i saw -O20, as far as i know there is -O0, .. -O3 and -Os but no -O20. changing that to -O2 (patch attached) one gets close to the result of gcc-3.4. gcc3.4-O20.ogg 20423 gcc4-O20.ogg 54623 gcc4-O3.ogg 54623 gcc4-O2.ogg 20423 looking

On Mar 31, 2007, at 11:35 PM, Erick Tryzelaar wrote: > I'm having some trouble getting llvm-gcc4 to compile. It's unable to > compile darwin-crt3.c. It's mentioning "Complex expression. Absolute > segment assumed." but I'm not sure if that's a real error message. Has > anyone run into this before? I'm running on a G4 apple 10.4.8, kernel > version