This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The utility of standard's semantics for overflow


On Jun 29, 2005, "Dave Korn" <dave.korn@artimi.com> wrote:

>   In fact, doesn't this suggest that in _most_ circumstances, *saturation*
> would be the best behaviour?

If that's for user-introduced overflows, it could be useful in some
cases, but I wouldn't go as far as `most'.

For compiler-introduced overflows (e.g., re-association), wrap
semantics enable some optimizations that you just couldn't perform
otherwise.  Consider the already-mentioned example:

  (a + b) + c

if you re-group this as:

  a + (b + c)

and `b + c' overflows, and then the addition with a underflows, that's
not a problem, since modulo semantics will give you the correct
result.

Turning:

  a * b + a * c

into

  a * (b + c)

might be a problem should b + c overflow, but if you use modulo
semantics, you'll always get the correct result for cases in which
none of the original operations overflowed.


What you must be careful to avoid, however, is deriving further
assumptions from `(b + c) does not overflow'.  Since it's a
compiler-introduced operation in both cases, that's only valid if you
can assume modulo semantics, assuming it doesn't overflow will lead
you to wrong conclusions.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]