Re: [lto] Streaming out language-specific DECL/TYPEs

> On Mon, Jun 2, 2008 at 5:10 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > > In g++.dg/torture/20070621-1.C we are trying to stream out a structure > > that contains a TEMPLATE_DECL. This currently causes a failure in > > lto-function-out.c:output_tree because not only TEMPLATE_DECL is > > C++-s

Re: [lto] Streaming out language-specific DECL/TYPEs

On Tue, Jun 3, 2008 at 2:37 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Diego Novillo wrote: >> >> In g++.dg/torture/20070621-1.C we are trying to stream out a structure >> that contains a TEMPLATE_DECL. This currently causes a failure in >> lto-function-out.c:output_tree because not only TEMP

[MELT] branch Melt- bootstrapped & questions...

Hello All, See http://gcc.gnu.org/wiki/MiddleEndLispTranslator for MELT The MELT branch bootstrapped, in the sense that the Lisp compiler is able to compile itself to C code. It is not the bootstrap in the usual GCC sense (a GCC being able to compile itself - currently MELT GCC behaves like t

Dream to be a real hero (KMM7321759V90985L0KM)

Your request has been received. A Gold Crown Club representative will be contacting you by e-mail as soon as possible. Thank you **Attachments will not be opened**

Cross compiling gcc-4.3: wrong library path

Hello, I'm trying to cross compile gcc-4.3 for emdebian.org and i have got some compilers for some arches but i'm struggling with some other arches (like powerpc, mips(el), sparc and s390). Those architectures have separated ABIs for (n)32, 64. The problem i have is that ../lib64 and ../lib32 are

Re: [lto] Streaming out language-specific DECL/TYPEs

