This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to allow Ada to work with tree-ssa
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 22 Jun 2004 13:49:08 -0700
- Subject: Re: Patch to allow Ada to work with tree-ssa
- References: <10406221952.AA09590@vlsi1.ultra.nyu.edu>
On Tue, Jun 22, 2004 at 03:52:25PM -0400, Richard Kenner wrote:
> Using TYPE_ALIGN doesn't work because you don't know whether all the fields
> in the path are aligned that way. They might be "bit fields" that are
> misaligned. Before highest_pow2_factor and the MEM_ALIGN addition, we used
> to get this wrong a lot. Now we are very precise.
Surely you're applying highest_pow2_factor step-by-step as you walk
down the components. Which means that the TYPE_ALIGN is just fine.
I'm absolutely certain that this *must* change. For exactly the same
reason that we added TYPE_SIZE_UNIT, we do not want to be doing pointer
arithmetic in units other than bytes.
> Sure, but by that argument we can allow <PLUS_EXPR <MULT_EXPR ....>> in
> GIMPLE! My point is that REALPART_EXPR and IMAGPART_EXPR have inputs and
> outputs that are both scalars, so it would seem more in keeping with
> the GIMPLE strategy to not mix them with other operations.
This is wrong. REALPART_EXPR is not like other gimple operands
because (irritatingly) it is an lvalue. You can take its address.
It has *exactly* the same semantics as <COMPONENT_REF var real_part>
or <ARRAY_REF var 0>. So it should be treated the same way.
r~