Re: GAS for ARM: Reject ASR/LSR/ROR with immediate of 0

[Richard Earnshaw <rearnsha at arm dot com>]

> Hi Scott,
> 
> : >   It was just pointed out to me that GAS for the ARM accepts an
> : >   immediate value of 0 for the ASR, LSR and ROR versions of addressing
> : >   mode 1, whereas ARM's own assembler does not.  Since the ARM ARM
> : >   also implies that a value of zero is incorrect I have developed the
> : >   patch below.  Will this break anything in your worlds if I apply it ?
> : > 
> : 
> : The documentation I have (ARM Architechure reference) seems to deal explicitly
> : with the case of 0 as the shift_imm value.  It specifies what the shifter
> : operand should be and the carry out bit.  Or have I missed what you are trying
> : to fix?
> 
> That is for the LSL shift only.  The other three shifts take immediate
> values in the range 1..32 (inclusive) and my patch is fixing GAS so
> that if these shift are given a value of 0 it will barf.
> 
> Cheers
> 	Nick

I forget if there was a reason now, or if it was just laziness when I did 
the original code :-)

It might have been the case that gcc used to occasionally omit <shift> #0 
because the optimizer had not re-canonicalized an expression properly (I 
vaguely recall problems of this nature at one time).  I think such bogons 
are now fixed.

Immediately below your proposed fix is a piece of code that fixes this up, 
so that shifts of zero are converted into lsl shifts.  So the assembler 
should never generate code that doesn't do as the coder expected (in 
particular, you don't get an unexpected shift of 32).  If your patch goes 
in, then that should be removed.

I guess it's a matter of taste as to which should be done.  Maybe it would 
be better to just emit some sort of warning and continue as before.  Is 
there some particular reason why this has come up?

On a final matter of style, I think we should add some defines for the the 
shift bit patterns.  Comparing shft->value with 0 is not particularly 
intuitive.
 Comparing it with SHFT_ASL would be much clearer.

R.