Re: Void Pointer Alignment - GCC 3.4.6

On Thu, Jan 29, 2009 at 11:39 AM, Ian Lance Taylor wrote: > Rohit Arul Raj writes: > >> I am working with GCC 3.4.6 for a private target. The Alignment of all >> pointer variables in my target is supposed to be 16bits. But it seems >> that for void pointers, the alignment by default is taken as 8

Re: Void Pointer Alignment - GCC 3.4.6

Rohit Arul Raj writes: > I am working with GCC 3.4.6 for a private target. The Alignment of all > pointer variables in my target is supposed to be 16bits. But it seems > that for void pointers, the alignment by default is taken as 8 bits. I > have defined the following macros to get the desired a

Void Pointer Alignment - GCC 3.4.6

Hi All, I am working with GCC 3.4.6 for a private target. The Alignment of all pointer variables in my target is supposed to be 16bits. But it seems that for void pointers, the alignment by default is taken as 8 bits. I have defined the following macros to get the desired alignment but still it do

sizeof in initializer expression not working as expected

Hi, I was trying to figure out how come a memory allocation was short. I think I've stumbled onto the issue. "evt_t" is a 48 byte structure and "tpd_uptr" is a uintptr_t. "sz" initializes to 52 (decimal). The value would be correct if I were not trying to multiply the size of the pointer by 4.

gcc 4.4.0 loop-unrolling optimizations peculiarity observed

gcc version: powerpc-apple-darwin8.11.0-gcc-4.4.0 (GCC) 4.4.0 20090116 (experimental) version is a macports (formerly darwin ports) build of gcc4.4.0 on an OSX 10.4.11 ppc7450 host Following C function produces different code depending on the use of 'loop_Ai' vs 'direct_assignment_Ai' snippets: f

Re: New GCC Runtime Library Exception

