From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11975 invoked by alias); 31 Aug 2004 20:33:26 -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 11958 invoked from network); 31 Aug 2004 20:33:25 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org with SMTP; 31 Aug 2004 20:33:25 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i7VKXCl3004426; Tue, 31 Aug 2004 16:33:12 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7VKXO704773; Tue, 31 Aug 2004 16:33:24 -0400 Received: from frothingslosh.sfbay.redhat.com (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i7VKXNV20541; Tue, 31 Aug 2004 13:33:23 -0700 Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1]) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i7VKXNOo008566; Tue, 31 Aug 2004 13:33:23 -0700 Received: (from rth@localhost) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i7VKXNd5008564; Tue, 31 Aug 2004 13:33:23 -0700 X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 31 Aug 2004 20:44:00 -0000 From: Richard Henderson To: "Joseph S. Myers" Cc: gcc@gcc.gnu.org Subject: Re: Undefined static functions Message-ID: <20040831203323.GA8419@redhat.com> Mail-Followup-To: Richard Henderson , "Joseph S. Myers" , gcc@gcc.gnu.org References: <20040831050123.GA4683@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2004-08/txt/msg01672.txt.bz2 On Tue, Aug 31, 2004 at 08:31:09AM +0000, Joseph S. Myers wrote: > This does rather make me wonder whether what check_global_declarations > does after warning, > > /* This symbol is effectively an "extern" declaration now. */ > TREE_PUBLIC (decl) = 1; > > is particularly safe. Doesn't sound like it. I guess the reason it works is that encode_section_info has already done its job, and we don't call back into it now. > ... defining TREE_NO_WARNING to apply > to decls as well as expressions looks safer. TREE_NO_WARNING *does* apply to decls. See warn_uninit in tree-ssa.c. r~