Re: RFC: Adding non-PIC executable support to MIPS

2008-07-27 Thread Richard Sandiford
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > All comments welcome - Richard, especially from you. How would you > like to proceed? I think the first step should be to get your other > binutils/gcc patches merged, including MIPS16 PIC; I used those as a > base. But see a few of the notes for p

Re: [tuples] New memory/time comparison vs trunk

2008-07-27 Thread Jan Hubicka
> > - The rest of the memory utilization difference is mostly in inlining > (240Kb) and SSA update (50Kb). > > I think the main focus points should be DSE and trying to get a good > way of measuring the memory utilization differences. Jan, any > suggestion? I've switched memory tester to tuples

Re: Recent warning regression: no return statement in function returning non-void

2008-07-27 Thread Richard Guenther
On Sun, Jul 27, 2008 at 1:18 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > I believe the following happened in the last 48 or so hours; I saw > this triggered by my nightly Wine builds which in turn use my nightly > GCC builds. ;-) > > For code like the following where we have an infinite loop in

Recent warning regression: no return statement in function returning non-void

2008-07-27 Thread Gerald Pfeifer
I believe the following happened in the last 48 or so hours; I saw this triggered by my nightly Wine builds which in turn use my nightly GCC builds. ;-) For code like the following where we have an infinite loop in a non-void function, we now (incorrectly) issue a warning with all of -O0, -O1 and

Build failure with Cygwin

2008-07-27 Thread Paul Richard Thomas
Dear All, Perhaps this is old news/my fault but I am seeing the following on Cygwin_NT/amd64: /irun/bin/gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -W missing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-for mat-attribute -pedantic -Wno-long-long -W

Re: Recent warning regression: no return statement in function returning non-void

2008-07-27 Thread Jan Hubicka
> On Sun, Jul 27, 2008 at 1:18 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > > I believe the following happened in the last 48 or so hours; I saw > > this triggered by my nightly Wine builds which in turn use my nightly > > GCC builds. ;-) > > > > For code like the following where we have an infi

GCC trunk frozen for the tuples merge

2008-07-27 Thread Richard Guenther
The trunk is frozen now until after the merge of the tuples branch which will happen tomorrow, Monday Jul 28th. Unfreezing of the trunk will be annonced after the fact. Thanks, Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernbe

Re: lto gimple types and debug info

2008-07-27 Thread Mark Mitchell
David Edelsohn wrote: I do not expect LTO (or WHOPR) to work on AIX -- at least not without a lot of work on wrappers around the AIX linker. However, I do not understand why enhancing GCC to support LTO -- when GCC is run without enabling LTO -- requires locking GCC completely into DWAR

Re: lto gimple types and debug info

2008-07-27 Thread Richard Guenther
On Sun, Jul 27, 2008 at 7:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > David Edelsohn wrote: > >>I do not expect LTO (or WHOPR) to work on AIX -- at least not >> without a lot of work on wrappers around the AIX linker. However, I do >> not understand why enhancing GCC to support LTO -

Re: lto gimple types and debug info

2008-07-27 Thread Andrew Pinski
On Sun, Jul 27, 2008 at 11:09 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > We generate variables with names like x$y for struct { int y; } x; - in theory > the debugger could "magically" associate a print x.y with x$y. But of course > there is no way to express this in the DWARF. Actually t

Re: lto gimple types and debug info

2008-07-27 Thread Daniel Berlin
On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > David Edelsohn wrote: > >>I do not expect LTO (or WHOPR) to work on AIX -- at least not >> without a lot of work on wrappers around the AIX linker. However, I do >> not understand why enhancing GCC to support LTO -

Re: lto gimple types and debug info

2008-07-27 Thread Mark Mitchell
Andrew Pinski wrote: Actually there is a way to express this in Dwarf2, using DW_OP_piece. See the thread at http://gcc.gnu.org/ml/gcc/2005-01/msg00080.html for more information. And if that's not sufficient, we can of course add extensions to DWARF that do represent it -- and that would be b

Re: lto gimple types and debug info

2008-07-27 Thread Mark Mitchell
Daniel Berlin wrote: I agree that, at least in principle, it should be possible to emit the debug info (whether the format is DWARF, Stabs, etc.) once. No, you can't. You would at least have to emit the variables separate from the types (IE emit debug info twice). Yes, of course; that's what

Re: lto gimple types and debug info

2008-07-27 Thread Kenneth Zadeck
Daniel Berlin wrote: On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: David Edelsohn wrote: I do not expect LTO (or WHOPR) to work on AIX -- at least not without a lot of work on wrappers around the AIX linker. However, I do not understand why enhancing

Re: RFC: Adding non-PIC executable support to MIPS

2008-07-27 Thread Mark Mitchell
Richard Sandiford wrote: Daniel Jacobowitz <[EMAIL PROTECTED]> writes: All comments welcome - Richard, especially from you. How would you like to proceed? I think the first step should be to get your other binutils/gcc patches merged, including MIPS16 PIC; I used those as a base. But see a fe

Re: lto gimple types and debug info

2008-07-27 Thread Daniel Berlin
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: > >>> I agree that, at least in principle, it should be possible to emit the >>> debug >>> info (whether the format is DWARF, Stabs, etc.) once. >> >> No, you can't. >> You would at least have to emit t

Re: lto gimple types and debug info

2008-07-27 Thread Kenneth Zadeck
Daniel Berlin wrote: On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: I agree that, at least in principle, it should be possible to emit the debug info (whether the format is DWARF, Stabs, etc.) once. No, you can't. You would at l

Re: lto gimple types and debug info

2008-07-27 Thread Mark Mitchell
Daniel Berlin wrote: Then again, I also don't see what the big deal about adding a debug info parser is. OK, yes, we may need to read debug info back in. I don't see it as a big deal, either -- and I also don't see it as locking us into DWARF2. We can presumably read in any formats we are

Re: lto gimple types and debug info

2008-07-27 Thread Daniel Berlin
On Sun, Jul 27, 2008 at 7:41 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Daniel Berlin wrote: >> I agree that, at least in principle, it should be possible to emit the debug info (whether the format is DW

Re: lto gimple types and debug info

2008-07-27 Thread Daniel Berlin
On Sun, Jul 27, 2008 at 7:48 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: >> you may of course be right and this is what we will end up doing, but the > implications for whopr are not good. The parser is going to have to work > in lockstep with the type merger Why? You d

Re: lto gimple types and debug info

2008-07-27 Thread Daniel Berlin
On Sun, Jul 27, 2008 at 7:50 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: > >> Then again, I also don't see what the big deal about adding a debug >> info parser is. > > OK, yes, we may need to read debug info back in. > > I don't see it as a big deal, either -- and I also do