On Thu, Jul 23, 2015 at 12:19 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Wed, Jul 22, 2015 at 5:11 PM, Tom de Vries <tom_devr...@mentor.com> wrote: >> [ Re: [RFC, PR66873] Use graphite for parloops ] >> On 22/07/15 13:01, Richard Biener wrote: >>> >>> why only scalar floats? Please use FLOAT_TYPE_P. >>> >>> + if (INTEGRAL_TYPE_P (type)) >>> + return (!TYPE_OVERFLOW_TRAPS (type) >>> + && TYPE_OVERFLOW_WRAPS (type)); >>> >>> it cannot both wrap and trap thus TYPE_OVERFLOW_WRAPS is enough. >> >> >> Hmm, indeed, when specifying both, one is quietly ignored. The documentation >> also doesn't mention this. >> >> Attached untested patch mentions this ftrapv/fwrapv interaction in the docs. >> >> OK for trunk, if bootstrap succeeds? > > Ok.
Btw, for consistency we probably should add -fsigned-overflow=traps|wraps|undefined and make -ftrapv and -fwrapv alias to the respective behavior. Oh, and -fstrict-overflow is another beast with rather unspecified behavior... while it's positive form could be aliased to -fsinged-overflow=undefined it's negative form is _not_ equal to -fwrapv - it's a third state that says overflow is neither known to wrap nor undefined (thus it allows even less optimizations). Note that the behavior of -fno-strict-overflow isn't documented (only it's postiive form is). This means that at -O[10] where -fno-strict-overflow is in effect we are in "undefined" territory. Maybe it's time to fix that ... Richard. > Richard. > >> Thanks, >> - Tom >> >>
