[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-06 16:35:02 UTC ---
On Tue, 6 Dec 2011, rguenth at gcc dot gnu.org wrote:

> > The combination -fwrapv -ftrapv is not particularly meaningful; it ought 
> > to act exactly the same as -ftrapv (i.e. -ftrapv should override any 
> > previous -fwrapv, and vice versa; -fwrapv -fno-trapv should mean -fwrapv 
> > and -ftrapv -fno-wrapv should mean -ftrapv, as at present).
> 
> I suppose the new Negative() .opt file annotation cannot cover this?

Negative() isn't particularly new, and it can't handle those semantics.

> Internally we probably should have a single enum that enumerates all
> valid integer overflow behaviors (what about the weak -f[no-]strict-overflow)?

Yes, I think one enum makes sense.  You need to work out what cases such 
as -ftrapv -fwrapv -fno-wrapv do (whether it means -ftrapv as at present, 
or the default state - I think probably the default state; that is, 
-ftrapv and -fwrapv would set the enum to appropriate values, -fno-trapv 
and -fno-wrapv would set it to default if -ftrapv or -fwrapv respectively 
were in effect, and otherwise do nothing).

I don't know about -fstrict-overflow, but maybe that should be separate 
(controlling whether, in cases where the default semantics are in effect, 
certain optimizations relating to overflow are made).