> Internally, we use VIEW_CONVERT_EXPR to overlay a TImode
> container on top of a struct. There is no exact C
> equivalent, though a union comes close. I tried that,
> but couldn't replicate the exact set of events that have
> to be present to hit the problem. I send what I tried
> to you separa
On 12/01/08 11:50:48, Eric Botcazou wrote:
> > cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC,
> > and is the routine that writes the REG_EQUAL note.
>
> OK, thanks. But I'm a little at a loss as to why this problem arises only
> now: the problematic code in lookup_as_f
t;[EMAIL PROTECTED]> wrote:
> From: Eric Botcazou <[EMAIL PROTECTED]>
> Subject: Re: CSE bug when narrowing constants
> To: "Gary Funck" <[EMAIL PROTECTED]>
> Cc: gcc@gcc.gnu.org
> Date: Monday, 1 December, 2008, 10:50 AM
> > cse_insn() calls lookup_as_
> cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC,
> and is the routine that writes the REG_EQUAL note.
OK, thanks. But I'm a little at a loss as to why this problem arises only
now: the problematic code in lookup_as_function is one decade old. Do you
happen to have ol
On 11/29/08 14:45:49, Eric Botcazou wrote:
> > Agreed. The routine that creates the errant REG_EQUAL note is
> > lookup_as_function().
>
> Really? Doesn't it only retrieve a pre-existing REG_EQUAL note?
It retrieves an equivalent rtx constant, if it exists. Before the patch,
the constant that
> Agreed. The routine that creates the errant REG_EQUAL note is
> lookup_as_function().
Really? Doesn't it only retrieve a pre-existing REG_EQUAL note?
--
Eric Botcazou
On 11/29/08 10:37:33, Eric Botcazou wrote:
> > The conditional jump instruction formed by instructions
> > 56 and 57 above is deleted because GCSE thinks that
> > (reg:SI 61 [ p$thread ]) is non-zero. It comes to this
> > conclusion when it propagates the
> >REG_EQUAL (const_int 4294967296 [0x
> The conditional jump instruction formed by instructions
> 56 and 57 above is deleted because GCSE thinks that
> (reg:SI 61 [ p$thread ]) is non-zero. It comes to this
> conclusion when it propagates the
>REG_EQUAL (const_int 4294967296 [0x1])
> value listed in instruction 25:
>
> (in
On 11/28/08 16:02:11, Gary Funck wrote:
>
> I'd think that somewhere in there gen_lowpart() needs to
> be called.
I posted a suggested patch:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01466.html
which fixes the reported problem.
