From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Michal Soltys <soltys@ziu.info>
Cc: neilb@suse.de, linux-raid@vger.kernel.org, dledford@redhat.com
Subject: Re: [PATCH 1/1] Work around gcc-4.7's strict aliasing checks
Date: Mon, 23 Jan 2012 13:50:45 +0100 [thread overview]
Message-ID: <4F1D57A5.7070104@redhat.com> (raw)
In-Reply-To: <1327193360-4446-1-git-send-email-soltys@ziu.info>
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. We're all going through the
code trying to come up with workarounds for gcc (myself included),
rather than fixing the code.
IMHO adding more ugly typedefs is a situation of where the cure is worse
than the disease.
Cheers,
Jes
next prev parent reply other threads:[~2012-01-23 12:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 11:16 [PATCH 0/1] gcc-4.7 build fix Jes.Sorensen
2012-01-05 11:16 ` [PATCH 1/1] Work around gcc-4.7's strict aliasing checks Jes.Sorensen
2012-01-11 23:43 ` NeilBrown
2012-01-12 7:14 ` David Brown
2012-01-12 13:45 ` Michal Soltys
2012-01-13 12:20 ` David Brown
2012-01-13 14:21 ` Michal Soltys
2012-01-13 17:48 ` David Brown
2012-01-12 9:24 ` Jes Sorensen
2012-01-22 0:49 ` Michal Soltys
2012-01-22 0:49 ` [PATCH] compile cleanly with -Wstrict-aliasing=1 Michal Soltys
2012-01-23 12:50 ` Jes Sorensen [this message]
2012-01-24 0:59 ` [PATCH 1/1] Work around gcc-4.7's strict aliasing checks Michal Soltys
2012-01-24 9:18 ` David Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F1D57A5.7070104@redhat.com \
--to=jes.sorensen@redhat.com \
--cc=dledford@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=soltys@ziu.info \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).