This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Regression for trunk on i686-pc-linux-gnu
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Jul 2004 19:24:28 -0400
- Subject: Re: Regression for trunk on i686-pc-linux-gnu
- Organization: Red Hat Canada
- References: <10407272305.AA26278@vlsi1.ultra.nyu.edu>
On Tue, 2004-07-27 at 19:05, Richard Kenner wrote:
> Why not call get_base_address? That's the standard way of getting the
> pointer out of an INDIRECT_REF. Assuming that the INDIRECT_REF is
> already gimplified, of course.
>
> I didn't say it was hard, just that it wasn't *trivial*, so it's not
> clear you want to have the code explicitly everywhere.
>
> I still think that it is a mistake adding ADDR_EXPR <INDIRECT_REF <>>
> to GIMPLE.
>
> I agree, but that's not what was being done here. We're allowing it
> on a transitory basis knowing that we're about to fold it away.
>
Nothing in is_gimple_* is transitory. Its responses are etched in
stone.
> This needs to be solved in the front end. By allowing it in GIMPLE we
> are exposing ourselves to trouble.
>
> It's not a front end issue. This comes up during gimplification (the
> conversion of a MODIFY_EXPR to a memcpy call) and during constant
> propagation. I can't see a front end wanting to generate these things.
>
Then we fold away as we generate them. I don't see why we have to
accept these nodes in the IL. Especially, if we are always going to be
folding them. The reverse situation with *& is a similar problem.
> What about verify_stmt? That seems to be doing a good job.
>
Oh, right. How could I forget.
Diego.