This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -Wstrict-aliasing in 2.95/6?
>>>>> "Jamie" == Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:
Jamie> Patrick J. LoPresti wrote:
patl> If there were an option to change that rule to allow ANY
patl> integral type pointer to alias all memory, would that fix the
patl> problem? (It does for the examples mentioned so far...)
Jamie> That's a bit severe, and would defeat the point of type-based
Jamie> aliasing in some cases.
You are right. But I still think the "char *" exception is quite
telling when you consider the obvious rationale, and I think the same
rationale suggests a clear extension for modern machines. Sometimes
programmers use "int *" to mean "pointer to an integer"; other times
use it to mean "pointer to 4 bytes of memory" (or 8 bytes, whatever).
How is this for a revised proposal: Add an adjective for types which
allows them to have the aliasing behavior of char *. (This would be a
GCC-only extension, of course.) Then a simple typedef could give you
an aliasing word pointer, longword pointer, or whatever.
Jamie> It would probably solve the kernel problems, though I'm not
Jamie> sure it would. I'd still want the warning in that case.
Figuring out a good way to give these warnings is interesting and
important; please do not think I am arguing with you. I am, however,
thinking about a slightly different issue: Am I ever going to see my
Linux kernel compiled with full optimization?
It would be nice to provide something that Linux developers (and
others!) can use for high-performance stuff. I suspect being able to
access arbitrary memory through wider integral pointers would do it,
but I admit I do not know enough to be sure.
Jamie> I've long ago written (non-kernel) code that accesses an
Jamie> integral type as a struct to take it apart efficiently... same
Jamie> problem arises.
Yup, and it would be solved if the "may_alias" type adjective could be
applied to struct pointers.
Jamie> Clearly unions of some kind are the right thing to use -- you
Jamie> can tell the compiler exactly what may alias and what can't.
Jamie> It's just (a) quite clunky,
Almost by definition, if it is "quite clunky" it is not the right
thing.
Jamie> (b) there is no solution for high-performance `memcpy' and
Jamie> more complicated things,
Does the "may_alias" adjective provide such a solution?
Jamie> and (c) there is a fix to (b) but it is GCC-specific, silently
Jamie> fails on a standard compiler, and not properly documented.
Well, at least "may_alias" would fail on other compilers.
- Pat