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
