Richard Guenther wrote: >> > 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? > > Disabling pruning will also increase memory-usage and compile-time.
You indicated earlier that you didn't think 30088 was a regression on the branch. That's an excellent point. I had it on my list of regressions from 4.1.[01], but perhaps I was misinformed when I put it on the list. Given that, I don't think we need to worry about it for 4.1.2; it's just one of several wrong-code regressions... > I don't think we need to go this way - there is a workaround available > (use -fno-strict-aliasing) and there are not enough problems to warrant > this. For the record, I don't think the workaround argument is as strong, though. When the user compiles a large application and it doesn't work, there's no hint that -fno-strict-aliasing is the work-around. It's not like an ICE that makes you think "Hmm, maybe I should turn off that pass, or compile this file with -O0". Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
