From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64538 invoked by alias); 12 May 2015 14:03:29 -0000 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 Received: (qmail 64515 invoked by uid 89); 12 May 2015 14:03:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 12 May 2015 14:03:18 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id E0D77543DCA; Tue, 12 May 2015 16:03:13 +0200 (CEST) Date: Tue, 12 May 2015 14:13:00 -0000 From: Jan Hubicka To: Jason Merrill Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: False ODR violation positives on anonymous namespace types Message-ID: <20150512140313.GA26537@kam.mff.cuni.cz> References: <20150511142810.GA6584@kam.mff.cuni.cz> <5550E3D2.2080408@redhat.com> <20150511174607.GB59663@kam.mff.cuni.cz> <5550ECB5.8000607@redhat.com> <20150511180509.GB22960@kam.mff.cuni.cz> <55511D40.1010808@redhat.com> <20150511213949.GB35526@kam.mff.cuni.cz> <55520517.1020507@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55520517.1020507@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg01088.txt.bz2 > On 05/11/2015 04:39 PM, Jan Hubicka wrote: > >What happens in LTO is that lto-symtab decide to merge the two declarations of > >foo. At this time it has chance to output the warning. For that it needs to > >be able to work out that these declarations are having different types, but > >because LTO merge canonical types on structural basis, types_compatible_p > >(long, int) will return true. > > OK. So I guess it makes sense to check built-in integer types as > well, but compound types should be compared structurally. Yes, agreed. if (flag_lto_odr_type_mering && TREE_CODE (decl) == TYPE_DECL && DECL_NAME (decl) && decl == TYPE_NAME (TREE_TYPE (decl)) && !is_lang_specific (TREE_TYPE (decl)) /* Save some work. Names of builtin types are always derived from properties of its main variant. A special case are integer types where mangling do make differences between char/signed char/unsigned char etc. Storing name for these makes e.g. -fno-signed-char/-fsigned-char mismatches to be handled well. See cp/mangle.c:write_builtin_type for details. */ && (TREE_CODE (TREE_TYPE (decl)) != VOID_TYPE && TREE_CODE (TREE_TYPE (decl)) != BOOLEAN_TYPE && TREE_CODE (TREE_TYPE (decl)) != REAL_TYPE && TREE_CODE (TREE_TYPE (decl)) != FIXED_POINT_TYPE) && !TYPE_ARTIFICIAL (TREE_TYPE (decl)) && !variably_modified_type_p (TREE_TYPE (decl), NULL_TREE) && !type_in_anonymous_namespace_p (TREE_TYPE (decl))) I probably want to check /* Record, union and enumeration type have linkage that allows use to check type_in_anonymous_namespace_p. Compound types can be always compared structurally. To save some work we compare builtin types properties of its main variant. A special case are integer types where mangling do make differences between char/signed char/unsigned char etc. Storing name for these makes e.g. -fno-signed-char/-fsigned-char mismatches to be handled well. See cp/mangle.c:write_builtin_type for details. */ && ((RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl)) || TREE_CODE (TREE_TYPE (decl)) == ENUMERATION_TIME && !type_in_anonymous_namespace_p (TREE_TYPE (decl))) || TREE_CODE (TREE_TYPE (decl)) == INTEGER_TYPE) I will test this. Thank you! Honza > > Jason