Re: Warning shift of 0 ignored

[Nick Clifton <nickc at redhat dot com>]

Hi Dirk,

> I'm using GNU arm-linux assembler (version 2.14.90.0.6 (arm-linux)
> using BFD version 2.14.90.0.6 20030820) to cross-compile ARM Linux
> Kernel 2.6.0. In one file I get warnings
>
> arch/arm/lib/csumpartialcopygeneric.S:142: Warning: shift of 0 ignored.
>
> with expression
>
>    mov	r5, r4, lsr #byte(0)
>
> I posted a patch to the ARM Linux Patch system, but it was rejected
> because the original code seems to be correct and "a fix should rather
> consist of having the assembler not emit a warning in those cases"
>
> (Please see
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1739/1)
>
> Any ideas to switch off or avoid these warnings?


Hmm - I do not think that the assembler is being too pedantic.  Using
"lsr 0" as a shifter operand is illegal according to the ARM
instruction set specification, since a value of zero is used to encode
a shift by 32 bits.  Hence I think that it is only fair that the
assembler should issue a warning message, (and helpfully translate the
shift operand into "lsl 0" which is valid).

I do not understand Nicolas Pitre's comment that your original patch
(to csumpartialcopygeneric.S) would break big endian support.  Perhaps
the "#byte(0)" string is being generated.or altered by a script
somewhere.  (I am not familiar with the ARM Linux kernel sources).

Anyway, the short answer to your question is no, there is no way
(without recoding the file that is being assembled) to turn off or
suppress the warning.  Of course you could generate a patch to add a
new (ARM specific) command line option to GAS to suppress the warning,
but this does seem to be wrong to me.  I would suggest that you try to
following:

  1. Find out why your original patch would break big-endian support
     and see if you can fix it so that it does not.  For example you
     could find out where these "lsr #byte(0)" operands are coming
     from and change it so that in the little-endian case "lsl
     #byte(0)" is generated instead.

  2. Accept that the warning will be generated and add a sed script to
     the makefile to delete it post-assembly.

  3. If all else fails, generate a GAS patch as suggested above and
     submit it for approval.

Cheers
        Nick