linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* strict aliasing warnings in Sparse; -fno-strict-aliasing
@ 2007-09-02  6:03 Josh Triplett
  2007-09-06 18:26 ` Josh Triplett
  0 siblings, 1 reply; 2+ messages in thread
From: Josh Triplett @ 2007-09-02  6:03 UTC (permalink / raw)
  To: linux-sparse

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: strict aliasing warnings in Sparse; -fno-strict-aliasing
  2007-09-02  6:03 strict aliasing warnings in Sparse; -fno-strict-aliasing Josh Triplett
@ 2007-09-06 18:26 ` Josh Triplett
  0 siblings, 0 replies; 2+ messages in thread
From: Josh Triplett @ 2007-09-06 18:26 UTC (permalink / raw)
  To: linux-sparse

On Sat, 2007-09-01 at 23:03 -0700, Josh Triplett wrote:
> In the absence of a better suggestion, I intend to make Sparse use
> -fno-strict-aliasing.

I've changed the Sparse Makefile to use -fno-strict-aliasing.  Patches
welcome if someone wants to remove it and fix the warnings some other
way.

- Josh Triplett

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-09-06 18:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-02  6:03 strict aliasing warnings in Sparse; -fno-strict-aliasing Josh Triplett
2007-09-06 18:26 ` Josh Triplett

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).