On Wed, Jan 28, 2009 at 11:17:27AM -0800, Mark Mitchell wrote: > > lines long) distributed by GCC that go into runtime libraries used by > > GCC-compiled code, except those shared with outside projects such as glibc > > and Classpath (but including e.g. the non-Classpath files in libjava, and > >

Re: CGEN-generated files vs GPL

On Wed, Jan 28, 2009 at 02:05:45PM -0800, Joseph S. Myers wrote: > On Wed, 28 Jan 2009, DJ Delorie wrote: > > > What are the implications (GPL-wise) of using CGEN-generated files in > > gcc? Specifically, I'm working on a second attempt to contribute the > > MeP port, and its intrinsics are CGEN-

Re: New GCC Runtime Library Exception

Joseph S. Myers wrote: > Then there are lots of other miscellaneous license issues: files that have > been added with GPLv2 on the host side since the main transition was done, > I don't know what issues are or are not considered how critical. Let's not turn this into a complete license

Re: New GCC Runtime Library Exception

On Wed, 28 Jan 2009, Mark Mitchell wrote: > Joseph S. Myers wrote: > > > The tm.h headers are a lot of essentially host-side code with a few macros > > such as LIBGCC2_LONG_DOUBLE_TYPE_SIZE that affect target-side code in some > > cases. But if we should add the exception to over 8 lines o

gcc-4.2-20090128 is now available

Snapshot gcc-4.2-20090128 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090128/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: incorrect license on some gcc/*.c files?

On Wed, Jan 28, 2009 at 11:29 PM, Ben Elliston wrote: > After reading about the new runtime license, I did some grepping through > the gcc/ directory to see how many files would need updating. I was > surprised to discover three files that are part of GCC proper, but are > still under GPLv2. Sho

incorrect license on some gcc/*.c files?

After reading about the new runtime license, I did some grepping through the gcc/ directory to see how many files would need updating. I was surprised to discover three files that are part of GCC proper, but are still under GPLv2. Shouldn't these all be GPLv3? M tree-parloops.c M ipa-s

Re: CGEN-generated files vs GPL

On Wed, 28 Jan 2009, DJ Delorie wrote: > > I believe the source code (i.e., what you'd change to modify the > > intrinsics) needs including in the GCC release tarballs. I don't > > think CGEN itself needs including, any more than OCaml needs > > including because the ARM NEON intrinsic generators

Re: CGEN-generated files vs GPL

> I believe the source code (i.e., what you'd change to modify the > intrinsics) needs including in the GCC release tarballs. I don't > think CGEN itself needs including, any more than OCaml needs > including because the ARM NEON intrinsic generators are written in > OCaml. The same cgen files p

Re: New GCC Runtime Library Exception

Joseph S. Myers wrote: > The tm.h headers are a lot of essentially host-side code with a few macros > such as LIBGCC2_LONG_DOUBLE_TYPE_SIZE that affect target-side code in some > cases. But if we should add the exception to over 8 lines of code > (the amount of config/*.h and config/*/*.h

Re: Request for testing/help for the LTO branch

On Tue, Jan 27, 2009 at 1:24 PM, H.J. Lu wrote: > On Tue, Jan 27, 2009 at 1:11 PM, Diego Novillo wrote: >> The LTO branch is starting to get some semblance of stability, though >> is by no means in any kind of mergeable state. I have updated the >> wiki page to reflect the current status (Simon,

Re: New GCC Runtime Library Exception

On Wed, 28 Jan 2009, Mark Mitchell wrote: > > (But that e.g. Makefiles building the libraries > > should use GPLv3+ without any exception, and tm.h headers should not have > > the exception even though they provide a few macros for libgcc.) > > Yes, except that I think tm.h headers should have

Re: CGEN-generated files vs GPL

On Wed, 28 Jan 2009, DJ Delorie wrote: > What are the implications (GPL-wise) of using CGEN-generated files in > gcc? Specifically, I'm working on a second attempt to contribute the > MeP port, and its intrinsics are CGEN-generated (and there are a *lot* > of them - most opcodes have an intrinsic

Re: CGEN-generated files vs GPL

DJ Delorie writes: > What are the implications (GPL-wise) of using CGEN-generated files in > gcc? Specifically, I'm working on a second attempt to contribute the > MeP port, and its intrinsics are CGEN-generated (and there are a *lot* > of them - most opcodes have an intrinsic). [...] My under

Re: Serious code generation/optimisation bug (I think)

On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote: > Zoltán Kócsi wrote: > >> No, this is since C90; nothing has changed in this area. NULL > >> doesn't mean "address 0", it means "nothing". The C statement > >> > >> if (ptr) > >> > >> doesn't mean "if ptr does not point to address z

Re: Serious code generation/optimisation bug (I think)

Paweł Sikora wrote: do you say that we can't write a valid/defined program in C for e.g. arm architercture? on some arms, the object (vector interrupt table) starts at adress 0x0. If 0 is a valid address, then it is improper for the compiler to use 0 to represent the null pointer. You may have

Re: Serious code generation/optimisation bug (I think)

Zoltán Kócsi wrote: You say: "You can't dereference a NULL pointer" I say: "You shouldn't dereference a NULL pointer" Yes, but the standard says can't in effect, and gives no idea of what it might mean to dereference a null pointer. I shouldn't but I most certainly can. I can generate a NUL

Re: New GCC Runtime Library Exception: amendment proposal

Joern Rennecke wrote: 1. Grant of Additional Permission. You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was eithwe g

Re: RFC: case insensitive for #include

"H.J. Lu" writes: > Say I have > > #include "Foo/Foo.h" > > I want to map it to foo/foo.h on disk. Can I map Foo to foo with > header.gcc in directory, foo? Yes. Put this at top level (i.e., in the same directory where the directory "foo" is): Foo/Foo.h foo/foo.h Then #include "Foo/Foo.h" wil

Re: RFC: case insensitive for #include

On Wed, Jan 28, 2009 at 12:48 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Wed, Jan 28, 2009 at 12:32 PM, Ian Lance Taylor wrote: >>> "H.J. Lu" writes: >>> I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comme

Re: RFC: case insensitive for #include

"H.J. Lu" writes: > On Wed, Jan 28, 2009 at 12:32 PM, Ian Lance Taylor wrote: >> "H.J. Lu" writes: >> >>> I got a request to try "FOO.H" if foo.h doesn't exist when dealing >>> with >>> >>> #include "foo.h" >>> >>> Any comments? >> >> Please, no. >> >> They could use header.gcc instead. >> >> h

Re: RFC: case insensitive for #include

On Wed, Jan 28, 2009 at 12:32 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> I got a request to try "FOO.H" if foo.h doesn't exist when dealing >> with >> >> #include "foo.h" >> >> Any comments? > > Please, no. > > They could use header.gcc instead. > > http://gcc.gnu.org/onlinedocs/cppinte

CGEN-generated files vs GPL

What are the implications (GPL-wise) of using CGEN-generated files in gcc? Specifically, I'm working on a second attempt to contribute the MeP port, and its intrinsics are CGEN-generated (and there are a *lot* of them - most opcodes have an intrinsic). I'd rather not have to manually enter all t

Re: RFC: case insensitive for #include

H.J. Lu wrote: On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner wrote: On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote: Hi, I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comments? I strongly recommend against this, unless this is only a "last chan

Re: RFC: case insensitive for #include

"H.J. Lu" writes: > I got a request to try "FOO.H" if foo.h doesn't exist when dealing > with > > #include "foo.h" > > Any comments? Please, no. They could use header.gcc instead. http://gcc.gnu.org/onlinedocs/cppinternals/Files.html Ian

Re: RFC: case insensitive for #include

On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner wrote: > > On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote: > >> Hi, >> >> I got a request to try "FOO.H" if foo.h doesn't exist when dealing >> with >> >> #include "foo.h" >> >> Any comments? > > I strongly recommend against this, unless this is only a

Re: RFC: case insensitive for #include

On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote: Hi, I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comments? I strongly recommend against this, unless this is only a "last chance" fall back. From a performance standpoint, if you have -Idir1 -I

Re: RFC: case insensitive for #include

On Wed, Jan 28, 2009 at 12:03 PM, David Daney wrote: > H.J. Lu wrote: >> >> Hi, >> >> I got a request to try "FOO.H" if foo.h doesn't exist when dealing >> with >> >> #include "foo.h" >> >> Any comments? >> > > How about "Foo.h", "FOo.H", etc.? > > I have found as many errors with mixed case screw

Re: RFC: case insensitive for #include

H.J. Lu wrote: Hi, I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comments? How about "Foo.h", "FOo.H", etc.? I have found as many errors with mixed case screw-ups as with the 'single case' variety you mention. Would you want to make it full

RFC: case insensitive for #include

Hi, I got a request to try "FOO.H" if foo.h doesn't exist when dealing with #include "foo.h" Any comments? Thanks. -- H.J.

Re: New GCC Runtime Library Exception

Joseph S. Myers wrote: > Is the full wording of a sample copyright/license header that should go in > all affected GCC source files available? I will check on this. I think I may have something from the FSF about that; if not, we'll figure out what to do. > Do I understand correctly that all

Re: New GCC Runtime Library Exception: not fit for purpose

Joern Rennecke writes: > The definition of 'independent module' is such that it does not include files > that make no use of any runtime interfaces at all. E.g. a newlib file > is an independent module if it uses a multiply and that multiply is > implemented as a libgcc function all by gcc, but

Re: Request for testing/help for the LTO branch

> My testing indicates otherwise, apart from the lack of support for some > newer Solaris features. I presume it's again the combination Sun as + GNU ld? -- Eric Botcazou

Re: Request for testing/help for the LTO branch

Joe Buck writes: > > Ok, I see. Maybe we can extend Sun ld to handle that, given that the > > sources are now open via OpenSolaris. > > Or just use GNU ld on Solaris, it works. My testing indicates otherwise, apart from the lack of support for some newer Solaris features. Rainer

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 05:18:13AM -0800, Rainer Orth wrote: > But at least on Solaris, using GNU ld is sort of a problem: there are lots > of GCC testsuite regressions right now, and GNU ld doesn't support several > of Sun ld's advanced features, which is why I very much prefer to use the > native

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 05:11:51AM -0800, Rainer Orth wrote: > Rafael Espindola writes: > > > > I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets > > > (just not Linux, so using the system linker, not GNU ld). If I understand > > > you correctly, they might just work (modul

Re: Serious code generation/optimisation bug (I think)

On Wednesday 28 of January 2009 17:39:39 Andrew Haley wrote: > Zoltán Kócsi wrote: > >> No, this is since C90; nothing has changed in this area. NULL > >> doesn't mean "address 0", it means "nothing". The C statement > >> > >> if (ptr) > >> > >> doesn't mean "if ptr does not point to address ze

Re: Serious code generation/optimisation bug (I think)

Zoltán Kócsi wrote: >> No, this is since C90; nothing has changed in this area. NULL >> doesn't mean "address 0", it means "nothing". The C statement >> >> if (ptr) >> >> doesn't mean "if ptr does not point to address zero", it means "if ptr >> points to something". > > A question then: > > H

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

> Andreas Schwab writes: > >> Dennis Clarke writes: >> >> > One of the things I have had no joy with is figuring out how to >> > include the ada component but that is a battle for another day. >> >> To build ada you need a good ada compiler to start with. If you don't >> have one natively you n

PPS: New GCC Runtime Library Exception: amendment proposal

Hmm, I didn't specifically think of the case where the Source code is not a high level language, but a code generator is used to generate a high-level language which is to be compiled with gcc. E.g. someone might have some assembly Source Code which they translate to C to migrate to new hardware,

PS: New GCC Runtime Library Exception: amendment proposal

Sorry, something went wrong while I edited the message and it was sent prematurely. Quoting Joern Rennecke : A file is an "Independent Module" if it is not based on the Runtime Library, except that it may either require the Runtime Library for execution after a Compilation Process, or make use

New GCC Runtime Library Exception: amendment proposal

A file is an "Independent Module" if it is not based on the Runtime Library, except that it may either require the Runtime Library for execution after a Compilation Process, or make use of an interface provided by the Runtime Library. Definitions of "GCC" and "GPL-compatible sotware as in th

Re: cross-compilation, deprecated option and libgcc

On Tue, 27 Jan 2009 09:16:10 +1100, Ben Elliston wrote: > On Mon, 2009-01-26 at 14:19 +0100, Vincent R. wrote: > >> 1) When I compile bootstrap gcc, I am using make all-gcc and make >> install-gcc and it seems it doesn't build libgcc anymore. > > I think that's correct; make all-gcc just builds

Re: Serious code generation/optimisation bug (I think)

Zoltán Kócsi writes: > How can I make a pointer to point to the integer located at address > 0x0? It is a perfectly valid object, it exists, therefore I should be > able to get its address? In fact, if I have a CPU that starts its data > RAM at 0, then the first data object *will* reside at addre

Re: x86-64 and large code model questions/bugs

On Wed, Jan 28, 2009 at 1:40 AM, Andi Kleen wrote: > On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote: >> Andi Kleen wrote: >> > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote: >> >>> He'll get much better code by putting the program into a -fPIC .so, >> >>> loading it

Re: Serious code generation/optimisation bug (I think)

> No, this is since C90; nothing has changed in this area. NULL > doesn't mean "address 0", it means "nothing". The C statement > > if (ptr) > > doesn't mean "if ptr does not point to address zero", it means "if ptr > points to something". A question then: How can I make a pointer to point

New GCC Runtime Library Exception: not fit for purpose

The definition of 'independent module' is such that it does not include files that make no use of any runtime interfaces at all. E.g. a newlib file is an independent module if it uses a multiply and that multiply is implemented as a libgcc function all by gcc, but if the multiply is implemented b

Re: Request for testing/help for the LTO branch

Joseph S. Myers writes: > > Unfortunately, gold doesn't even build on non-Linux targets: see PR > > gold/7024. > > That actually appears to be a list of issues with non-Linux hosts, not > non-Linux targets. Right, I had ignored non-native builds since I rarely do them. > I would certainly hope

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 08:18, Joseph S. Myers wrote: > I would certainly hope both LTO and gold should work on a wide range of > non-Linux hosts (if anyone cares to contribute patches for such support), > including non-ELF hosts, even though restricted to ELF targets at least in > the case of go

Re: Request for testing/help for the LTO branch

Diego Novillo writes: > On Wed, Jan 28, 2009 at 08:18, Rainer Orth > wrote: > > > But at least on Solaris, using GNU ld is sort of a problem: there are lots > > of GCC testsuite regressions right now, and GNU ld doesn't support several > > of Sun ld's advanced features, which is why I very much

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 08:18, Rainer Orth wrote: > But at least on Solaris, using GNU ld is sort of a problem: there are lots > of GCC testsuite regressions right now, and GNU ld doesn't support several > of Sun ld's advanced features, which is why I very much prefer to use the > native linker

Re: Request for testing/help for the LTO branch

On Wed, 28 Jan 2009, Rainer Orth wrote: > Rafael Espindola writes: > > > > I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets > > > (just not Linux, so using the system linker, not GNU ld). If I understand > > > you correctly, they might just work (modulo bugs)? > > > > Th

Re: Request for testing/help for the LTO branch

Diego Novillo writes: > On Wed, Jan 28, 2009 at 08:11, Rainer Orth > wrote: > > > Unfortunately, gold doesn't even build on non-Linux targets: see PR > > gold/7024. > > Note that you don't really need gold to use LTO. It works just fine > with GNU ld. But at least on Solaris, using GNU ld is

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 08:11, Rainer Orth wrote: > Unfortunately, gold doesn't even build on non-Linux targets: see PR > gold/7024. Note that you don't really need gold to use LTO. It works just fine with GNU ld. What you get with gold and the linker plugin is mostly the ability to open up .a

Re: Request for testing/help for the LTO branch

Rafael Espindola writes: > > I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets > > (just not Linux, so using the system linker, not GNU ld). If I understand > > you correctly, they might just work (modulo bugs)? > > That should work. You still might need to extend the link

c-4_5-branch merge plan

Once 4.4 has branched I plan to merge the changes from c-4_5-branch to trunk. I plan to merge in three logical patches, each one with a logical change from the branch and all followups to that change combined into a single trunk commit, rather than merging the whole branch at once. * Constant

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 06:56, Rainer Orth wrote: > Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)? Yes, it should work on any ELF target. Diego.

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 05:36, Richard Guenther wrote: > /gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: internal > compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. >

Re: Request for testing/help for the LTO branch

On Wed, Jan 28, 2009 at 00:06, Chris Lattner wrote: > Thanks for the summary, it's great to see the progress of the project. Do > you have any compile time numbers for LTO so far? If you pick a mid-sided > program from spec or even a bootstrap, how much slower is LTO than compiling > at -O3? T

Re: Request for testing/help for the LTO branch

> I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets > (just not Linux, so using the system linker, not GNU ld). If I understand > you correctly, they might just work (modulo bugs)? That should work. You still might need to extend the linker to support IL in static librarie

Re: Request for testing/help for the LTO branch

Rafael Espindola writes: > > Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)? > > We need ELF for storing the IL files. In theory that is only a > container format and you could crate a plugin for the IRIX linker to > read it. I suppose you mis-parsed my question: Sola

