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

[Mark Mitchell <mark at codesourcery dot com>]

> > 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.
>
>  OK, I can give it a shot.

Thanks.  Perhaps Jakub would be willing to help with that, if you get stuck?

> > 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.
>
>  Sure. Humm, another quick thing for completeness: the very initial idea
>  for this patch was to check for the existence of a TYPE_DECL associated
>  with the pointed-to type. I wasn't sure how to achieve this, discussed
>  it with Richard, he told me way, and the anonymity idea came up.
>
>  This is conceptually different, but at this point in the discussion I'm
>  not sure it is really better.

Until this discussion, I believed that a TYPE_DECL is just a way of 
naming a type, and had no semantics.  (Joseph's approach would make that 
belief reality, by requiring that front ends make explicit any 
calculations required to compute sizes.)  However, at present, you've 
explained that TYPE_DECLs do have semantics; in particular, the bounds 
of VLAs are executed at the point where a TYPE_DECL occurs.

So, I think that checking for non-TYPE_DECL ness is a little better than 
anonymity; at least, we'd be checking for a semantic property.  However, 
given the situation outlined in the previous paragraph, it's pretty 
questionable: we're admitting the existence of variable-sized types 
without TYPE_DECLs, which means that there is no well-defined point at 
which the bounds should be calculated.  In particular, I don't think 
"the first time you encounter that type" is that well-defined.

But, I would be more accepting of the no-TYPE_DECL test than the no-name 
test, if we have to choose between those two.

Thanks,

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