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
>
> - 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
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
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
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
> 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
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
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
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 -
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
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 -
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo