This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/17746
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: gcc-patches at gcc dot gnu dot org
- Cc: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Wed, 20 Oct 2004 20:16:25 +0200
- Subject: Re: [PATCH] Fix PR middle-end/17746
- References: <10410201344.AA17587@vlsi1.ultra.nyu.edu>
> I'm sure it was. If I did it purposely, I would have added a comment to
> that effect.
I may have over-interpreted then.
> Here's my take on this. My initial reaction when investigating the
> problem was similar to yours: why on Earth is there this obvious gap
> between get_inner_reference and handled_component_p? I found your
> patch and immediately added the missing bits to handled_component_p.
> Then things started to break because is_gimple_addressable now returns
> false for this kind of VIEW_CONVERT_EXPR.
> Right, it's supposed to in that case. Why did that cause problems?
is_gimple_lvalue becomes false too. Moreover, the gimplifier doesn't know
what to do with these VIEW_CONVERT_EXPRs (gimplify_compound_lval aborts).
More fundamentally, I don't see why they should not be addressable.
> Yes, but that's just at the outer level: if you have a single
> VIEW_CONVERT_EXPR outside of a nest of references. It won't do the
> right thing if it's *inside* the nest of references.
I'm really skeptical about this assertion: how could the compiler have ever
worked on STRICT_ALIGNMENT platforms in that case? All GNAT 5.x releases have
> I'm wondering if we need the code in get_inner_reference that disallows
> certain VIEW_CONVERT_EXPRs. I think that might be the issue. Do you
> know why/when that was added?
As I already mentioned, it comes from:
2002-10-16 ?Richard Kenner ?<firstname.lastname@example.org>
????????* expr.c (get_inner_reference): Don't go through a VIEW_CONVERT_EXPR
????????whose purpose is to step up the alignment.
Probably ACT TN BA08-006, but the ChangeLog entry is a bit terse (gcc-31.dif):
date: 2002/10/16 14:09:31; author: kenner; state: Exp; lines: +34 -0
Add expr.c patch to fix BA08-006
That said, I'm all for removing this code if we can.