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


    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.


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