This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Put scope blocks on a diet


On Nov 27, 2007, Mark Mitchell <mark@codesourcery.com> wrote:

> Alexandre Oliva wrote:
>>> there is a 50% increase in memory consumption and a 5% increase in
>>> compile-time for tramp3d.

>> For the record, two points:

> Alexandre, please take the rhetoric down a notch.  I know you have
> strong feelings about this, but you're among friends. :-)

I thought you agreed that -g and -g0 ought to emit the same executable
code.  Did you change your mind about this?  Seriously!

As if it wasn't enough to spend 3 months trying to get a major
regression in this property fixed, and doing that out of shared
consideration for the effort to control memory use, I now have to
revert the fix and sacrifice this property for the sake of preserving
a *bug* that *largely exaggerated* the memory reduction of the
original broken patch?

> That certainly makes sense.  Do you have a URL for the July 24 patch?

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html

> Meanwhile, please revert your patch.

Can you justify the double standards being applied here?

One major bug remains unfixed for months and the patch that introduced
it doesn't get reverted.

A patch that fixes it needs immediate reversion?

This is insulting.  Please at least make an effort to understand where
the problem actually lies, and to give any indication that you did,
before coming to a decision on this.  The decision ATM is prejudicial
and absurd.

I'd happily revert both patches.  But reverting to the broken state we
were in before the fix just gets people confused as to understanding
the effects of the patch.

> We don't want to oscillate too much.

Then how about we avoid yet another oscillation and figure out what to
do before reverting to the broken state we had before?

> Is there a PR for the problem that your patch fixed?  If not,
> please sure that there is one.

I'll open one right away.

>> I don't think letting -g or -g0 affect the executable code output by
>> the compiler is acceptable.

> I don't either.  But, we don't have agreement on how best to solve the
> problem.

It could be as easy as reverting the patch that caused it, no?  If
that "works" for the bug fix, it ought to work even more immediately
for the patch that introduced the bug, no?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]