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 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
Ross Ridge writes:
> This section doesn't make sense to me. The force_align_arg_pointer
> attribute and -mstackrealign assume that the ABI is being
> followed, while the -fpreferred-stack-boundary option effectively
"H.J. Lu" writes
> According to Apple engineer who implemented the -mstackrealig
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
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.
Hi,
thanks for writting the proposal. It seems that at least in general
terms we are all in sync.
> At this point we are interested in getting feedback on the general idea.
> There is some refactoring that will be needed inside the call-graph
> manager and some aspects of the design may not even n
Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit aligned
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> >// Reserve two stack slots and save return address
> >// and previous frame pointer into them. By
> >// pointing new ebp to them, we build a pseudo
> >// stack for unwinding
>
> Hmmm... I don't know much about the DWARF unwind in
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
On Tue, Dec 18, 2007 at 03:39:42AM -0500, Ross Ridge wrote:
> >> changes the ABI. According your defintions, I would think
> >> that INCOMING should be ABI_STACK_BOUNDARY in the first case,
> >> and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second.
> >
> > That isn't true since some
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
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.
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
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?
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.
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
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
> 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
On Tue, Dec 18, 2007 at 08:47:35AM -0500, Daniel Jacobowitz wrote:
> On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> > >// Reserve two stack slots and save return address
> > >// and previous frame pointer into them. By
> > >// pointing new ebp to them, we build a pseudo
> > >//
On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote:
I was just browsing the gcc-list to see if there are any updates on
the Objective-C 2.0 extensions. Can you please send and email to the
gcc-list with the current state?
I hope to be able to contribute them in the next year, but exactly
whe
Hi Mike,
Tuesday 18 December 2007 20:04:45 tarihinde Mike Stump şunları yazmıştı:
> On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote:
> > I was just browsing the gcc-list to see if there are any updates on
> > the Objective-C 2.0 extensions. Can you please send and email to the
> > gcc-list with t
On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote:
Any schedule for fixing Obj-C++ regressions on mainline?
Same answer. My hope would be that people that introduce regressions
would fix them...
Tuesday 18 December 2007 20:47:29 tarihinde Mike Stump şunları yazmıştı:
> On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote:
> > Any schedule for fixing Obj-C++ regressions on mainline?
>
> Same answer. My hope would be that people that introduce regressions
> would fix them...
We were talking a
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
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
>
> 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
Ye, Joey writes:
>i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
>and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
>Strictly speaking by the above definition it would be 8 for i386.
>The hardware doesn't force the stack to be 32-bit aligne
Ross Ridge wrote:
> The -fpreferrred-stack-boundary flag currently generates code that
> assumes the stack aligned to the preferred alignment on function entry.
> If you assume a worse incoming alignment you'll be aligning the stack
> unnecessarily and generating code that this flag doesn't require
Hello,
This is a complaint about how the bug database is being managed. It
is getting harder and harder to find bug reports to work on, because
too many old bug reports are being kept open even though there is no
sign of intent to ever resolve the report.
For example, PR18346 is a bug report in
> So I'm asking for a policy here that says when it is OK to resolve old
> bug without progress as WONTFIX or SUSPENDED. Start shooting.
I think this would be a big mistake to reuse an existing state for this.
If/when someone does start caring about that particular feature it'll be
impossible fo
Does anyone understand why we get the following when configure is run
in the libgomp directory on darwin?
configure:17711: checking for shared libgcc
configure:17731:
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./
On Wednesday 19 December 2007, Joe Buck wrote:
> On Wed, Dec 19, 2007 at 01:11:11AM +, Paul Brook wrote:
> > > So I'm asking for a policy here that says when it is OK to resolve old
> > > bug without progress as WONTFIX or SUSPENDED. Start shooting.
> >
> > I think this would be a big mistake t
On Wed, Dec 19, 2007 at 01:11:11AM +, Paul Brook wrote:
> > So I'm asking for a policy here that says when it is OK to resolve old
> > bug without progress as WONTFIX or SUSPENDED. Start shooting.
>
> I think this would be a big mistake to reuse an existing state for this.
But this is pretty
Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack t
On Wed, Dec 19, 2007 at 01:25:19AM +, Paul Brook wrote:
> On Wednesday 19 December 2007, Joe Buck wrote:
> > On Wed, Dec 19, 2007 at 01:11:11AM +, Paul Brook wrote:
> > > > So I'm asking for a policy here that says when it is OK to resolve old
> > > > bug without progress as WONTFIX or SUSP
Robert Dewar writes:
>Well if we have local variables of type float (and we have specified
>use of SSE), we are in trouble, no?
Non-vector SSE instructions, like the ones that operate on scalar floats,
don't require memory operands to be aligned.
Ross Ridge
Ross Ridge wrote:
> I'm currently using -fpreferred-stack-boundary without any trouble.
> Your proposal would in fact generate code to align stack when it's not
> necessary. This would change the behaviour of
-fpreferred-stack-boundary,
> hurting performance and that's unacceptable to me.
This p
On Tue, Dec 18, 2007 at 06:31:26PM -0500, Ross Ridge wrote:
> Ross Ridge wrote:
> > The -fpreferrred-stack-boundary flag currently generates code that
> > assumes the stack aligned to the preferred alignment on function entry.
> > If you assume a worse incoming alignment you'll be aligning the stac
On Wed, 19 Dec 2007, Steven Bosscher wrote:
> The bigger issue here, is that people seem to be using Bugzilla as a
> kind-of TODO list for things may some day work on, but probably will
I don't see any problem with that. It records known issues. We can then
use the existing fields, or create n
On Tue, Dec 18, 2007 at 06:31:25PM -0500, Ross Ridge wrote:
> Ye, Joey writes:
> >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
> >and 64 for x86_64. It is the minimum stack boundary. It is fixed.
>
> Ross Ridge wrote:
> >Strictly speaking by the above definition it would
On Wed, Dec 19, 2007 at 01:25:19AM +, Paul Brook wrote:
> > Ok. I did check the GCC bugzilla help pages, and they don't mention
> > SUSPENDED
> > at all :-)
I wrote:
> Patches welcome, as they say.
Never mind; see
http://gcc.gnu.org/bugs/management.html
for when to use SUSPENDED.
Ross Ridge wrote:
> I'm currently using -fpreferred-stack-boundary without any trouble.
> Your proposal would in fact generate code to align stack when it's
> not necessary. This would change the behaviour of
> -fpreferred-stack-boundary, hurting performance and that's unacceptable
> to me.
Ye, J
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.
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.
> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 18, 2007 6:00 PM
> To: GCC
> Cc: [EMAIL PROTECTED]
> Subject: Regression count, and how to keep bugs around forever
>
> Maybe it is just me, but I find it very annoying to have to wade
> th
Joe Buck wrote:
> On Wed, Dec 19, 2007 at 01:25:19AM +, Paul Brook wrote:
>
>>> Ok. I did check the GCC bugzilla help pages, and they don't mention
>>> SUSPENDED
>>> at all :-)
>>>
>
> I wrote:
>
>> Patches welcome, as they say.
>>
>
> Never mind; see
> http://gcc.gnu.org/bu
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 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
> > I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some
> > simplest c54x.h and c54x.c and a empty md, and I
>
> I think the answer is right there
> ^^
IIRC what you need as a bare minimum as a w
49 matches
Mail list logo
