This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: ebotcazou at libertysurf dot fr
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 21 Dec 04 08:10:18 EST
- Subject: Re: [ada] can't build g-awk.adb in gcc cvs trunk 20041212 on sparc-linux: GCC error: in expand_expr_addr_expr_1, at expr.c:6047, Error detected at g-awk.adb:1316:24
and neither expand_expr_addr_expr nor expand_expr_addr_expr_1 make
temporaries, based on alignment conditions or not.
I know. And I'm not at all sure that won't cause problems elsewhere,
though I agree that it's far better for the gimplifier to make those
temporaries (and even better if the front end can do it). But that means
the writing of code to detect when they have to be made, and no such code
exists yet. So I'm guessing that Ada is broken on STRICT_ALIGNMENT
machines on the head now because of this. But it's *way* too early to
look for test cases.
I think that, when expand_expr_addr_expr is invoked on an ADDR_EXPR
tree, it will make no difference whether the alignment gets explicitly
stepped up when a VIEW_CONVERT_EXPR is encountered or not, because the
final object the address of which will be returned will be the same.
What do you think?
Given that nobody cares anymore, that's certainly true.
The other question is if we have to do the step-up in the _REF case.
I think we still do there, so the disparity between handled_components_p
and get_inner_reference needs to remain and should be documented.