On Jan 1, 2008 12:39 AM, Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
>
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> > [...] I chose to ignore this problem and say we debug the optimized
> > program, not the source as far as life ranges are concerned. [...]
>
> Yes, and this choice has a ce
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> [...] I chose to ignore this problem and say we debug the optimized
> program, not the source as far as life ranges are concerned. [...]
Yes, and this choice has a certain pragmatism. However, it seems to
miss the basic observation that what dri
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Right, which will significantly increase debugging size as you add two
> more notes around many lines.
FWIW, I've just got powerpc64-linux-gnu to pass bootstrap-debug and
bootstrap4-debug/-g0 (i.e., all host and target libraries pass
On 18 Dec 2007 08:13:55 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> > A plan to fix local variable debug information in GCC
> >
> > by Alexandre Oliva <[EMAIL PROTECTED]>
> >
> > 2007-12-18 draft
>
On Dec 17, 2007 9:28 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> > On 12/17/07 12:51, Alexandre Oliva wrote:
> >> I guess I'm to blame, for having naïvely put the code out without as
> >> much as a design and goals document
>
> > Y
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> [...] Because a compiler that generates incorrect instructions is
> completely useless for all users.
Surely you overstate this: gcc has always included a generous serving
of incorrect-code-generation bugs.
> A compiler that generates incorrect de
On Sun, Dec 23, 2007 at 02:33:44AM +0100, Andi Kleen wrote:
> > I don't know why you say that. ld knows a bit about debugging
> > sections, and how to read .debug_line for errors; objdump knows how to
> > decode debug info, as does readelf; strip knows how to remove it;
> > objcopy how to copy and
> I don't know why you say that. ld knows a bit about debugging
> sections, and how to read .debug_line for errors; objdump knows how to
> decode debug info, as does readelf; strip knows how to remove it;
> objcopy how to copy and separate it.
Sorry I mean separate debuginfo, as Ian was refering
On Sat, Dec 22, 2007 at 11:49:23PM +0100, Andi Kleen wrote:
> > As I'm sure you know, the GNU
> > binutils
>
> Actually binutils only barely supports debuginfo. AFAIK
> objcopy is the tool tool that knows anything about them.
I don't know why you say that. ld knows a bit about debugging
section
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I'm in favor of implementing this.
Yes it would be great.
> As I'm sure you know, the GNU
> binutils
Actually binutils only barely supports debuginfo. AFAIK
objcopy is the tool tool that knows anything about them.
> and gdb already support usin
Chris Lattner <[EMAIL PROTECTED]> writes:
> If debug info size and link time is really such a serious problem for
> so many users, perhaps people developing the gnu toolchain should
> investigate an extension like this.
I'm in favor of implementing this. As I'm sure you know, the GNU
binutils an
Andrew Haley wrote:
We know you don't understand, but that isn't likely to change. Would
it not surely be better to cease this pointless argument and get on
with the job of improving debuginfo? This absolutist position you
seem to have adopted isn't helping.
If we could talk about "better" an
Alexandre Oliva writes:
> On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
>
> > Alexandre, I have to say that in my opinion absurd arguments like this
> > do not strengthen your position.
>
> I'm sorry that you feel that way, but I don't understand why you and
> so many ot
On Dec 21, 2007, at 4:09 PM, Andrew Pinski wrote:
On 12/21/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 21 Dec 2007 16:02:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]>
wrote:
Like it or not, the large size of debug information is a serious
issue
for many people.
Link times are hurt b
Alexandre Oliva wrote:
I'm sorry that you feel that way, but I don't understand why you and
so many others apply different compliance standards to debug
information. Why do you regard compiler output that causes systems to
fail because they process incorrect debug information as any more
accept
On 12/21/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On 21 Dec 2007 16:02:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > Like it or not, the large size of debug information is a serious issue
> > for many people.
>
> Link times are hurt by large size of debugging information. I have
On 21 Dec 2007 16:02:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Like it or not, the large size of debug information is a serious issue
> for many people.
Link times are hurt by large size of debugging information. I have
many many complaints from some users of the PS3 toolchain that
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > Alexandre, I have to say that in my opinion absurd arguments like this
> > do not strengthen your position.
>
> I'm sorry that you feel that way, but I don't understand why you and
> so many others apply different compliance standards to debug
> inf
On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>>
>> >> Why would code, essential for debug information consumers that are
>> >> part of larger systems to work correctly, de
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> >> Why would code, essential for debug information consumers that are
> >> part of larger systems to work correctly, deserve any less attention
> >> to correctness?
>
> > Because for mo
On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Why would code, essential for debug information consumers that are
>> part of larger systems to work correctly, deserve any less attention
>> to correctness?
> Because for most people the use of debug information is to use it in a
>
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > Right, which will significantly increase debugging size as you add two
> > more notes around many lines.
>
> If that's the price to avoid debug information consumers getting
> incorre
Alexandre Oliva wrote:
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Right, which will significantly increase debugging size as you add two
more notes around many lines.
If that's the price to avoid debug information consumers getting
incorrect values...
It may be an unaccept
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Right, which will significantly increase debugging size as you add two
> more notes around many lines.
If that's the price to avoid debug information consumers getting
incorrect values...
Would you argue for a position such as:
we
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > It is technically feasible but problematic for other reasons.
> > i = i * m + ((i / j) + k) / n;
> > On a two register machine like the x86 i will change several times
> > during t
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> It is technically feasible but problematic for other reasons.
> i = i * m + ((i / j) + k) / n;
> On a two register machine like the x86 i will change several times
> during that calculation.
No. The register used to hold its init
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> > How do i know i need to change this DEBUG expression.
>>
>> As reassoc looks for sets of variables it can freely mess with, it
>> should take note of variables that are used in debug an
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > And it will avoid the problem of turning the testsuite into a
> > regression testsuite rather than an accuracy testsuite.
>
> Sorry, I don't understand what you mean here.
It's not a major point.
When one adds a testsuite to working code, it is na
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > For some things, sure, but we are just talking about the values in
> > user visible variables stored in registers. There is no way we can
> > make that information be correct between
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > How do i know i need to change this DEBUG expression.
>
> As reassoc looks for sets of variables it can freely mess with, it
> should take note of variables that are used in debug annotations in
> addition to the kind of single (?) non-debug uses it
On Dec 20, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I'm addressing this in a bit more detail in a revised version of the
> spec, that I intend to publish in the GCC wiki RSN.
http://gcc.gnu.org/wiki/Var_Tracking_Assignments
Here's a diff between the version I posted a couple of days ag
On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> You snipped (skipped?) one aspect of the reasoning on why it is
>> appropriate. Of course this doesn't prove it's the best possibility,
>> but I haven't seen evidence of why it isn't.
>
On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> For some things, sure, but we are just talking about the values in
> user visible variables stored in registers. There is no way we can
> make that information be correct between line notes.
Err... I think there is, and one way to d
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>> Now, if z_5 were present in a debug expression, then it would need
>> adjusting. No different from the adjusting need for any other
>> instruction in which z_5 was present, though.
> uh, but if you don't adjust in the fixed examples,
Janis Johnson <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-19 at 10:00 -0800, Ian Lance Taylor wrote:
> > One way to make a principled choice is to consider the line notes we
> > are going to emit with the debugging information. Presumably we do
> > not have the goal of emitting correct debug in
On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> > Here is the easy one:
>
> > z_5 = a_3 + b_3
> > x_4 = z_5 + c_3
>
> > DEBUG(x, x_4)
>
>
> > Reassoc may transform this into:
>
>
> > z_5 = c_3 + b_3
> > x_4 = z_5 + a_3
>
> >
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>
> > It gets worse, however
> >
> > c_3 = a_1 + b_2
> > z_5 = c_3 + d_9
> > x_4 = z_5 + e_10
> > DEBUG(x, x_4)
> > y_7 = x_4 + f_11
> > z_8 = y_7 + g_12
> > ->
> >
> > c_3 = a_1 + b_2
> > z_5 = c_3 + g_12
> > x_4 = z_5 + e_10
> > DEBUG(x, x_4
On Wed, Dec 19, 2007 at 05:02:52PM -0200, Alexandre Oliva wrote:
> That said... I can't find any more the equivalent of
> DW_CFA_val_expression in DW_OP_*s that could be used in location
> expressions. I just *knew* it was there, but I guess I just imagined
> it. This is embarrassing.
I am pret
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>>
>> > Consider PRE alone,
>>
>> > If your debug statement strategy is "move debug statements when we
>> > insert
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> Here is the easy one:
> z_5 = a_3 + b_3
> x_4 = z_5 + c_3
> DEBUG(x, x_4)
> Reassoc may transform this into:
> z_5 = c_3 + b_3
> x_4 = z_5 + a_3
> DEBUG(x, x_4)
> Now x has the wrong value.
As Andrew said, no, it doesn't.
Now,
It gets worse, however
c_3 = a_1 + b_2
z_5 = c_3 + d_9
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + g_12
->
c_3 = a_1 + b_2
z_5 = c_3 + g_12
x_4 = z_5 + e_10
DEBUG(x, x_4)
y_7 = x_4 + f_11
z_8 = y_7 + d_9
x_4 now no longer represents the value of x, but we haven't directly
ch
On Wed, 2007-12-19 at 10:00 -0800, Ian Lance Taylor wrote:
> One way to make a principled choice is to consider the line notes we
> are going to emit with the debugging information. Presumably we do
> not have the goal of emitting correct debug information in between
> line notes--e.g., when using
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
> >
> > Here is the easy one:
> >
> > z_5 = a_3 + b_3
> > x_4 = z_5 + c_3
> >
> > DEBUG(x, x_4)
> >
> >
> > Reassoc may transform this into:
> >
> >
> > z_5 = c_3 + b_3
> > x_4 = z_5 + a_3
> >
> > DEBUG(x, x_4)
> >
> > No
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> Dwarf enables arbitrary value expressions too.
> Well, uh, no.
> The only way to directly specify the value of a variable is for
> constants. DW_AT_const_value does not allow
On Wed, Dec 19, 2007 at 10:00:38AM -0800, Ian Lance Taylor wrote:
> int f(int x, int y) {
> int i = 0, j = 0;
>
> probe1();
> i = x;
> j = y;
> probe2();
> Of course there are no actual instructions between the calls to
> probe1() and probe2(). If I use gdb's "finish" command out of
>
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> You snipped (skipped?) one aspect of the reasoning on why it is
> appropriate. Of course this doesn't prove it's the best possibility,
> but I haven't seen evidence of why it isn't.
You will find it easier to demonstrate the worth of your proposal if
Daniel Berlin wrote:
Here is the easy one:
z_5 = a_3 + b_3
x_4 = z_5 + c_3
DEBUG(x, x_4)
Reassoc may transform this into:
z_5 = c_3 + b_3
x_4 = z_5 + a_3
DEBUG(x, x_4)
Now x has the wrong value.
??
x_4 looks like it has the value 'a_3 + b_3 + c_3' in both examples to
me, although c
On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> >> int c = z;
> >> whatever0(c);
> >> c = x;
>
> > Because you have added information you have no way of knowing.
> > How exactly did you compute that the call *definitely sets
On 12/19/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> >
> > > Consider PRE alone,
> >
> > > If your debug statement strategy is "move debug statements when we
> > > insert cod
On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> > Consider PRE alone,
>
> > If your debug statement strategy is "move debug statements when we
> > insert code that is equivalent"
>
> Move? Debug statements don't move, in gen
On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> Consider PRE alone,
> If your debug statement strategy is "move debug statements when we
> insert code that is equivalent"
Move? Debug statements don't move, in general. I'm not sure what you
have in mind, but I sense some disconnec
On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>> int c = z;
>> whatever0(c);
>> c = x;
> Because you have added information you have no way of knowing.
> How exactly did you compute that the call *definitely sets c to the
> value of z_0*, and definitely sets the value of c to x_2.
On Dec 18, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> A plan to fix local variable debug information in GCC
>>
>> by Alexandre Oliva <[EMAIL PROTECTED]>
>>
>> 2007-12-18 draft
> Thank you for writing this. It makes an enormous difference.
>
> It is desirable to be able to represent constants and other
> optimized-away values, rather than stating variables have values they
> can no longer have:
>
> int
> x1 (int x)
> {
> int i;
>
> i = 2;
> f(i);
> i = x;
> h();
> i = 7;
> g(i);
> }
>
> Even if variable i is completely
On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Then, we let tree optimizers do their jobs. Whenever they rename,
> renumber, coalesce, combine or otherwise optimize a variable, they
> will automatically update debug statements that mention them as well.
>
Speaking only about the tree l
On Dec 18, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> On Dec 18, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
>>> OK, so you are agreeing that good debuggability is impossible
>>> with all the optimizations in place, so once again, let's have
>>> an optimziation le
> Short of putting a barrier at every sequence point, how would you stop
> the debugger from jumping all over the place? I'm assuming that you
> do want the debugger to show what is actually going on, not fake it.
You could, for example, add a -Og option that says "don't do any
optimizations that
Robert Dewar writes:
> Andrew Haley wrote:
> =
> > > I don't think it is fine, we have constant complaints from our
> > > users about this. I think we definitely need an optimization
> > > level that avoids this.
> >
> > Short of putting a barrier at every sequence point, how would you s
Daniel Jacobowitz wrote:
On Tue, Dec 18, 2007 at 11:22:12AM -0500, Robert Dewar wrote:
I don't think it is fine, we have constant complaints from our
users about this. I think we definitely need an optimization
level that avoids this.
It's fine because it's not the problem he's working on.
Andrew Haley wrote:
=
> I don't think it is fine, we have constant complaints from our
> users about this. I think we definitely need an optimization
> level that avoids this.
Short of putting a barrier at every sequence point, how would you stop
the debugger from jumping all over the place?
On Tue, Dec 18, 2007 at 11:22:12AM -0500, Robert Dewar wrote:
>>> == Goals
>>
>> I note that you don't say anything about the other big problem with
>> debugging optimized code, which is that the debugger jumps around all
>> over the place. That is fine, of course.
>
> I don't think it is fine, we
Robert Dewar writes:
> Ian Lance Taylor wrote:
> > Alexandre Oliva <[EMAIL PROTECTED]> writes:
> >
> >> A plan to fix local variable debug information in GCC
> >>
> >> by Alexandre Oliva <[EMAIL PROTECTED]>
> >>
> >> 2007-12-18 draft
> >
> > Thank you fo
Ian Lance Taylor wrote:
Alexandre Oliva <[EMAIL PROTECTED]> writes:
A plan to fix local variable debug information in GCC
by Alexandre Oliva <[EMAIL PROTECTED]>
2007-12-18 draft
Thank you for writing this. It makes an enormous difference.
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> A plan to fix local variable debug information in GCC
>
> by Alexandre Oliva <[EMAIL PROTECTED]>
>
> 2007-12-18 draft
Thank you for writing this. It makes an enormous difference.
> == Goals
I note tha
On Dec 18, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/18/07 03:07, Alexandre Oliva wrote:
>> Rats, this below-the-waistline attack really got me annoyed.
> I'm sorry you feel that way, it was not meant as a personal attack,
> though it was rather brusque. I was getting tired of askin
Alexandre Oliva wrote:
On Dec 18, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
OK, so you are agreeing that good debuggability is impossible
with all the optimizations in place, so once again, let's have
an optimziation level that optimizes as far as possible without
harming debuggability.
On 12/18/07 03:07, Alexandre Oliva wrote:
Rats, this below-the-waistline attack really got me annoyed.
I'm sorry you feel that way, it was not meant as a personal attack,
though it was rather brusque. I was getting tired of asking for the
same thing over and over again.
So, what do you s
On Dec 18, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> On 12/17/07 19:50, Alexandre Oliva wrote:
>>> Now, since you're so interested in it and you've already read the
>>> various perspectives on the issue that I listed in my yeste
On Dec 18, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> Yes, I've considered something along these lines, but decided against
>> it, for we can't afford for debug information to affect executable
>> code generation in any way whatsoever, and we don't want to pessimize
On Tue, Dec 18, 2007 at 02:38:31AM -0200, Alexandre Oliva wrote:
> Would reformatting these and stamping a title on top make it worthy of
> your interest?
Actually, I think that *would* help (though, of course, it's impossible
to predict if it would help *enough*).
I've noticed before (though th
On Dec 18, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> Yep. Sometimes code just is optimized away. Can't stop that without
>> harming optimizations.
> OK, so you are agreeing that good debuggability is impossible
> with all the optimizations in place, so once again
Alexandre Oliva wrote:
Yep. Sometimes code just is optimized away. Can't stop that without
harming optimizations.
OK, so you are agreeing that good debuggability is impossible
with all the optimizations in place, so once again, let's have
an optimziation level that optimizes as far as possib
Alexandre Oliva wrote:
Yes, I've considered something along these lines, but decided against
it, for we can't afford for debug information to affect executable
code generation in any way whatsoever, and we don't want to pessimize
optimized code when compiling without -g just so that compiling wi
On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/17/07 19:50, Alexandre Oliva wrote:
>> Now, since you're so interested in it and you've already read the
>> various perspectives on the issue that I listed in my yesterday's
>> e-mail to you, would you help me improve this document,
On Dec 17, 2007, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote:
>> Line number information has a well-defined meaning: it ought to
>> represent the source code line that best represents the source-code
>> construct that ended up implemented u
On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote:
> Line number information has a well-defined meaning: it ought to
> represent the source code line that best represents the source-code
> construct that ended up implemented using that instruction.
You implicitly assume that souch a
On Dec 17, 2007, Geert Bosch <[EMAIL PROTECTED]> wrote:
> We could conceptually have inspection points between each source
> statement and declaration, which would roughly correspond to a
> use of all memory and all source variables, wether in memory or
> in registers.
> These inspections points w
On 12/17/07 19:50, Alexandre Oliva wrote:
Now, since you're so interested in it and you've already read the
various perspectives on the issue that I listed in my yesterday's
e-mail to you, would you help me improve this document, by letting me
know what you believe to be missing from the selecte
On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/17/07 15:28, Alexandre Oliva wrote:
>>> You need to provide such a document now.
>>
>> Can't I instead provide it when it's ready?
> Of course.
Thanks,
Now, since you're so interested in it and you've already read the
various pe
On 12/17/07 15:28, Alexandre Oliva wrote:
You need to provide such a document now.
Can't I instead provide it when it's ready?
Of course.
Diego.
On Dec 17, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 12/17/07 12:51, Alexandre Oliva wrote:
>> I guess I'm to blame, for having naïvely put the code out without as
>> much as a design and goals document
> Yes, you are.
Wow, thanks. At least we agree on something! ;-)
> You need to p
On Dec 16, 2007, Joe Buck <[EMAIL PROTECTED]> wrote:
> However, since preserving accurate debug information
> has a cost, I think it would be better to turn -O1, not -O2, into the
> mode that Alexandre wants, where debug information is preserved.
In terms of memory, that's true, it does have a co
On 12/17/07 12:51, Alexandre Oliva wrote:
I guess I'm to blame, for having naïvely put the code out without as
much as a design and goals document
Yes, you are.
You need to provide such a document now. I can't see how you'll be able
to incorporate your implementation without a convincing d
On Dec 16, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>> It is obvious that you misunderstood what I want, and how intrusive
>> the approach is.
> Yes Alexandre, everyone who disagrees with you must not understand!
My conclusion is not based on disagreement, but rather on the faulty
argume
On Dec 16, 2007, at 20:27, Joe Buck wrote:
I have some sympathy for going in Alexandre's direction, in that it
would be nice to have a mode that provided optimization as well as
accurate debugging. However, since preserving accurate debug
information
has a cost, I think it would be better to
On Sun, Dec 16, 2007 at 08:12:07PM -0500, Daniel Berlin wrote:
> > It is obvious that you misunderstood what I want, and how intrusive
> > the approach is.
> >
>
> Yes Alexandre, everyone who disagrees with you must not understand!
> That's really the problem here.
> None of us understand but you.
> It is obvious that you misunderstood what I want, and how intrusive
> the approach is.
>
Yes Alexandre, everyone who disagrees with you must not understand!
That's really the problem here.
None of us understand but you.
Alexandre Oliva wrote:
>> Yes, please. I would very much like to see an abstract design
>> document on what you are trying to accomplish.
>
> Other than the ones I've already posted, here's one:
>
> http://dwarfstd.org/Dwarf3Std.php
>
> Seriously. There is a standard for this stuff.
That's
On Dec 16, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> There is no portion of the DWARF3 spec which requires you output
> information that is correct or useful. The same way the C standard
> does not require you to write correct programs, only valid ones, the
> DWARF3 spec does not require
On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> > On 11/25/07 3:43 PM, Mark Mitchell wrote:
>
> >> My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
> >> GCC developer with an interest in improving the compi
On Dec 5, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 11/25/07 3:43 PM, Mark Mitchell wrote:
>> My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
>> GCC developer with an interest in improving the compiler in the same way
>> that you're trying to do) is that you stop
Alexandre Oliva wrote:
On Nov 24, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
Alexandre Oliva wrote:
Besides, the Ada RTS compiles differently with -g than without -g,
such that compare-debug doesn't pass if you compare sysdep.o. Nobody
but me seems to care.
We certainly care about thi
On Nov 24, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> Besides, the Ada RTS compiles differently with -g than without -g,
>> such that compare-debug doesn't pass if you compare sysdep.o. Nobody
>> but me seems to care.
> We certainly care about this, and appreciate
On Wed, Dec 05, 2007 at 09:05:33AM -0500, Diego Novillo wrote:
> In my simplistic view of this problem, I've always had the idea that -O0
> -g means "full debugging bliss", -O1 -g means "tolerable debugging"
> (symbols shouldn't disappear, for instance, though they do now) and -O2
> -g means "yo
On 11/25/07 3:43 PM, Mark Mitchell wrote:
My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
GCC developer with an interest in improving the compiler in the same way
that you're trying to do) is that you stop writing code and start
writing a paper about what you're trying to d
On Nov 27, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Mon, 26 Nov 2007, Alexandre Oliva wrote:
>> >> And then, you have to tweak everything else to keep the note that
>> >> replaced the set up to date as you further optimize the code.
>>
>> > No. remove_insn() would replace the SE
Hi,
On Mon, 26 Nov 2007, Alexandre Oliva wrote:
> >> And then, you have to tweak everything else to keep the note that
> >> replaced the set up to date as you further optimize the code.
>
> > No. remove_insn() would replace the SET with a note.
>
> What information would this note convey?
Oh
On Nov 26, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Fri, 23 Nov 2007, Alexandre Oliva wrote:
>> On Nov 13, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
>>
>> > The nice thing is, that there are only few places which really get rid of
>> > SETs: remove_insn. You have to tweak t
On Nov 26, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Fri, 23 Nov 2007, Alexandre Oliva wrote:
>> Yep. Nowhere does that bug report request parameters to be forced live.
> Not in that bug report perhaps, but we got requests for exactly this, i.e.
> to be able to introspect all
On Nov 26, 2007, J.C. Pizarro <[EMAIL PROTECTED]> that i wrote:
> ..., last access data for elimination from bigger cache, etc. }
I'm sorry, it's date, not data:
..., last access date for elimination from bigger cache, etc. }
Sincerely, J.C.Pizarro
1 - 100 of 197 matches
Mail list logo
