This is the mail archive of the gcc@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: GCC 4.1.2 Status Report


Daniel Berlin wrote:

>> Daniel, 30088 is another aliasing problem.  IIIRC, you've in the past
>> said that these were (a) hard to fix, and (b) uncommon.  Is this the
>> same problem?  If so, do you still feel that (b) is true?  I'm
>> suspicious, and I am afraid that we need to look for a conservative hack.
> 
> It's certainly true that people will discover more and more aliasing
> bugs the harder they work 4.1 :)

Do you think that PR 30088 is another instance of the same problem, and
that therefore turning off the pruning will fix it?

> There is always the possibility of turning off the pruning, which will
> drop our performance, but will hide most of the latent bugs we later
> fixed through rewrites well enough that they can't be triggered (the
> 4.1 optimizers aren't aggressive enough).

Is it convenient for you (or Richard?) to measure that on SPEC?
(Richard, thank you very much for stepping up to help with the various
issues that I've raised for 4.1.2!)  Or, have we already done so, and
I've just forgotten?  I'm very mindful of the import or performance, but
if we think that these aliasing bugs are going to affect reasonably
large amounts of code (which I'm starting to think), then shipping the
compiler as is seems like a bad idea.

(Yes, there's a slippery slope argument whereby we turn off all
optimization, since all optimization passes may have bugs.  But, if I
understand correctly, the aliasing algorithm in 4.1 has relatively
fundamental problems, which is rather different.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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