http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-29
12:22:10 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > We do not try to preserve traps instead we only try to not produce new ones.
>
> That would make a lot of sense, and assuming it is the official policy I am
> happy to learn that, but then why don't we optimize this testcase:
>
> int f(double a,double b){
> if(a>=b) if(a<=b) return 1;
> return 0;
> }
>
> to
> if(a==b) return 1;
> ?
Good question. I suppose that's a missed optimization then.
> The test in combine_comparisons seems to deliberately check for any change of
> the trapping condition, not just false->true.
>
> I am happy to relabel this bug (or file a new one if you prefer) as a missed
> optimization.
I'd say open a new one.
