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).
