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 [EMAIL PROTECTED] (650) 331-3385 x713
