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.
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
> mayali
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.
Paolo Bonzini wrote:
The following patch fixes it, but it's completely untested.
2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
* gimplify.c (fold_indirect_ref_rhs): Use
STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
Index: ../../gcc/gimplify.c
=
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:
> > >
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;
> >
> >
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 b
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]
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 lo
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
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 no
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
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
14 matches
Mail list logo