Re: Request for testing/help for the LTO branch

> Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)? We need ELF for storing the IL files. In theory that is only a container format and you could crate a plugin for the IRIX linker to read it. >Rainer Cheers, -- Rafael Avila de Espindola Google | Gordon House

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

Andreas Schwab writes: > Dennis Clarke writes: > > > One of the things I have had no joy with is figuring out how to > > include the ada component but that is a battle for another day. > > To build ada you need a good ada compiler to start with. If you don't > have one natively you need to bu

Re: Request for testing/help for the LTO branch

Diego Novillo writes: > Essentially, the biggest areas where we need help are: > > - Testing on other targets. We have only tested on x86 (32 and 64 > bit) targets. I'm pretty sure other targets are either non-functional > or show major breakage. We'd appreciate any daily tester that could >

Re: Serious code generation/optimisation bug (I think)

Zoltán Kócsi wrote: I don't mean to complain, but I happen to work with embedded systems. I program them in C, or at least in a language that uses the syntactic elements of C. Yes, and that is an important distinction. If you program in C, you should program in C (and know the language). Wh

Re: Serious code generation/optimisation bug (I think)

Zoltán Kócsi wrote: > On Tue, 27 Jan 2009 07:08:51 -0500 > Robert Dewar wrote: > >> James Dennett wrote: >> >>> I don't know how much work it would be to disable this optimization >>> in gcc. >> To me, it is always troublesome to talk of "disable this optimization" >> in a context like this. The p

