similar to: Using gcc4 visibility features

> Please lemme know if it works. It does. Thanks. > I don't know what that is :( I believe that code compiled without -fpic is going into a DSO. This creates text relocations that are not supported on linux/amd64 (http://people.redhat.com/drepper/dsohowto.pdf). > -Chris Rafael

On Fri, 8 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am not sure if it is the correct solution, but the attached patch > fixes the problem. Your solution is correct, in that it will work and follows with the current ifdef approach. I applied this patch though, which doesn't use the ifdefs, hopefully it is more robust:

Domagoj, > Is that change absolutely necessary? Unfortunately, yes. We're having at least two PRs opened for aliases including libstdc++ compilation in shared mode for x86/linux. > I've just spent 2 days compiling benchmarks. So, now I'd need to > ditch all that and start from scratch... No. Bytecode will be breaking only if it have module-wide assembler. I don't think

llvm-gcc4 currently references some files from the build directory of llvm, but looking through the make file, I haven't yet come across a file that llvm-gcc4 needs that isn't installed with llvm. I checked, and all the headers for the src and obj are installed into ${prefix}/include/llvm and ${prefix}/include/llvm-c. All the main object files are the same as well. The only difference

On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > Which one is correct ? > - movl $tm_nest_level at TPOFF, %ecx > or > - movq $tm_nest_level at TPOFF, %rcx > or > - movl tm_nest_level at TPOFF, %ecx > I believe this is initial exec and so from: http://people.redhat.com/drepper/tls.pdf it would be movl tm_nest_level at TPOFF, %ecx > Otherwise, Is there a

John, This was my attempt to add symbol versioning to the library, letting us break ABI without breaking any existing callers. Unfortunately it doesn't work: - the new versioned symbols are marked local in libguestfs.so - the existing symbols should now have @GUESTFS_0.0 versions, but don't The documentation for this stuff is extremely thin, and I've got a bad case of

On Mon, 4 Feb 2008, Brian Hurt wrote: > Another possibility, and I'm not sure how to do this in LLVM, would be to > sacrifice a register to hold the pointer to the unique per-thread > structure. This would be worthwhile to me even on the register-starved > x86-32. I suppose I could also just add a "hidden" (compiler-added and > -maintained) argument to every function

On Tue, 5 Feb 2008, Chris Lattner wrote: > On Mon, 4 Feb 2008, Brian Hurt wrote: >> Another possibility, and I'm not sure how to do this in LLVM, would be to >> sacrifice a register to hold the pointer to the unique per-thread >> structure. This would be worthwhile to me even on the register-starved >> x86-32. I suppose I could also just add a "hidden"

On Jul 7, 2010, at 11:20 AM, Eric Christopher wrote: > > On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > >> Which one is correct ? >> - movl $tm_nest_level at TPOFF, %ecx >> or >> - movq $tm_nest_level at TPOFF, %rcx >> or >> - movl tm_nest_level at TPOFF, %ecx >> > > I believe this is initial exec and so from: > >

On Wed, Sep 17, 2008 at 12:32:40PM +0300, Kirill A. Shutemov wrote: > On Tue, Sep 16, 2008 at 07:09:02PM +0300, Adrian Bunk wrote: > > On Tue, Sep 16, 2008 at 07:10:25AM -0700, Ulrich Drepper wrote: > > > Kirill A. Shutemov wrote: > > > >> What is the error message? > > > > > > > > /usr/include/asm-generic/fcntl.h:117: error: redefinition

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

Devang Patel wrote: > > On Aug 23, 2006, at 7:00 PM, Emil Mikulic wrote: > >> Where -is- that documented? >> >> The only reason I know about it is because of how many times it's come >> up on the list. =) > > http://llvm.org/docs/GettingStarted.html ? > > ... > Example with llvm-gcc4 > First, create a simple C file, name it

Ryan Brown wrote: > I don't think llvm-gcc4 uses gccas or gccld, but it can emit bytecode > if you give it the --emit-llvm option: > llvm-gcc --emit-llvm -c -o foo.bc foo.c That's a bit asymmetric with the previous gcc3 version, isn't it? That would mean that the "An Example Using the LLVM Tool Chain" section needs to be updated for the gcc4 frontend. OTOH, I could

There should also be a large notice in 40 point font and bold that says, "gcc4 does not produce byte code by default: you must use the -emit-llvm flag to get LLVM byte code." Erick Tryzelaar wrote: > Hello, > > It looks like the "Getting Started" is missing some info about the gcc > 4.0 frontend. Since it doesn't follow the setup of the cfrontend/gcc3.4 >

Andrew Purtell wrote: > I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. > > > cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor&

On 11 May 2017 at 12:16, Patrick Perry wrote: | I've done a bit more investigation into this issue. Here is my current | understanding of the situation: | | 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all | platforms except for Linux. | 2. My package defines a C function, "xrealloc", for internal use. | 3. The libreadline library that R links to defines a

Hello, It looks like the "Getting Started" is missing some info about the gcc 4.0 frontend. Since it doesn't follow the setup of the cfrontend/gcc3.4 package, a couple sections describing the front end don't cover the gcc4 package. Here are the couple things I'd wish could be fleshed out a bit more: Under "Getting Started Quickly (A Summary)", it'd be nice

I know that Al Stone has compiled llvm-gcc4 successfully and I can report the same. The problem I consistently run into is that llvm-gcc ends up producing native format output; it does not produce bytecode, nor does it invoke gccas or gccld. I'm using the latest svn, and my configure args are: --prefix=/work/scottm/llvm-cfrontend/obj/../i686-pc-linux-gnu \

Hi, I'm trying to track down some nasty glibc failures on Linux. I think the problem is that my system compiler (3.4.6) doesn't match llvm-gcc (4.0.x) so when the llc compiled programs run they don't quite get the right libstdc++. If I run a test program with: LD_LIBRARY_PATH=/path/to/my/llvm-gcc4/libs Output/sieve.llc then I get this: Output/sieve.llc: symbol lookup error: