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: Fix processing of ADDR_EXPR in get_expr_operands


    I feel like I'm talking to myself here.  Yes, that's exactly what it
    means and that's exactly what I've been saying all this time.

It sounds like we're in what's often called "violent agreement", but saying
the same thing different ways.

    For address constants?  Yes, that's always the case.  CONSTANT is a
    superset of INVARIANT.  In an intra-procedural setting, we care for
    invariant addresses, we don't care if they are constant or not.

A few things:

(1) I'm not at all sure if the handling of nested variables is correct
or even what it should be.

(2) I'm not as convinced as you are that there is no conceivable
reason why constant might not be the proper check within a function.
But I indeed can't think of any at the moment.

(3) I think I may know what motivated the change I made: the stupid VLA
case we've been discussing.  There you have a case of a decl in the current
function whose address is *not* invariant.  And I think there are (or at
least used to be) other variables whose DECL_RTL is a MEM of a pseudo.
In all of those cases, it isn't invariant either: the invariance is
over the life of the variable, but not over the function.


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