Re: Serious code generation/optimisation bug (I think)

On Tue, 27 Jan 2009 07:08:51 -0500 Robert Dewar wrote: > James Dennett wrote: > > > I don't know how much work it would be to disable this optimization > > in gcc. > > To me, it is always troublesome to talk of "disable this optimization" > in a context like this. The program in question is not

Re: Request for testing/help for the LTO branch

On Tue, Jan 27, 2009 at 11:02 PM, Diego Novillo wrote: > On Tue, Jan 27, 2009 at 16:58, H.J. Lu wrote: > >> LTO failed to bootstrap on RHEL5/ia32 and RHEL5/ia64: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992 > > Thanks. This was known to us, though we had not filed a request. > Essenti

Re: New GCC Runtime Library Exception

On Tue, 27 Jan 2009, Adam Nemet wrote: > Gerald Pfeifer writes: >> +January 27, 2008 > 2009 ;) Oops. Good catch! I guess that shows this was a bit of a lengthy process. ;-) Gerald

-ftime-report might wrap

Hello, I stumbled over a problem in timevar.c, function timevar_accumulate. When USE_CLOCK is set on a 32-bit system, the counter silently wraps around. This can result in negative time values, or some time being ignored (because one pass uses more than 72 minutes of time). A check like

Re: x86-64 and large code model questions/bugs

