From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107685 invoked by alias); 11 May 2015 17:46:13 -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 107674 invoked by uid 89); 11 May 2015 17:46:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,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; Mon, 11 May 2015 17:46:10 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 6BEB2542E7B; Mon, 11 May 2015 19:46:07 +0200 (CEST) Date: Mon, 11 May 2015 17:46: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: <20150511174607.GB59663@kam.mff.cuni.cz> References: <20150511142810.GA6584@kam.mff.cuni.cz> <5550E3D2.2080408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5550E3D2.2080408@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg00976.txt.bz2 > On 05/11/2015 09:28 AM, Jan Hubicka wrote: > >We already discussed earlier that type_in_anonymous_namespace_p is not working > >on compund types, because these do not have TYPE_STUB_DECL. I thought those are > >!TYPE_NAME types. What is reason for !TYPE_NAME type with no TYPE_STUB_DECL? > >Is it always a compound type with typedef name? > > Right. Typedef names have no linkage, so they aren't really ODR > types; only classes and enums have linkage. Why do you want to > check other types? Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle enums. But other case I would like to deal with are integer types - i.e. preserve difference between char/signed char/unsigned char/short/int/long/wchar in cases where they structurally coincide. This makes us to output better diagnostics on ODR violations caused by -fsigned-char mismatches, but it also has some issues with fact that LTO forcingly merge char_type_node no matter whetehr it agrees or disagress across units by preloading https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01538.html I can go with RECORD_OR_UNION_TYPE_P (..) || TREE_CODE (type) == ENUMERAL_TYPE with comment that those types have linkage and other not, but we lose some checks. Honza > > Jason