From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23089 invoked by alias); 26 May 2003 02:17:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13318 invoked from network); 26 May 2003 02:15:42 -0000 Received: from unknown (HELO www.eyesopen.COM) (12.96.199.11) by sources.redhat.com with SMTP; 26 May 2003 02:15:42 -0000 Received: from localhost (roger@localhost) by www.eyesopen.COM (8.11.6/8.11.6) with ESMTP id h4Q1t9N06454; Sun, 25 May 2003 19:55:09 -0600 Date: Mon, 26 May 2003 02:44:00 -0000 From: Roger Sayle To: Gabriel Dos Reis cc: jason@redhat.com, Subject: Re: C++: Anticipated declaration of builtins. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-05/txt/msg02233.txt.bz2 > | > 1) Shouldn't we pre-declare the function at global scope, then > | > do a using-declaration at the standard scope? > | > | The problem here is that they need to be treated as two independent > | pre-declarations. If a prototype or declaration is given for > | one, it does not automatically anticipate/declare the other. Hence, > | we require separate DECLs with independent DECL_ANTICIPATED flags. > > Hmm, why do we need to have two independent declarations for the same > builtin? Because of the way that duplicate_decls overwrites the original decl when redeclaring a declaration, such as when an anticipated built-in function is prototyped. If a single decl was shared between ::strlen and std::strlen, then the destructive modification of the first decl would side-effect the second. I'd hoped this was clear from my reference to the DECL_ANTICIPATED flag. Setting it to true for the decl in the first namespace should not automatically set the DECL_ANTICIPATED field of the pre-declaration in the second namespace. I believe/hope that the DECLs themselves take up very little space, they don't contain any RTL, they share their types and other major fields. So the DECL itself just acts a place holder, associating the namespace/identifier, with its types, flags and attributes. > If we have the same builtin declared twice with possibly two > incompatible declarations, it occurs to me that we're calling for > trouble. Is there any case where that could be useful? The DECL_BUILT_IN and similar attributes are only preserved if the declarations are compatible. If the type of the redeclaration doesn't match the anticipated/pre-declared type, the old decl is just completely overwritten. Consider: // Global namespace declaration matches anticipated type. extern "C" size_t strlen(const char *); // std namespace declaration doesn't match anticipated type. namespace std { double strlen; } We end up modifying or overwritting the anticipated decls for each redeclaration, but clearly with very different information in each. Its not that we use the same "built-in" function with different types, but that we may or may not completely overwrite the decls based upon different types, i.e. redeclare the DECL associated with the identifier differently in different contexts. The built-in only gets used when the types match. A less ambiguous/confusing example might be: int strlen; namespace std { double strlen; } in which neither declaration matches the pre-declared built-in. > The point is that I have been reworking some part of th name lookup > machinery, and that particular behaviour crashes the compiler until I > realized that declarations (of builtins) in the outer space is no good. > If they are supposed to be pre-declared at the global scope (as the > comment indicates), then their DECL_CONTEXT should point to > global_namespace. I'll make that change, once I understand the other > issue. That sounds very reasonable. Fortunately, fixing this should be independent of the first issue. You can be forgiven for being confused by the current convoluted scheme. I'd really like to see reuse of old DECLs in C/C++'s duplicate_decls removed, but the entire area is a minefield, and the current implementation has the one redeeming feature that, for the time being, it works and works efficiently. I hope this is clearer with a second explanation. Roger --