On Mon, Jun 2, 2008 at 20:37, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > the problem with making this a langhook is that there is no "there-there" in > that on the serialize in side, you would have to recreate the c++ front end > code that expects this tree code. (if there is no such code, then

Re: [lto] Streaming out language-specific DECL/TYPEs

On Tue, Jun 3, 2008 at 09:28, Jan Hubicka <[EMAIL PROTECTED]> wrote: > Sure if it works, we should be lowering the types during gimplification > so we don't need to store all this in memory... > But C++ FE still use its local data later in stuff like thunks, but we > will need to cgraphize them an

Re: [lto] Streaming out language-specific DECL/TYPEs

> On Mon, Jun 2, 2008 at 20:37, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > > > the problem with making this a langhook is that there is no "there-there" in > > that on the serialize in side, you would have to recreate the c++ front end > > code that expects this tree code. (if there is no such c

Re: [lto] Streaming out language-specific DECL/TYPEs

Diego Novillo wrote: On Tue, Jun 3, 2008 at 09:28, Jan Hubicka <[EMAIL PROTECTED]> wrote: Sure if it works, we should be lowering the types during gimplification so we don't need to store all this in memory... But C++ FE still use its local data later in stuff like thunks, but we will need t

Re: [lto] Streaming out language-specific DECL/TYPEs

Hi, On Tue, 3 Jun 2008, Diego Novillo wrote: > On Tue, Jun 3, 2008 at 04:51, Richard Guenther > <[EMAIL PROTECTED]> wrote: > > > You may want to read > > > > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html > > Thanks. I think I will try to incorporate this in LTO so we won't > even nee

Re: [lto] Streaming out language-specific DECL/TYPEs

On Tue, Jun 3, 2008 at 5:28 PM, Michael Matz <[EMAIL PROTECTED]> wrote: > Hi, > > On Tue, 3 Jun 2008, Diego Novillo wrote: > >> On Tue, Jun 3, 2008 at 04:51, Richard Guenther >> <[EMAIL PROTECTED]> wrote: >> >> > You may want to read >> > >> > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html

Re: [lto] Streaming out language-specific DECL/TYPEs

Michael Matz wrote: Hi, On Tue, 3 Jun 2008, Diego Novillo wrote: On Tue, Jun 3, 2008 at 04:51, Richard Guenther <[EMAIL PROTECTED]> wrote: You may want to read http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html Thanks. I think I will try to incorporate this in LTO so w

[tuples] Memory savings in gimple.h

Hi! I think 2/3 operand GIMPLE_ASSIGN is the most widely used gimple type, and 128 bytes + 16/24 bytes in separate allocation for it is a lot (though, we'd need a separate extra_order_size_table for such GIMPLE_ASSIGNs if we decrease it a little bit). The low hanging fruit on 64-bit arches is mov

How to reserve an Elf e_machine value

I am working on a compiler kit for an in-house processor that uses Elf as object file format. Since this compiler will be released to external customers, I need to reserve an 'official' e_machine value for this processor. Somehow I am unable to find out how to reserve such a value. How should I

Re: [lto] Streaming out language-specific DECL/TYPEs

On Tue, Jun 3, 2008 at 5:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Michael Matz wrote: > > Note that michael's patch exposes some sleeping dragons for lto. Namely, if > the debug information is generated early for these issues, then there will > have to be code in lto which "copies" this

Re: [lto] Streaming out language-specific DECL/TYPEs

On Tue, Jun 3, 2008 at 04:51, Richard Guenther <[EMAIL PROTECTED]> wrote: > You may want to read > > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html Thanks. I think I will try to incorporate this in LTO so we won't even need to deal with these codes in the streamer. Michael, are you OK

Re: How to reserve an Elf e_machine value

Hi, I suggest you post a message at http://groups.google.com/group/generic-abi H.J. On Tue, Jun 3, 2008 at 8:46 AM, Stephen Andieta <[EMAIL PROTECTED]> wrote: > > I am working on a compiler kit for an in-house processor that uses Elf as > object file format. Since this compiler will be release

No warning for unreachable code

I just discovered a behaviour in gcc-4, which I don't understand: code unsigned int x; if (x < 0) do_something(); compiled with -Wall doesn't produce a warning, and the call to do_something() is silently dropped, whereas if x is of type unsigned char, I get as e

[whopr] Design/implementation alternatives for the driver and WPA

We've started working on the driver and WPA components for whopr. These are some of our initial thoughts and implementation strategy. I have linked these to the WHOPR page as well. I'm hoping we can discuss these at the Summit BoF, so I'm posting them now to start the discussion. Robert, Ollie,

Why g++ does not emit any information for a local variable in a template class member function?

Hi, I have the following code. I try to print the variable temp in the constructor of A. But gdb can not do that. The error message is shown blow the C++ code. According to the people from gdb mailing list, it is because that the compiler (g++) does not generate information for such variable in

Re: No warning for unreachable code

I just discovered a behaviour in gcc-4, which I don't understand: code unsigned int x; if (x < 0) do_something(); compiled with -Wall doesn't produce a warning, and the call to do_something() is silently dropped, whereas if x is of type unsigned char, I get as

Re: No warning for unreachable code

Hi Segher, On Wed, 4 Jun 2008, Segher Boessenkool wrote: > > I just discovered a behaviour in gcc-4, which I don't understand: code > > > > unsigned int x; > > > > if (x < 0) > > do_something(); > > > > compiled with -Wall doesn't produce a warning, and the call to > > do_s

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 3, 2008, at 9:45 AM, Diego Novillo wrote: We've started working on the driver and WPA components for whopr. These are some of our initial thoughts and implementation strategy. I have linked these to the WHOPR page as well. I'm hoping we can discuss these at the Summit BoF, so I'm posting

why 6Gb RAM not enough to compile a 14Mb source [MELT]?

Hello All, my MELT branch http://gcc.gnu.org/wiki/MiddleEndLispTranslator has a big source file in it warm-basilys-0.c. It is "self" generated, about 14Mbytes & almost 280KLOC (in rev136334). It ends with a big initialization routine of 100KLOC which mostly fills a 5000 member structure (each