linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Triplett <josh@freedesktop.org>
To: linux-sparse@vger.kernel.org
Subject: strict aliasing warnings in Sparse; -fno-strict-aliasing
Date: Sat, 01 Sep 2007 23:03:24 -0700	[thread overview]
Message-ID: <46DA522C.4010209@freedesktop.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

Since commit 06bcf19cb8eb3cc3154ba6131477d742a9f0b4b6 switching sparse to -O2,
building Sparse generates various warnings like this:

parse.c:676: warning: dereferencing type-punned pointer will break strict-aliasing rules

These occur because the ptrlist code breaks the C99 strict aliasing rules,
which require that conforming code not access the same memory through pointers
of two different types.

I want to eliminate these warnings in Sparse, both because I want Sparse to
build without warnings and because at least in theory these warnings mean that
GCC may generate incorrect code.

However, the more I stare at the ptrlist code, the more I think it can't
possibly work with strict aliasing on.  It intentionally uses pointers to
different types to refer to the same memory, and I don't see any way to
transform it into code that follows the C99 strict aliasing rules

I found an approach that manages to fool GCC into not warning, but it still
violates the strict aliasing standards, as well as the standards for decency.

#define union_cast(type, value) (((union { __typeof__((void)0,value) v1; type v2; }) { .v1 = (value) }).v2)

Using that to convert pointers to struct ptr_list * or struct ptr_list **
proves sufficiently complex that GCC's strict aliasing warnings don't fire,
but it still ends up with two pointers of different types to the same memory,
so GCC could still generate incorrect code by assuming aliasing.

The strict-aliasing-compliant way to alias memory also involves a union, but
the union must represent the actual memory, not the pointers.

Now, as far as I can tell, nothing in the ptrlist code ever dereferences the
dummy field "list" of the structs declared via DECLARE_PTR_LIST, except the
type-safety macros in ptrlist.h, which don't actually use the values they
obtain.  I *think* that means aliasing issues can't actually cause a problem
here, because only one of the pointers to the same memory location get
dereferenced.  I'd welcome confirmation of this.

That still leaves the problem of how to handle the warnings.  GCC's
__attribute__((may_alias)) might work, but I don't see how to apply it here;
I've tried various possibilities, and they don't work.  -fno-strict-aliasing
would also work.  Either of these approach may lead to suboptimal code
generation.

In the absence of a better suggestion, I intend to make Sparse use
-fno-strict-aliasing.

- Josh Triplett


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

             reply	other threads:[~2007-09-02  6:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-02  6:03 Josh Triplett [this message]
2007-09-06 18:26 ` strict aliasing warnings in Sparse; -fno-strict-aliasing Josh Triplett

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=46DA522C.4010209@freedesktop.org \
    --to=josh@freedesktop.org \
    --cc=linux-sparse@vger.kernel.org \
    /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).