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: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 21 Dec 2004 17:51:34 +0100
- 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
- References: <10412211310.AA28309@vlsi1.ultra.nyu.edu>
> 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.
OK, that's more or less the conclusion I came to.
> So I'm guessing that Ada is broken on STRICT_ALIGNMENT machines on the head
> now because of this.
Not that much according to the ACATS testsuite, the results on the SPARC were
on par with those on x86 the last time I tried. Of course ACATS is not
exhaustive.
> 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.
I can't believe that the chunk of code I quoted in my previous message was
simply dropped. Isn't there any substitute elsewhere?
> 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.
Agreed.
--
Eric Botcazou