This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i686 bootstrap failure in revision 110699: looping in execute_pre
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Joern RENNECKE <joern dot rennecke at st dot com>, gcc at gcc dot gnu dot org, Diego Novillo <dnovillo at redhat dot com>
- Date: Wed, 08 Feb 2006 14:43:16 -0500
- Subject: Re: i686 bootstrap failure in revision 110699: looping in execute_pre
- References: <200602081728.k18HSdLG026862@earth.phy.uc.edu>
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
>