On April 25, 2017 4:39:49 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote: >On 04/24/2017 05:25 AM, Richard Biener wrote: >> >> The following makes signed overflow undefined for all >(non-)optimization >> levels. The intent is to remove -fno-strict-overflow signed overflow >> behavior as that is not a sensible option to the user (it ends up >> with the worst of both -fwrapv and -fno-wrapv). The implementation >> details need to be preserved for the forseeable future to not wreck >> UBSAN with either associating (-fwrapv behavior) or optimizing >> (-fno-wrapv behavior). >> >> The other choice would be to make -fwrapv the default for -O[01]. >> >> A second patch in this series would unify -f[no-]wrapv, -f[no-]trapv >> and -f[no-]strict-overflow with a >> -fsigned-integer-overflow={undefined,wrapping,trapping[,sanitized]} >> option, making conflicts amongst the options explicit (and reduce >> the number of flag_ variables). 'sanitized' would essentially map >> to todays flag_strict_overflow = 0. There's another sole user >> of flag_strict_overflow, POINTER_TYPE_OVERFLOW_UNDEFINED - not sure >> what to do about that, apart from exposing it as different flag >> alltogether. >> >> Further patches in the series would remove -Wstrict-overflow (and >> cleanup VRP for example). >> >> Anyway, most controversical part(?) below. >> >> Any comments on this particular patch (and the overall proposal)? >> >> Cleaning up the options is probably a no-brainer anyways. >> >> Thanks, >> Richard. >> >> 2017-04-24 Richard Biener <rguent...@suse.de> >> >> * common.opt (fstrict-overflow): Enable by default. >> * opts.c (default_options_table): Remove OPT_fstrict_overflow entry. >Presumably when this work is complete -fno-strict-overflow will give >some kind of reasonable error message to the user directing them to the > >new option that most likely does what they were looking for?
No, it will simply map to -fwrapv. Richard. >Jeff