This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/17746
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: ebotcazou at libertysurf dot fr
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 20 Oct 04 09:44:47 EDT
- Subject: Re: [PATCH] Fix PR middle-end/17746
Very interesting. You added the supplementary check for VIEW_CONVERT_EXPR
without updating handled_component_p. For the FSF tree:
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00396.html
I can't imagine this is an oversight.
I'm sure it was. If I did it purposely, I would have added a comment to
that effect.
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?
I came to the conclusion that returning true for them in
handled_component_p is a good solution (and that you probably came to
it too). They are handled like the other VIEW_CONVERT_EXPRs except
that, when they are expanded, an additional step is performed:
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 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?
I wouldn't do anything for GCC 3.4 (or GNAT 5.x) on the grounds of "if it
ain't broke, don't fix it", but in the head where we are very strict about
what trees look like, it's critical that get_inner_reference and
handled_component_p precisely agree.