--- Comment #8 from tdragon at tdragon dot net 2007-06-20 14:52 ---
Not seeing any further action or confirmation on this yet, I've gone ahead and
created a simpler testcase. It's plain that, when using -O2, line 14 of
alias1.c is skipped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #7 from tdragon at tdragon dot net 2007-06-20 14:46 ---
Created an attachment (id=13744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13744&action=view)
Better testcase pt.2; use with alias1.c
Compile this file with any or no additional options as desired; linking wit
--- Comment #6 from tdragon at tdragon dot net 2007-06-20 14:44 ---
Created an attachment (id=13743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13743&action=view)
Better testcase; compile with -O2, use with alias_main.c
Compiling this file with -O2 and linking with the object f
--- Comment #5 from tdragon at tdragon dot net 2007-06-13 22:47 ---
Is it possible that an optimization enabled by -O2 *assumes* that hashitem()
will conform with strict aliasing by not dereferencing that argument, and thus
optimizes those lines away? (Not the case.) If this is what is h
--- Comment #4 from tdragon at tdragon dot net 2007-06-13 22:36 ---
(In reply to comment #2)
> Though we could have an alias violation if you don't cast back in hashitem to
> the correct type of the argument.
hashitem() uses the type as punned to HASHDATA* (where HASHDATA is a struct
wit
--- Comment #3 from tdragon at tdragon dot net 2007-06-13 22:27 ---
(In reply to comment #2)
> Do you mean the last two stores to b:
> b->time = time;
> b->progress = found ? 4 : 2;
Yes, those two lines are the ones that are wrongly skipped.
--
http://gcc.gnu.org/bugzilla/show_bug
