https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84997
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-03-21
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to jos...@codesourcery.com from comment #1)
> On Tue, 20 Mar 2018, antoshkka at gmail dot com wrote:
>
> > For example
> >
> > int test2(int lhs) {
> > lhs += 2.0;
> > return lhs;
> > }
>
> That would need -fno-trapping-math, because if the addition results in a
> double value larger than INT_MAX, under Annex F the conversion back to int
> is defined to raise FE_INVALID along with producing an unspecified value.
If it produces an unspecified value it doesn't raise undefined behavior, right?
So replacing it with lhs += 2; is incorrect as if that overflows that's
undefined behavior. So we could only replace it with lhs = (int)((unsigned)lhs
+ 2) and produce implementation defined behavior from "unspecified" which I
suppose is OK.
