Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) wrote:
Most people
fall in this camp
and this is what gcc has implemented. This camp doesn't want to change the code
so that they can get better debugging information.
This is definitely not the case. At least among our users, very few fall
into this camp. But in
I think both sides are talking over each other, partially because two
different goals are in mind.
IMHO, there are two extremes when it comes to the so called debugging
optimized code.
One camp wants the full debuggability (let's call them debuggability
crowd) - which means
they want to know the v
Ian Lance Taylor wrote:
Alexandre Oliva <[EMAIL PROTECTED]> writes:
So... The compiler is outputting code that tells other tools where to
look for certain variables at run time, but it's putting incorrect
information there. How can you possibly argue that this is not a code
correctness issue?
Andrew Pinski wrote:
I have to ask, do you want an optimizing compiler or one which
generates full debugging information
Both!
I would like modes which do the following
a) reasonable amount of optimization that does not intefere too much
with debugging. The old GCC 3 -O1 was a close app
On Nov 8, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva wrote:
>> On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>>
>>> Until we all know what we're trying to do
>>
>> Here's what I am trying to do:
> I think these are laudable goals, but you didn't really provide
Alexandre Oliva wrote:
On Nov 8, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
My general feelings on this subject:
1. I don't think we should care much about the ability to
*SET* values of variables in optimized code.
Indeed. We should care about correctness of debug information, and
th
On Thu, Nov 08, 2007 at 02:36:57PM -0200, Alexandre Oliva wrote:
> > 3. The quality of code at -O0 is really terrible
>
> That's a feature, no?
Actually it's a misfeature, in that it's worse than it needs to
be, and it's worse in ways that increase the time required to produce it
(since a larger
> This doesnt happen because while inserting the caller save insn, its
> live_throughout is simply set to the live_throughout of the call insn
> + the registers marked with REG_DEAD notes in the call insn.
Ouch. Relying on REG_DEAD notes to get complete liveness info is a no-no:
/* The value in
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> So... The compiler is outputting code that tells other tools where to
> look for certain variables at run time, but it's putting incorrect
> information there. How can you possibly argue that this is not a code
> correctness issue?
I don't see any p
I created two new branches to allow companies that create ix86 processors such
as AMD and Intel to backport the changes for these new chipsets into GCC 4.1
and 4.2 branches. It is expected that any changes in this branch will be put
into the mainline first and then backported. When 4.3 branches,
On Nov 8, 2007, "Andrew Pinski" <[EMAIL PROTECTED]> wrote:
> On 11/7/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> I'm personally getting numerous requests for debug information
>> correctness and better completeness from debug info consumers such as
>> gdb, frysk and systemtap. GCC's eage
On Nov 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> However, I don't think your arguments that this is
> an issue comparable to code correctness are valid.
It *is* code correctness. Say, if the linker emitted incorrect
addresses in an executable, but the kernel and dynamic loader didn
Ian Lance Taylor wrote:
> It seems very likely that it would be possible to write a plugin which
> would generate IR to be fed into a proprietary backend.
>
> More deeply, I think his concern is misplaced.
For the record, I agree on both points.
There are some ways in which plugins might make
First off I would like to say I did not want to reply but I guess I am
going to because of some false information spreading around about what
GCC as a compiler is.
On 11/7/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I'm personally getting numerous requests for debug information
> correctnes
David Daney wrote:
>> (a) if the variable has not been optimized away, gives the location
>> where that variable's current value can be found, or
>> (b) if the variable has been optimized away, and the value is not a
>> constant, says that the value is not available, or
>
> Perhaps if the variabl
Mark Mitchell wrote:
Alexandre Oliva wrote:
On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Until we all know what we're trying to do
Here's what I am trying to do:
I think these are laudable goals, but you didn't really provide the
information I wanted. In particular, what I'd l
Alexandre Oliva wrote:
> On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>> Until we all know what we're trying to do
>
> Here's what I am trying to do:
I think these are laudable goals, but you didn't really provide the
information I wanted. In particular, what I'd like to drill do
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Nov 7, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> >> Does it really matter? Do we compromise standards compliance (and so
> >> violently, while at that) in any aspect of the compiler?
>
> > What standards are you talking about?
>
> D
On Nov 8, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> If you want to be really sure no arguments disappear (necessary for
> instance for meaningful use of systemtap) you also need to inhibit
> some transformations,
I'm not aware of any situations in which we must force an argument not
to dis
On Nov 8, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:
> My general feelings on this subject:
> 1. I don't think we should care much about the ability to
> *SET* values of variables in optimized code.
Indeed. We should care about correctness of debug information, and
then this ability will co
On Nov 8, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Wed, 7 Nov 2007, Alexandre Oliva wrote:
>> > x and y at the appropriate part. Whatever holds 'x' at a point (SSA
>> > name, pseudo or mem) will also mention that it holds 'c'. At a later
>> > point whichever holds 'y' will al
Hi,
On Thu, 8 Nov 2007, Robert Dewar wrote:
> significantly degraded -O1 debugging. I have found for
> instance that debugging the GNAT compiler itself, -O1
> used to be perfectly fine, but now far too many arguments
> and variables disappear.
Yes. That problem is addressed by Alexandre's appro
On Thu, Nov 08, 2007 at 08:59:18AM -0500, Robert Dewar wrote:
> 2. It is much more important to have reasonable debugging
> for most users than the last mile of optimization. For me
> we should ensure that -O1 is still reasonably debuggable.
> The switch to GCC 4, at least in the Ada context, has
>
My general feelings on this subject:
1. I don't think we should care much about the ability to
*SET* values of variables in optimized code. You can
definitely do without that. So if a variable exists in
two places, no problem, just register one of them.
2. It is much more important to have reaso
Hi,
> > (call_insn:HI 91 270 92 5 cor_h.c:129 (parallel [
> >(set (reg:SI 1 $c1)
> >(call (mem:SI (symbol_ref:SI
> > ("DotProductWithoutShift") [flags 0x41] > DotProductWithoutShift>) [0 S4 A32])
> >(const_int 0 [0x0])))
> >(use (const_i
Florian Weimer wrote:
* Robert Dewar:
Tom Tromey wrote:
First, aren't we already in this situation? There are at least 2
compilers out there that re-use parts of GCC by serializing trees and
then reading them into a different back end.
It's not obvious to me that this is consistent with the
* Robert Dewar:
> Tom Tromey wrote:
>
>> First, aren't we already in this situation? There are at least 2
>> compilers out there that re-use parts of GCC by serializing trees and
>> then reading them into a different back end.
>
> It's not obvious to me that this is consistent with the GPL ..
It
On 07 November 2007 17:52, David Edelsohn wrote:
>
> The concern is the many forms of shim layers that possibly could
> be written more easily with a plug-in framework.
I wonder if we could adapt some kind of privsep model, so that once the
compiler has finished init, it gives away its r
Hi,
On Wed, 7 Nov 2007, Alexandre Oliva wrote:
> > x and y at the appropriate part. Whatever holds 'x' at a point (SSA
> > name, pseudo or mem) will also mention that it holds 'c'. At a later
> > point whichever holds 'y' will also mention in holds 'c' .
>
> I.e., there will be two parallel
Ian Lance Taylor wrote:
>
> More deeply, I think his concern is misplaced. I think that gcc has
> already demonstrated that the only widely used compilers are free
> software. Proprietary compilers don't keep up over time, outside of
> niche markets. Hooking proprietary code into gcc, one way o
On 11/8/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor wrote:
>
> > At one time, gcc actually provided better debugging of optimized code
> > than any other compiler, though I don't know if that is still true.
> > Optimized gcc code is still debuggable today. I do it all the time.
31 matches
Mail list logo
