Re: [patch] fix wrong gimple code with ptr to forward vla

[Olivier Hainque <hainque at adacore dot com>]

To start with, thanks for all the feedback on this issue.

Mark wrote:
> I'm not happy with this heuristic.  

> Wouldn't the same bug occur if a typedef was used to give a name to the
> pointer type?

 I don't think so. As Richard clarified later on, the idea was to check
 whether the pointed-to (not pointer) type has a name.
 
> In any case, I can't see any intuitive reason for making anonymity
> have semantics in the middle end.  (It does have semantics in some
> languages, of course, so in the front end I would not have the same
> objection.)

 I understand and share your concern.

 The middle-end operates over a large set of implicit assumptions
 about the entities it has to process, and about the order in which
 they are to be presented to it.

 It did not seem unreasonable to consider variants of such assumptions
 for a pointed-to type depending on whether it is anonymous or not (e.g.
 there is no possible forward declaration involved), but I agree
 exploiting such variations sure makes maintainance harder. Besides,
 one's understanding of what can implicitly be relied upon might simply
 be mistaken.

 Part of the issue here is that many aspects of the middle-end expectations
 are not explicit, and at this point we have two other suggestions for the 
 regression at hand:

 From Richard:

 << So the "proper" fix for this is to remove Jakub's patch and instead make
    a patch for the C (and perhaps C++) front ends to make a TYPE_DECL for
    that anonymous type and chain it accordingly.
 >>

 From Joseph:

 << front ends should be responsible for making sure that VLA sizes
    get evaluated at the right time and replacing them with temporary
    variables, rather than relying on SAVE_EXPRs getting evaluated at a
    sensible time.  The core gimplifier should then expect all array
    sizes to be either constant or a reference to a variable, and all
    it would do with them is arrange for stack space to be allocated /
    deallocated as required; the front end would have made sure that the
    internal variable has the right value at each point.
 >>

 The latter would be a step forward in making some middle-end expectations
 explicit.

 It looks to me like a significant change compared to the current
 implicit set, however, requiring changes to the middle-end + several
 front-ends, and Richard's suggestion appears like a simpler way out.

 Thoughts on that ?

 Thanks.