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:
signature.asc
Description: OpenPGP digital signature
