gcc miscompiles csum_tcpudp_magic() on ARMv5
Måns Rullgård
mans at mansr.com
Thu Dec 12 08:48:27 EST 2013
Maxime Bizon <mbizon at freebox.fr> writes:
> On Thu, 2013-12-12 at 12:40 +0000, Russell King - ARM Linux wrote:
>
>> Depends which swab16 you mean by "dumb swab16". If it is a gcc bug then
>
> that one:
>
> #define __swab16(x) ((uint16_t)( \
> (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) | \
> (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
>
> usually expands to this:
>
> 24: e1a00800 lsl r0, r0, #16
> 28: e1a03c20 lsr r3, r0, #24
> 2c: e1833420 orr r3, r3, r0, lsr #8
> 30: e1a03803 lsl r3, r3, #16
> 34: e1a00823 lsr r0, r3, #16
>
> but in my case, the two last shifts are missing.
>
>> you need to submit a bug report to gcc people.
>
> but is it for sure ?
>
> I couldn't find any working gcc version so it does not look like a
> regression, hence my doubt.
>
> basically if you use inline asm with a variable that is smaller than
> register width (32 bits here), can you assume the value in the register
> will be zero extended ? I could not find the answer in the gcc manual.
In the code above, the outer (uint16_t) cast should clear the top half,
as should passing the value to a function (inline doesn't alter the
semantics) as a 16-bit type, so there's something fishy here.
Which gcc versions did you try?
--
Måns Rullgård
mans at mansr.com
More information about the linux-arm-kernel
mailing list