--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-25 20:49 ---
No response, closing as invalid as of comment #4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-23 12:21 ---
Can you verify the bug still occurs with a still maintained version of GCC?
That
is, GCC 4.2.1 or trunk. Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-02
08:01 ---
If -fno-strict-aliasing fixes the problem, then you have an aliasing problem
in the source. So closing as invalid.
Ugh! If compilers were that simple... -fno-strict-aliasing disables a whole
class of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
00:54 ---
If -fno-strict-aliasing fixes the problem, then you have an aliasing problem in
the source.
So closing as invalid.
--
What|Removed |Added
--
What|Removed |Added
Component|c |target
Keywords||wrong-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29
18:08 ---
Can you try something?
try with -fno-strict-aliasing -O2 -march=pentium4.
Then if that works try changing the following line:
but_event = (XButtonEvent *) event;
to
but_even = event-xbutton.
And if
--- Additional Comments From thrall at vss dot fsi dot com 2004-11-29
19:38 ---
-fno-strict-aliasing does make the segfault go away, but changing the line like
you suggested does not (the assembly for handleButtonEvent is exactly the same
up to the place it zeroes event, and it still