On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote: > Andi Kleen wrote: > > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote: > >>> He'll get much better code by putting the program into a -fPIC .so, > >>> loading it from a small stub and then unmap the stub. > >>> large mod

Re: x86-64 and large code model questions/bugs

Andi Kleen wrote: > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote: >>> He'll get much better code by putting the program into a -fPIC .so, >>> loading it from a small stub and then unmap the stub. >>> large model generates really very bad code because all jumps >>> will be indirect.

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

Dennis Clarke writes: > One of the things I have had no joy with is figuring out how to > include the ada component but that is a battle for another day. To build ada you need a good ada compiler to start with. If you don't have one natively you need to build a cross compiler on a system that h

Re: x86-64 and large code model questions/bugs

On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote: > > > He'll get much better code by putting the program into a -fPIC .so, > > loading it from a small stub and then unmap the stub. > > large model generates really very bad code because all jumps > > will be indirect. > > Is it also

Re: Request for testing/help for the LTO branch

> Hi Diego, > > Thanks for the summary, it's great to see the progress of the project. Do > you have any compile time numbers for LTO so far? If you pick a mid-sided > program from spec or even a bootstrap, how much slower is LTO than compiling > at -O3? We haven't tried a bootstrap with LTO ena

Re: Serious code generation/optimisation bug (I think)

Chris Lattner wrote: It will be quite a while before whole program optimization is good enough to prove that my_null_pointer is not referenced by anything else. Why not just make it volatile, that way, the compiler cannot assume anything about the value.

Re: x86-64 and large code model questions/bugs

> He'll get much better code by putting the program into a -fPIC .so, > loading it from a small stub and then unmap the stub. > large model generates really very bad code because all jumps > will be indirect. Is it also true with -fpie? Paolo