Re: [PATCH 1/1] Work around gcc-4.7's strict aliasing checks

[Michal Soltys <soltys@ziu.info>]

On 12-01-23 13:50, Jes Sorensen wrote:
> On 01/22/12 01:49, Michal Soltys wrote:
>>  Below is approach to the "problem" from a bit different angle -
>>  using alias-permitting type definitions consistently where necessary
>>  - so assuring compiler won't (shouldn't ?) pursue any funny ideas no
>>  matter what. I'd guess it's the "right" thing to do - aside from
>>  going kernel way and using -fno-strict-aliasing everywhere (or
>>  #pragmas).
>>
>>  The compilation goes cleanly at Wstrict-aliasing=1 - so most
>>  aggresive yet most dumb at the same time (note, not checked on 4.7,
>>  but obviously I included necessary equivalent changes to the Jes's
>>  patch).
>>
>>  Anyway - side effects of Wstrict-aliasing=1 are false positives -
>>  quite a few of them actually (funcion argument casts where only
>>  pointers are involved, some pointers which are not dereferenced
>>  "nearby" and/or in the same block) - but false negatives should be
>>  (almost ?) nonexistent.  As mdadm is rather critical, and itself
>>  compiled with Wall, Wextra and Werror - I assume to be extra careful
>>  - this should complement those settings well.
>>
>>  On a bad side of this approach - it doesn't necessary make the code
>>  prettier, and might make people ask "the hell is this ...".
> 
> Hi Michal,
> 
> Personally I'd rather have someone who knows about the ddf on disk
> format go through the code and fix properly.
> IMHO adding more ugly typedefs is a situation of where the cure is
> worse than the disease.

Btw, the patch went through the whole mdadm, not just ddf part. And
afaik, if we aim to be formally correct - there's no going around
typedefs (which are required for "may_alias" on simple types).
Otherwise, it just tricking gcc into not issuing warnings (even if
the chance of actual problems occuring is absolutely minuscule).

> We're all going through the code trying to come up with workarounds
> for gcc (myself included), rather than fixing the code.

Well, IMHO the [probably] best workaround for now would be
-fno-strict-aliasing then - which avoids warnings, ugly attribute
[over]use, and should assure expected behavior.

Say, near the top of Makefile:

-CFLAGS = $(CWFLAGS) $(CXFLAGS) -DSendmail=\""$(MAILCMD)"\" $(CONFFILEFLAGS) $(DIRFLAGS)
+CFLAGS = $(CWFLAGS) $(CXFLAGS) -fno-strict-aliasing -DSendmail=\""$(MAILCMD)"\" $(CONFFILEFLAGS) $(DIRFLAGS)