From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26303 invoked by alias); 7 Dec 2007 20:52:46 -0000 Received: (qmail 26293 invoked by uid 22791); 7 Dec 2007 20:52:46 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Dec 2007 20:52:40 +0000 Received: (qmail 26597 invoked from network); 7 Dec 2007 20:52:38 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Dec 2007 20:52:38 -0000 Message-ID: <4759B28F.5090608@codesourcery.com> Date: Fri, 07 Dec 2007 20:52:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jakub Jelinek CC: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340) References: <20071126233015.GP16835@devserv.devel.redhat.com> <20071205150141.GN16835@devserv.devel.redhat.com> <4758CC95.5040000@codesourcery.com> <20071207074941.GC13207@devserv.devel.redhat.com> In-Reply-To: <20071207074941.GC13207@devserv.devel.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00363.txt.bz2 Jakub Jelinek wrote: >> 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. It does? Where? (I'm not disagreeing, I'm just surprised, and I couldn't find a pointer.) > 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. We don't want to issue errors about valid programs -- but we do want to issue diagnostics about invalid programs. Those can be warnings, pedwarns, etc.; they don't necessarily have to stop compilation. > 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. TREE_USED should be accurate. It should tell us whether or not a thing was used by the input. If TREE_USED is not set when it should be, or set when it shouldn't be, we have a problem. > template struct C > { > static T ca; > static const int value = sizeof (D::foo (ca, 0)) == sizeof (int); > }; I don't think the standard is not entirely clear. It says this code is not evaluated, but I don't see anything that says that this means that "ca" is not used. Of course, might well not require that, independent of what the standard says; I agree that QoI suggests not issuing an error in this case. > 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. All right; let's revert your original patch, then. AIUI, that patch fixed an accepts-invalid problem; that's better than rejects-valid problems. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713