Volatile operations and PRE

[Ricardo FERNANDEZ PASCUAL]

Thank you for your answer. I give some more information below:

Daniel Berlin wrote:

> On 11/6/06, Ricardo FERNANDEZ PASCUAL <ricardo.fernandez@st.com> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: volatile-vn-2.diff
Type: text/x-patch
Size: 527 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20061106/d67de29d/attachment.bin>