gcc miscompiles csum_tcpudp_magic() on ARMv5

Måns Rullgård mans at mansr.com
Thu Dec 12 10:00:54 EST 2013


Russell King - ARM Linux <linux at arm.linux.org.uk> writes:

> On Thu, Dec 12, 2013 at 02:36:30PM +0100, Maxime Bizon wrote:
>> 
>> 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 ?
>
> Well, in the above code, we're being quite explicit about wanting only
> bits 7-0 to be moved to bits 15-8, whereas what the compiler is actually
> doing is moving bits 15-0 to 23-8.
>
> In other words, the compiler has completely lost sight of that & 0x00ff
> in there.
>
>> I couldn't find any working gcc version so it does not look like a
>> regression, hence my doubt.
>
> Well, looking at the builds I have here, it seems that my gcc also
> produces wrong code here in __udp4_lib_rcv(), which makes me wonder
> how NFS works.  Ah, that's how - in the standard kernel, it's not
> "len" which usually gets swabbed, it's the protocol ID - which for
> UDP is 17.  __swab16(17) produces 0x1100 even with the bug.
>
> Even so, the code _is_ buggy, because if the protocol value had bits
> 15-8 set, then this would go wrong for all the same reasons that
> you've found.  GCC is definitely ignoring the outter (uint16_t) cast
> in the above.
>
> So yes, afaics it's a GCC bug which appears to affect many GCC versions.
>
> The question is... what to do about this.  I don't think we want to wait
> for a gcc version to be fixed...

First we need to figure out exactly pattern triggers the bug.  Once that
is known, we can work around it.

-- 
Måns Rullgård
mans at mansr.com



More information about the linux-arm-kernel mailing list