From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24899 invoked by alias); 26 May 2003 00:33:15 -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 24841 invoked from network); 26 May 2003 00:33:14 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 26 May 2003 00:33:14 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h4Q0W8eR018175; Mon, 26 May 2003 02:32:08 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h4Q0W7j2018174; Mon, 26 May 2003 02:32:07 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Roger Sayle Cc: gcc@integrable-solutions.net, jason@redhat.com, Subject: Re: C++: Anticipated declaration of builtins. References: From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Mon, 26 May 2003 02:08:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg02231.txt.bz2 Roger Sayle writes: | Hi Gaby, | | > 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? | Similarly, the user-provided declaration/prototype in one namespace | could be compatible with the predeclared type, and hence use the | builtin's functionality, but the declaration given in the other | namespace incompatible, overrides the anticipated functionality | and providing it's own definition, DECL_RTL, etc... 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? | > 2) Why doesn't the second call to builtin_function_1() specify | > global_namespace instead of NULL_TREE? I think specifying | > global_namespace should be the way to go. What I am missing? | | For this I have no good answer. The original code used NULL_TREE | when I added the additional call to also anticipate the declaration | in the std:: namespace. I've no problem with you changing it if | that's more correct thing to do, and it passes regression checking. 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. Thanks, -- Gaby