Here is the warning after my patch:
1.cpp: In function 'int foo(int, int, int)':
1.cpp:29:70: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
return hash2(static_cast<const unsigned short*>(change1), len / 2);
^
1.cpp:29:70: warning: during inlining function int hash2(const short unsigned
int*, int) into function int foo(int, int, int) [-Wstrict-aliasing]
It is clear what is going on.
On Tue, Aug 19, 2014 at 04:49:57PM +0800, lin zuojian wrote:
> Hi Richard,
> > Generally I don't think we want to expand the use of the IMHO broken
> > strict_aliasing_warning code.
> If you have read my test code, you must understand it is the
> programmer who responsible for this undefined behavior, instead of
> the compiler. Like PR 60546 concluded.
>
> And I doubt if limiting the compiler behavior is a good choice.
>
> > We should be able to do better after some constant/forward propagation,
> > scanning for MEM_REFs operating on decls and accessing those with
> > an alias set that is not a subset of the set of the decl. Like simply
> > warn as part of the tree-ssa-forwprop.c sweep (maybe only for those
> > MEM_REFs we simplified to avoid duplicates, but then also watch
> > for CCP doing the same).
> That's a more generalize solution. But it have a defection: at that
> point, the compiler have no idea who generates these code. That make
> it difficult to debug.
> ---
> Lin Zuojian
>
