From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-50611-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30675 invoked by alias); 24 Apr 2002 20:03:20 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 29352 invoked from network); 24 Apr 2002 20:01:32 -0000
Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237)
  by sources.redhat.com with SMTP; 24 Apr 2002 20:01:32 -0000
Received: from prospero.cambridge.redhat.com (dell-paw-2.cambridge.redhat.com [195.224.55.226])
	by executor.cambridge.redhat.com (Postfix) with ESMTP
	id D8CFBABB01; Wed, 24 Apr 2002 21:01:31 +0100 (BST)
Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046)
	id 171F4F7B7A; Wed, 24 Apr 2002 21:01:31 +0100 (BST)
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
Cc: Richard Henderson <rth@redhat.com>,
	Alan Modra <amodra@bigpond.net.au>,
	Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
Subject: Re: GCC 3.1 Prerelease
References: <5.1.1.2.2.20020423130143.04a21008@mail.lauterbach.com>
	<200204240003.42142@enzo.bigblue.local>
	<wvlr8l5vw8q.fsf@prospero.cambridge.redhat.com>
	<200204242101.39393@enzo.bigblue.local>
From: Jason Merrill <jason@redhat.com>
In-Reply-To: <200204242101.39393@enzo.bigblue.local> (Franz Sirl's message
 of "Wed, 24 Apr 2002 21:01:39 +0200")
Date: Wed, 24 Apr 2002 13:14:00 -0000
Message-ID: <wvly9fcvpb9.fsf@prospero.cambridge.redhat.com>
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-04/txt/msg01263.txt.bz2

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> Hmm, it seems to make more sense for the warning check too, with TREE_USED 
> changed to TREE_SYMBOL_REFERENCED the c++ regression 
> g++.old-deja/g++.jason/template39.C went away along with a bunch of 
> regressions in the libstdc++ testsuite, except one:

> FAIL: 26_numerics/complex_inserters_extractors.cc (test for excess errors)
> Excess errors:
> /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h: 
> In instantiation of `const size_t std::basic_string<char, gnu_char_traits, std::allocator<char> >::npos':
> /home/fsirl/TC/gcc/BUILD/gcc-3.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc:109:   
> instantiated from here
> /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h:217: 
> warning: weak declaration of `const size_t std::basic_string<char,
> gnu_char_traits, std::allocator<char> >::npos' after first use may result
> in unspecified behaviour

> Can a c++ expert tell me if this warning makes sense in this testcase or does 
> the warning check need still more refinement?

The latter.  We don't want to warn about the C++ frontend's internal
trickery with DECL_WEAK.

I'd prefer to omit the warning entirely on the branch.

> Hmm, Jason, I'm just noticing the purpose of the test in weak_finish.
...
> Are we sure there is no code out there relying on these lonely .weak 
> statements? Was this change intended?

I believe so.  But Richard was the one who made the change.

Jason