This is the mail archive of the gcc-patches@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: [PATCH] Fix PR middle-end/17746


    Again, my question is: what behavior do we expect from this code?
    Given the quoted code

        ADDR_EXPR
          COMPONENT_REF
            VIEW_CONVERT_EXPR <record_type1 ... align-ok>
              INDIRECT_REF <record_type2>
                VAR_DECL <pointer_type <record_type2>>
    
    where the VIEW_CONVERT_EXPR is increasing the alignment, either
    1) we know that the pointer already has the proper alignment, or
    2) the pointer might not have the proper alignment, so we might need to
       copy into a record_type1 temporary with the appropriate alignment.

If #1 is true, then TYPE_ALIGN_OK should be set.

    I suspect that the get_inner_reference change was needed because #2 is
    true.  In that case, the gimplifier should allocate a temporary for the
    VIEW_CONVERT_EXPR on platforms where a temporary is needed.

Agreed.

    Perhaps the right fix is to make handled_component_p match
    get_inner_reference

That seems right.

    and tweak gimplify_compound_lval to set fallback fb_either if the base
    expression is a VIEW_CONVERT_EXPR.

This I don't follow.  Case #2 can't happen in an LHS: it's an ICE if it does.

    Incidentally, the expand_expr_real/VIEW_CONVERT_EXPR code doesn't seem
    to try to use 'target' in the alignment mismatch case; it seems to me
    that it should do that before it allocates a temporary.

Only if the sizes are the same, I think, but indeed that should be done.


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