On Wed, 2006-02-08 at 12:28 -0500, Andrew Pinski wrote:
> >
> > I've build in a unified (symlink) tree, with sourceware stuff checked
> > out via cvs from date/time D2006.02.07.17.00.00
>
> I am reducing this failure and will file a bug report.
>
This failure is actually a latent bug elsewhere in marking statements
annotations with volatile ops
PRE doesn't touch statements that contain volatile operations because
operand_equal_p claims two volatile operands are different, even if they
look the same (which is the underlying cause of your infinite loop. We
keep thinking we've generated new values because the hash lookup never
finds the old ones because operand_equal_p returns false)
All the other statements related to your volatile expressions have
stmt_ann (stmt)->has_volatile_ops set to 1.
However, ...
(gdb) p debug_tree (stmt)
<modify_expr 0x401a5288
...
arg 0 <ssa_name 0x40238d34 type <integer_type 0x401ae284 int>
visited var <var_decl 0x401aa318 D.1538> def_stmt <modify_expr
0x401a5288>
version 8>
arg 1 <component_ref 0x401ac190 type <integer_type 0x401ae284 int>
side-effects volatile
...
/home/dberlin/prejoernne.c:19>
yet
(gdb) p ann->has_volatile_ops
$18 = 0
:(
> Thanks,
> Andrew Pinski
>
