Re: Use unsigned(-1) for lshift

[Marc Glisse <marc dot glisse at inria dot fr>]

On Fri, 24 May 2013, Richard Biener wrote:

> On Thu, May 23, 2013 at 9:47 PM, Marc Glisse <marc.glisse@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