similar to: [LLVMdev] [patch] native AMD64 support

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

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 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

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

I will definately look into this tonight and see if it is a problem with my recent patch. On Wednesday 02 March 2005 3:39 am, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > >>Follow up: After removing the dangling symlink the problem now looks: > >> > >>-march=c((anonymous

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

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

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, We are in the process of trying to make this happen. It's a matter of getting all the duckings lined up in a row. We finally resigned ourselves to the fact that we can't cvs/svn and maintain the sanity of FSF branches, Apple branches and LLVM branches. So, over the next few working days we are going to set up a nightly cron script to checkout the latest and greatest

Adam, Looks like you have your first issue with the gccld patch. Could you please look into this for us? Markus seems to have detected a situation where -native-cbe is acting like -native ... On Wed, 2005-03-02 at 00:39, Markus F.X.J. Oberhumer wrote: > Short update: -native-cbe is currently broken as gccld/llc seems to generate > assembler code instead of C. To easy debugging of such

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

On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Sat, 7 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> As I've just seen that there are some things going on w.r.t the long >>> needed implementation of calling conventions, may I also ask if it's >>> possible to address inlining at the same moment (i.e. attributes

On Wed, 2004-12-22 at 22:09, Markus F.X.J. Oberhumer wrote: > Below you will find a small patch for llvm/autoconf/configure.ac that fixes > wrong AC_SUBST usage and adds AMD64 detection. Please review. > > ~Markus > --- autoconf/configure.ac 22 Dec 2004 05:56:56 -0000 1.147 > +++ autoconf/configure.ac 23 Dec 2004 06:06:04 -0000 > @@ -139,7 +139,8 @@ >

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 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

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

"Markus F.X.J. Oberhumer" <markus.oberhumer at jk.uni-linz.ac.at> writes: > Package: ssh > Version: 1.2.1pre24-1 > Severity: important > > I've just upgraded from ssh-nonfree to openssh and it seems > that openssh doesn't allow an additional `=' in the > config file options - but ssh 1.2.27 does. > > Attached is my ~/.ssh/config. > >

On Wed, 2 Mar 2005, Markus F.X.J. Oberhumer wrote: > When running the current CVS version on an AMD64 (targeted at 64-bits) I hit > the following when trying to link with -Wl,native-cbe: > > march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e] > /lib/libc.so.6(abort+0xcc)[0x556abbbc] > -march=c[0x8261958] > [0x8afe738] > gccld: /usr/lib/../lib64/X11:

On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > Follow up: After removing the dangling symlink the problem now looks: > > -march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e] > -fno-strict-aliasing: example.out.cbe.c: No such file or directory > gccld: example.out.cbe.c: Can't destroy file: > make: *** [example.out] Error 1 > At a minimum that