Re: [PATCH] Fix PR middle-end/17746

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> 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 
the "problem".

> 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 ?<kenner@vlsi1.ultra.nyu.edu>

????????* 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):

revision 1.54
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.

-- 
Eric Botcazou