--- Additional Comments From evandro at yahoo dot com 2005-09-20 16:45
---
Ahem, never mind. My eyes are blury after looking at so much asm code...
Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From evandro at yahoo dot com 2005-09-20 16:43
---
-fno-strict-aliasing still doesn't result in the correct code. I agree with
your assesment, but what am I missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
16:08 ---
>From the dup bug:
Also PR 14024 is the bug for C++ front-end not reporting possible aliasing
violations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From evandro at yahoo dot com 2005-09-20 16:06
---
It would be nice if -Wall, -Wstrict-aliasing or -Wstrict-aliasing=2 caught it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
20:25 ---
Yes this is a case where you are violating C/C++ aliasing rules.
*** This bug has been marked as a duplicate of 21920 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
20:17 ---
First try -fno-strict-aliasing, since:
return *(short*)&tmp;
is violating them.
Second I think this is a known issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
