Thank you for your answer. I give some more information below:
Daniel Berlin wrote:
On 11/6/06, Ricardo FERNANDEZ PASCUAL <[EMAIL PROTECTED]> wrote:
Hello,
I have discovered that volatile expresions can cause the tree-ssa
pre pass to loop forever in "compute_antic". The problem seems to be
that the expresion is assigned a different value number at each
iteration, hence the fixed point required to exit the loop is never
reached.
This should not be possible, it would imply that you have SSA names
marked as volatile, or a statement whose operands are marked volatile
but ann->has_volatile_ops is false.
Actually, I have a MODIFY_EXPR with a volatile operand whose
ann->has_volatile is not being set.
Any statement which contains volatile operands should have
ann->has_volatile_ops set.
That is your real bug.
Ok, the tree that is giving me problems is the following one:
<modify_expr 0xa78b918c
type <integer_type 0xa78c3284 int sizes-gimplified public SI
size <integer_cst 0xa78b3408 constant invariant 32>
unit size <integer_cst 0xa78b3198 constant invariant 4>
align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xa78b33c0
-2147483648> max <integer_cst 0xa78b33d8 2147483647>
pointer_to_this <pointer_type 0xa78c3bdc>>
side-effects visited
arg 0 <ssa_name 0xa78bf210 type <integer_type 0xa78c3284 int>
visited var <var_decl 0xa78be1b8 temp0> def_stmt <modify_expr 0xa78b918c>
version 3>
arg 1 <component_ref 0xa78c20f0 type <integer_type 0xa78c3284 int>
side-effects volatile
arg 0 <var_decl 0xa78be0b0 ____Module__static_data type <record_type
0xa78f58a0>
static SI file volatile.exe line 1 size <integer_cst 0xa78b3408 32> unit
size <integer_cst 0xa78b3198 4>
align 32 chain <type_decl 0xa78c99c0 ____Module__record>>
arg 1 <field_decl 0xa78f58fc w type <integer_type 0xa78c3284 int>
SI file volatile.exe line 1 size <integer_cst 0xa78b3408 32> unit size
<integer_cst 0xa78b3198 4>
align 32 offset_align 128
offset <integer_cst 0xa78b31b0 constant invariant 0>
bit offset <integer_cst 0xa78b3768 constant invariant 0> context <record_type
0xa78f58a0>>>
volatile.exe:1>
Notice that the arg 1 of the MODIFY_EXPR is a COMPONENT_REF which is
marked as volatile. Notice also that the arg 1 of the COMPONENT_REF is
not marked as such, because that field is not volatile itself and there
are other accesses to it which are not volatile. This is because in my
source language individual load or stores can be marked as volatile, not
the variables.
So, I think the real question is: are COMPONENT_REF nodes allowed to be
marked as volatile by themselves? I think they should, and actually it
seems to work (the generated code looks correct).
If it is allowed, the attached patch would solve my problem too. Would
it be correct this time?
Thanks for your help,
Ricardo.
Index: ../gcc/tree-ssa-operands.c
===================================================================
--- ../gcc/tree-ssa-operands.c (revision 557)
+++ ../gcc/tree-ssa-operands.c (working copy)
@@ -1960,7 +1960,7 @@
if (code == COMPONENT_REF)
{
- if (s_ann && TREE_THIS_VOLATILE (TREE_OPERAND (expr, 1)))
+ if (s_ann && (TREE_THIS_VOLATILE (TREE_OPERAND (expr, 1)) || TREE_THIS_VOLATILE (expr)))
s_ann->has_volatile_ops = true;
get_expr_operands (stmt, &TREE_OPERAND (expr, 2), opf_none);
}
