On Fri, May 24, 2013 at 10:33 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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?
I'm not dure what the standard says here - I'd equally well may interpret the standard in that all left-shifts of negative values are well-defined (there must be a reason for the pattern to use -1 << instead of 1 <<). Richard. > -- > Marc Glisse
