On Tue, 11 Sep 2012, Jonathan Wakely wrote:
G++ correctly warns about a strict aliasing violation in this code,
because an object of type char is accessed as type uintptr_t:
char buf[64];
inline int get(int offset)
{
return *reinterpret_cast<int*>(&buf[offset]);
}
$ g++-4.7 f.cc -c -fstrict-aliasing -Wstrict-aliasing
f.cc: In function 'int get(int)':
f.cc:4:48: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
But the following doesn't elicit a warning:
char buf[64];
inline int get(int offset)
{
char* addr = &buf[offset];
return *reinterpret_cast<int*>(addr);
}
I believe this code is still undefined, for exactly the same reason,
but I assume the diagnostic machinery isn't smart enough to detect the
violation of the rules. Can the optimisers still cause this code to
do unexpected things, even though the diagnostic is absent?
I thought char was the type that can alias anything (so the optimizer
stays clear).
--
Marc Glisse
