This is the mail archive of the 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

    Very interesting.  You added the supplementary check for VIEW_CONVERT_EXPR 
    without updating handled_component_p.  For the FSF tree:

    I can't imagine this is an oversight.  

I'm sure it was.  If I did it purposely, I would have added a comment to
that effect.

    Here's my take on this.  My initial reaction when investigating the
    problem was similar to yours: why on Earth is there this obvious gap
    between get_inner_reference and handled_component_p?  I found your
    patch and immediately added the missing bits to handled_component_p.
    Then things started to break because is_gimple_addressable now returns
    false for this kind of VIEW_CONVERT_EXPR.

Right, it's supposed to in that case.  Why did that cause problems?

    I came to the conclusion that returning true for them in
    handled_component_p is a good solution (and that you probably came to
    it too).  They are handled like the other VIEW_CONVERT_EXPRs except
    that, when they are expanded, an additional step is performed:

Yes, but that's just at the outer level: if you have a single
VIEW_CONVERT_EXPR outside of a nest of references.  It won't do the
right thing if it's *inside* the nest of references.

I'm wondering if we need the code in get_inner_reference that disallows
certain VIEW_CONVERT_EXPRs.  I think that might be the issue.  Do you
know why/when that was added?

I wouldn't do anything for GCC 3.4 (or GNAT 5.x) on the grounds of "if it
ain't broke, don't fix it", but in the head where we are very strict about
what trees look like, it's critical that get_inner_reference and
handled_component_p precisely agree.

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