On 12.01.2012 08:14, David Brown wrote:
> On 12/01/12 00:43, NeilBrown wrote:
>> On Thu, 5 Jan 2012 12:16:41 +0100 Jes.Sorensen@xxxxxxxxxx wrote:
>>
>>> From: Jes Sorensen<Jes.Sorensen@xxxxxxxxxx>
>>>
>>> - info->array.ctime = DECADE + __be32_to_cpu(*(__u32*)
>>> - (ddf->anchor.guid+16));
>>> + cptr = (__u32 *)(ddf->anchor.guid + 16);
>>> + info->array.ctime = DECADE + __be32_to_cpu(*cptr);
But going through intermediate (yet incompatible) pointer still breaks
the aliasing rules - unless the above is related to how 4.7+ in
particular do things.
Somewhat similar code - on 4.5.2 and 4.4.1 though, of which the former
will warn about possible break only with the most aggressive (broad)
-Wstrict-aliasing=1 (and the latter at all levels):
int main(void)
{
struct s {
uint16_t d[128];
} tab;
uint32_t *p32;
tab.d[8] = 0x5678;
tab.d[9] = 0x1234;
p32 = (uint32_t *)&tab.d[8];
printf("%X\n", *p32);
return 0;
}
Will output 0 on my machines when compiled with -O2 or higher (or -O1
-fstrict-aliasing) - unless -fno-strict-aliasing is added.
The code clearly breaks the rules, so no wonder optimizations relying on
them messed up. I'm not sure if/how much changed since then, so perhaps
it would behave fine on 4.7+.
>
> The basic rule is that the compiler can assume that objects whose type
> has different sizes, cannot appear at the same address. Unions are one
> way to avoid this.
>
Following this lengthy (but quite interesting) thread it's not (was not
?) allowed either:
http://thread.gmane.org/gmane.comp.gcc.devel/111111
It's 2 years old thread, still the rules and interpretation seem pretty
well entrenched.
OTOH: __attribute__((__may_alias__)) should(?) always give consistent
(expected) results with type definitions that are used as aliases. Maybe it
would be better to go by this route.
In context of mdadm - I wonder if simply -fno-strict-aliasing wouldn't
be the overall best thing to do.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
