similar to: [LLVMdev] misc CVS patches

On Wed, 20 Apr 2005, 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: >> >>> 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 >

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 Thu, Apr 21, 2005 at 05:56:43PM +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > >This patch can't be applied. Not all platforms have getgid() and > >getuid() functions. Placing non-portable code outside of lib/System > >is deprecated. We set the values to 1000 by default because in > >general the uid/gid doesn't matter in an archive and the 1000

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 >

Markus, This patch can't be applied. Not all platforms have getgid() and getuid () functions. Placing non-portable code outside of lib/System is deprecated. We set the values to 1000 by default because in general the uid/gid doesn't matter in an archive and the 1000 value gets you to a safe (non-root, non-system) value. If a specific value for these is needed on a given platform, then we

Nope. Win32 is not (and does not pretend to be) POSIX compliant. These functions cannot be used outside of lib/System/Unix. New methods need to be added to class llvm::sys::Process. Markus F.X.J. Oberhumer wrote: > Jeff Cohen wrote: > >> Misha Brukman wrote: >> >>>> I didn't use get{u,g}id() because that's not portable - I think we >>>> need

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

On Fri, Apr 22, 2005 at 03:13:44AM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > >>[...] > >>bugpoint: Unknown command line argument '-instcombine-load-vn'. Try: > >>'bugpoint --help' > > > >You need a space between -instcombine and

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 Thu, Apr 21, 2005 at 10:25:45PM +0200, Markus F.X.J. Oberhumer wrote: > while you're at this, may I also ask you to look at "indenting by tabs" > ? Some (rather few) source files have hard tabs which could be changed > to spaces in this cleanup process. OK, I'll do this in the next pass over the tree. -- Misha Brukman :: http://misha.brukman.net ::

Yeah, that's fine. I'll change it soon. Reid. On Thu, 2005-04-21 at 18:32 +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > 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

On Thu, Dec 23, 2004 at 06:42:02AM +0100, Markus F.X.J. Oberhumer wrote: > 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. Sounds great! I'll add it to the list of supported platforms. > This means that compilation, bytecode management and CWriter output > all work as

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 Fri, Apr 22, 2005 at 02:21:05AM +0200, Markus F.X.J. Oberhumer wrote: > Many thanks - attached you will find a list of files you still might > want to consider. Hmmm, those pesky .c and .in files, but I thought I covered all the .h and .cpp files... darn. OK, I'll trade you -- can you tell me how I can grep for a tab within a file? The following don't work for me: grep

On Apr 20, 2005, at 0:01, Misha Brukman wrote: > Sure. Patches are accepted, but please separate formatting changes > from > functionality changes into different patches. Speaking of random formatting changes, I've noticed in a few pages that the doxygen documentation comments incorrectly only have two '//' characters on the line. Hence, no doxygen documentation gets

On Wed, 20 Apr 2005, Evan Jones wrote: > On Apr 20, 2005, at 0:01, Misha Brukman wrote: >> Sure. Patches are accepted, but please separate formatting changes from >> functionality changes into different patches. > > Speaking of random formatting changes, I've noticed in a few pages that the > doxygen documentation comments incorrectly only have two '//'

On Fri, Apr 22, 2005 at 01:46:53AM +0200, Markus F.X.J. Oberhumer wrote: > Debugging code generator problem! > <cbe><gcc><program>Warning: While generating reference output, program > exited with > non-zero exit code. This will NOT be treated as a failure. > > *** The C backend cannot match the reference diff, but it is used as the > 'known good'

On Fri, Apr 22, 2005 at 02:14:23AM +0200, Markus F.X.J. Oberhumer wrote: > Hmm - is there some option so that bugpoint automatically runs all the > passes that are normally run by gccas and gccld ? Nope, that's not built into bugpoint, hence the procedures in the document. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > Ok, after pasting the output from "gccas -debug-pass=Arguments > </dev/null -o - >/dev/null" I get the following: > > bugpoint -verify -lowersetjmp -funcresolve -raiseallocs -simplifycfg > -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine > -simplifycfg -prune-eh

On Thu, 21 Apr 2005, Reid Spencer wrote: > 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. I'd rather not have CVS commit scripts mucking with the code. If you want to have the nightly tester whine about source code with spaces at the end of lines (like it whines about