This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]