On Fri, 24 May 2013, Richard Biener wrote:
On Thu, May 23, 2013 at 9:47 PM, Marc Glisse <marc.gli...@inria.fr> wrote:
Hello,
this is a simple patch to reduce a bit the noise in PR57324 (undefined
behavior flagged by clang). I only handled some of the most obvious ones.
Passes bootstrap+testsuite on x86_64-linux-gnu.
Hm, so ISO C99 says in 6.5.7/4 that (E1 << E2) "If E1 has signed type
and nonnegative
value, and E1 * 2^E2 is representable in the result type, then that is the
resulting value; otherwise, the behavior is undefined."
I guess if the architecture only has logical shifts and uses another
representation than 2's complement...
While seriously underspecified for signed negative values (always undefined?!
or well-defined?!), I wonder why CLang requires
- *hv &= ~((HOST_WIDE_INT) (-1) << (prec - count -
HOST_BITS_PER_WIDE_INT));
+ *hv &= ~((unsigned HOST_WIDE_INT) (-1)
+ << (prec - count - HOST_BITS_PER_WIDE_INT));
here.
That is, isn't this a bug in CLang?
Note that my set of changes may not exactly match clang's report. Since
that was done on 4.8, I relied on grep quite a bit, and there didn't seem
to be any harm in adding unsigned there. If we consider that the standard
says that any lshift of a negative number is undefined, why do you find
this particular change surprising?
--
Marc Glisse
