On 11/15/06, Richard Guenther [EMAIL PROTECTED] wrote:
On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Andrew Haley [EMAIL PROTECTED] writes:
2006-11-07 Paolo Bonzini [EMAIL PROTECTED]
* gimplify.c (fold_indirect_ref_rhs): Use
On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Andrew Haley [EMAIL PROTECTED] writes:
2006-11-07 Paolo Bonzini [EMAIL PROTECTED]
* gimplify.c (fold_indirect_ref_rhs): Use
STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
Regtested
Paolo Bonzini writes:
At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.
Almost there. It looks like strip_useless_type_conversions is not used,
and then something Bad happens.
The following patch fixes it, but it's completely untested.
Andrew Haley [EMAIL PROTECTED] writes:
2006-11-07 Paolo Bonzini [EMAIL PROTECTED]
* gimplify.c (fold_indirect_ref_rhs): Use
STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
Regtested x86-64-gnu-linux. The only interesting failure was
mayalias-2.c, but
Andrew Haley wrote:
Ricardo FERNANDEZ PASCUAL writes:
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).
volatile is a type qualifier. The type of a
Ricardo FERNANDEZ PASCUAL writes:
Andrew Haley wrote:
Ricardo FERNANDEZ PASCUAL writes:
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
At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.
Almost there. It looks like strip_useless_type_conversions is not used,
and then something Bad happens.
The following patch fixes it, but it's completely untested.
2006-11-07 Paolo Bonzini [EMAIL PROTECTED]
Paolo Bonzini wrote:
At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.
Almost there. It looks like strip_useless_type_conversions is not
used, and then something Bad happens.
Thank you Andrew and Paolo for your quick answers. I have made a report
for this
On 07 November 2006 16:33, Andrew Haley wrote:
Ricardo FERNANDEZ PASCUAL writes:
I have done some experiments to try to understand what is happening, and
I am a bit confused by the bahavior of GCC. Consider the following C
function:
static struct { int w; } s;
void wait
Dave Korn writes:
On 07 November 2006 16:33, Andrew Haley wrote:
Ricardo FERNANDEZ PASCUAL writes:
I have done some experiments to try to understand what is happening, and
I am a bit confused by the bahavior of GCC. Consider the following C
function:
static
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
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
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
Ricardo FERNANDEZ PASCUAL writes:
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
14 matches
Mail list logo
