On Tue, 3 May 2011, Eric Botcazou wrote: > > In my view we should require front ends to take responsibility for > > variable-size types, and get rid of this language-independent function > > (copying such parts as are needed into the front ends that need them). > > I don't really see the point here. GCC supports variable-sized types in the > middle-end (stor-layout.c, gimplifier) so why special-casing this function?
In general errors from outside the front end, but relating to problems with the user's source code, are suspicious; the front end should detect invalid code, diagnose it and not pass it to the language-independent compiler. And the exact language semantics regarding where variable-size types are permitted and when the sizes should be evaluated are inherently front-end-specific and not easily represented in a generic function. convert.c is another place with errors that I think ought to go in the front ends; having some generic conversion logic is fine, but the front ends should deal with diagnosing invalid cases and convert.c should ICE if asked to do a conversion it doesn't know how to do. > > C for example uses its own version as the language-independent one isn't > > right for C. > > The C version looks an almost exact duplicate of the generic one though. We > should probably try to reconciliate the different versions. C doesn't want the language-independent errors (see above); they don't reflect the right logic for C. It needs to override parts of the generic function when called from generic code, and so to replace it when called from the front end. C returns -1 from global_bindings_p, as does Ada. That the languages that probably care most about variable-size types find aspects of the generic function need overriding like that should be a good indication that it isn't really that generic - as I said above, semantics for variable sizes are very front-end-specific. -- Joseph S. Myers jos...@codesourcery.com
