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 wrong gimple code with ptr to forward vla


Olivier Hainque wrote:

 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.

OK.


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.

OK, so we all agree we don't like the approach that's been proposed. The question now is one of pragmatism: what can we do in the relatively short term to solve the problem, without tying our hands for the future?


 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.

I think I understand why the heuristic works, in practice. It's based on Richard's explanation, which assumes an Ada-like language in which types are elaborated at a well-defined point. If you can't name the type, then its point of elaboration must be the point at which you first encounter it.


I guess that you can either make the assumption that there will be TYPE_DECLs for all types at their point of elaboration (which then allows the gimplifier to transform the size calculations into temporary variables, etc.), or do as Joseph suggests and make the front ends themselves perform the transformations.

I like Joseph's choice better. In particular, Richard's approach requires the C front end to make more TYPE_DECLs, which drives up memory usage. And, Joseph's choice also makes the middle-end semantics more straightforward, which I think is important in helping as many people as possible work on the common code. That said, I recognize that Joseph's change is not a simple one.

Have you looked into making Richard's proposed change to the C front end, as an alternate fix to Jakub's PR 21536? If you made the C front end explictly declare the type, then the type-elaboration approach would work as expected, and Jakub's patch could be removed. That would be a logically coherent approach, and we could always switch to Joseph's approach in the fullness of time.

In other words, I think I agree that Jakub's patch is incorrect: gimplification of pointer types should not imply gimplification of pointed-to types. But, I'd much rather fix it in a coherent way than with a dependence on anonymity, which is a clever, but logically rather indefensible, approach.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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