[fedora-arm] Broken sha512sum in coreutils

[omalleys at msu.edu]

Quoting Andy Green <andy at warmcat.com>:

> On 01/10/11 12:23, Somebody in the thread at some point said:
>
>>>> Even on x86 it may not always generate code that does what you want:
>>>> gcc is perfectly entitled to assume that an unaligned pointer is
>>>> never used. And even now, x86 has a big performance hit for word
>>>> accesses that straddle a cache line boundary.
>>>
>>> I don't know about gcc being able to discard unaligned pointers, and
>>> have never observed it to my knowledge. That's just a "C lawyer"
>>> possibility or actually can happen?
>>
>> Both. It doesn't happen, but according to the language specification
>> it could. However, we've seen quite enough of "this is only a
>> language lawyer's theoretical possibility" bugs turning into real
>> bugs.
>
> Well, with --pedantic -Wall -Werror gcc doesn't care to warn about the
> unaligned pointer test x.c I posted the other day (not even with a
> static byte buffer) and produces code using the pointer correctly.  So I
> think you're right with gcc at least silently dropping a misaligned
> pointer "doesn't happen" and I still don't know what the basis is that
> it could happen.
>
> I agree though having been bitten by it myself with mIsdn a guy just
> casting things unaligned is at least writing nonportable code and should
> be able to be written better.  There're benefits even on x86 and ARM
> with hardware fixup so it's hard to argue against.

I think you will find this interesting.

on fc14 i586 gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
[so at bk14 ~]$ gcc --pedantic -o x x.c
x.c: In function ?main?:
x.c:9:2: warning: pointer targets in passing argument 1 of ?strcpy?  
differ in signedness
/usr/include/string.h:128:14: note: expected ?char * __restrict__? but  
argument is of type ?unsigned char *?


Also if you add -Wcast-align gcc version 4.3.2 (Debian 4.3.2-1.1) on  
the guruplug, you actually get
x.c:7: warning: cast increases required alignment of target type