From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9725 invoked by alias); 7 Dec 2007 07:53:53 -0000 Received: (qmail 9709 invoked by uid 22791); 7 Dec 2007 07:53:51 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Dec 2007 07:53:47 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lB77ngG5028238; Fri, 7 Dec 2007 02:49:43 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [10.10.36.72]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lB77nfoK018138; Fri, 7 Dec 2007 02:49:41 -0500 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id lB77nfIM006624; Fri, 7 Dec 2007 02:49:41 -0500 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11/Submit) id lB77nfeF006622; Fri, 7 Dec 2007 02:49:41 -0500 Date: Fri, 07 Dec 2007 07:53:00 -0000 From: Jakub Jelinek To: Mark Mitchell Cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340) Message-ID: <20071207074941.GC13207@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <20071126233015.GP16835@devserv.devel.redhat.com> <20071205150141.GN16835@devserv.devel.redhat.com> <4758CC95.5040000@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4758CC95.5040000@codesourcery.com> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes 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: 2007-12/txt/msg00311.txt.bz2 On Thu, Dec 06, 2007 at 08:31:17PM -0800, Mark Mitchell wrote: > Jakub Jelinek wrote: > > > The following patch (which obsoletes my earlier 34238 patch) fixes all of > > this, but letting cgraph_optimize actually emit all the vars into assembly > > and only checking afterwards if we emitted something we shouldn't, which > > seems to be much more reliable. > > The diagnostic is not about what the compiler happens to end up spitting > out; it's about the user's program. If you do: > > namespace { struct A { static int i; }; } > static int foo() { return A::i; } > > the program is still erroneous, even though the compiler may likely > optimize away foo, and the reference to A::i. That's true, but the standard explicitly says the diagnostic is not required. With struct A { static int i; }; static int foo() { return A::i; } int main () {} as whole program we wouldn't diagnose this either. To me it is more important that we don't error on valid programs (especially a lot of boost using code is broken), and when all references are optimized out, no real harm is done, compiler doesn't make up something unexpected. When compiler puts it into bss, it can e.g. do so even for objects that need constructing, without running any constructors on it etc. That's something that should be warned about. If we have some bit which we can really rely on to be set reliably for these purposes, then the warning can be precise, but TREE_USED is unfortunately not it. BTW, is the boost testcase valid? template struct C { static T ca; static const int value = sizeof (D::foo (ca, 0)) == sizeof (int); }; is instantiated with T in anon namespace (so ca is also limited to current CU), but it is (intentionally) never defined and only used in sizeof expression. [class.static.data]/5 says "There shall be exactly one definition of a static data member that is used in a program" but it is not clear (at least to me) what exactly counts as use. Boost certainly wouldn't like to pollute bss of programs with many (sometimes big) variables that nobody ever uses. I'm afraid I don't know the FE enough to further improve this warning without breaking valid programs, so the other possibility for me is just to back out the original patch and leave this can of worms to you/Jason. Though, waiting for that in a state which at least errors out when real harm is done rather than being silent even for those cases is IMHO preferrable. Jakub