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: Question on aggregates and GIMPLE

    Well, unless you've done something wrt your most curious use of
    VIEW_CONVERT_EXPR, then yes we will make a temporary.

But that's an error because the code will then abort due to the fact that it
doesn't allow ARRAY_TYPE or any variable-sized type.

However, this particular issue isn't a "most curious use", but can easily
result from a user-level Unchecked_Conversion.  The programmer would consider
it very unfriendly for a copy to occur.

    If you've changed things to arrange for it to be considered
    is_gimple_lvalue in the gimple grammer, then no, you shouldn't need a
    temporary.  Instead it'll remain the rhs of a MODIFY_EXPR which will
    be expanded to memcpy by expand_expr.

Well, do you think that I *should* change things that way?

    Are you going to start posting patches for these sorts of gimple
    extensions so that we can review them?

I'm not sure when the best time is.  On the one hand, I'd like to get a
little further along and have more confidence in the approach, but on the
other hand, it would indeed be good for others to see the direction I'm going.

    What the hell does a comparison of an aggregate mean?  

What it always has!  do_jump has supported it for over a decade!

    I suppose we could gimplify it to memcmp, but since I suspect no one
    else thinks such things are possible, this could as well be a
    front-end issue.

But it's valid in the GCC tree and always has been!

    Given that no one other than you knows what a PLACEHOLDER_EXPR is,
    it's up to you to figure out where we're missing such things and
    replicate expr_size and its ilk to work on trees in gimplify.c.

Sorry, I didn't mean my general comment about how to handle things related
PLACEHOLDER_EXPR.  Those are trivial: it's just a matter of code calling
expr_size instead of thinking that it knows how to do it itself, as I see a
lot of places doing.

    And since no one other than Ada uses such things, I consider this
    part and parcel with porting the Ada front end.

Yes and no.  Sure, only Ada *uses* it, but these things have always been
supported in the middle-end and are defined in the tree structure, so not
implementing those things as part of the tree-ssa work is a major regression.
I'm certainly willing to work on fixing them, and have been, but I need
feedback on the best way to do so.

Basically what I was saying in this message is that I see quite a number of
holes in the handling of copies and comparisons of aggregate values, things
which are indeed very rare in C and quite common in Ada.

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