Re: Possible issue with ARC gcc 4.8

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

On Mon, 6 Jul 2015, Vineet Gupta wrote:

> > It is the C language standard that says that shifts like this invoke
> > undefined behavior.
>
> Right, but the compiler is a program nevertheless and it knows what to do when it
> sees 1 << 62
> It's not like there is an uninitialized variable or something which will provide
> unexpected behaviour.
> More importantly, the question is can ports define a specific behaviour for such
> cases and whether that would be sufficient to guarantee the semantics.
>
> The point being ARC ISA provides a neat feature where core only considers lower 5
> bits of bitpos operands. Thus we can make such behaviour not only deterministic in
> the context of ARC, but also optimal, eliding the need for doing specific
> masking/clamping to 5 bits.

IMO, writing a << (b & 31) instead of a << b has only advantages. It 
documents the behavior you are expecting. It makes the code 
standard-conformant and portable. And the back-ends can provide patterns 
for exactly this so they generate a single insn (the same as for a << b).

When I see x << 1024, 0 is the only value that makes sense to me, and I'd 
much rather get undefined behavior (detected by sanitizers) than silently 
get 'x' back.

--
Marc Glisse