From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25115 invoked by alias); 3 May 2011 20:05:55 -0000 Received: (qmail 25101 invoked by uid 22791); 3 May 2011 20:05:53 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 20:05:40 +0000 Received: (qmail 9105 invoked from network); 3 May 2011 20:05:39 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 May 2011 20:05:39 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QHLqj-0003U2-JM; Tue, 03 May 2011 20:05:37 +0000 Date: Tue, 03 May 2011 20:09:00 -0000 From: "Joseph S. Myers" To: Eric Botcazou cc: Jan Hubicka , gcc-patches@gcc.gnu.org, Xinliang David Li Subject: Re: [google]: initialize language field for clone function struct In-Reply-To: <201105032151.17713.ebotcazou@adacore.com> Message-ID: References: <201105032034.51751.ebotcazou@adacore.com> <201105032151.17713.ebotcazou@adacore.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg00219.txt.bz2 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 joseph@codesourcery.com