From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52236 invoked by alias); 29 Nov 2017 09:33:12 -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 50473 invoked by uid 89); 29 Nov 2017 09:33:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Nov 2017 09:33:10 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5FBCB4E02B; Wed, 29 Nov 2017 09:33:09 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-77.ams2.redhat.com [10.36.116.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EA42B600D5; Wed, 29 Nov 2017 09:33:08 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id vAT9X6io022845; Wed, 29 Nov 2017 10:33:06 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id vAT9X58I022844; Wed, 29 Nov 2017 10:33:05 +0100 Date: Wed, 29 Nov 2017 09:39:00 -0000 From: Jakub Jelinek To: Nathan Sidwell Cc: GCC Patches Subject: Re: [PATCH] complex type canonicalization Message-ID: <20171129093304.GY2353@tucnak> Reply-To: Jakub Jelinek References: <384ed945-83b4-b421-ab82-92b5e236d874@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <384ed945-83b4-b421-ab82-92b5e236d874@acm.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02478.txt.bz2 On Tue, Nov 28, 2017 at 01:27:54PM -0500, Nathan Sidwell wrote: > --- tree.c (revision 255202) > +++ tree.c (working copy) > - /* We need to create a name, since complex is a fundamental type. */ > - if (!TYPE_NAME (t) && named) > + /* We need to create a name, since complex is a fundamental type. */ > + if (named) > + { > + const char *name = NULL; > + > + if (TREE_TYPE (t) == char_type_node) > + name = "complex char"; > + else if (TREE_TYPE (t) == signed_char_type_node) > + name = "complex signed char"; > + else if (TREE_TYPE (t) == unsigned_char_type_node) > + name = "complex unsigned char"; > + else if (TREE_TYPE (t) == short_integer_type_node) > + name = "complex short int"; > + else if (TREE_TYPE (t) == short_unsigned_type_node) > + name = "complex short unsigned int"; > + else if (TREE_TYPE (t) == integer_type_node) > + name = "complex int"; > + else if (TREE_TYPE (t) == unsigned_type_node) > + name = "complex unsigned int"; > + else if (TREE_TYPE (t) == long_integer_type_node) > + name = "complex long int"; > + else if (TREE_TYPE (t) == long_unsigned_type_node) > + name = "complex long unsigned int"; > + else if (TREE_TYPE (t) == long_long_integer_type_node) > + name = "complex long long int"; > + else if (TREE_TYPE (t) == long_long_unsigned_type_node) > + name = "complex long long unsigned int"; > + > + if (name != NULL) > + TYPE_NAME (t) = build_decl (UNKNOWN_LOCATION, TYPE_DECL, > + get_identifier (name), t); > + } Are you sure nothing can build_complex_type before build_common_tree_nodes is called and builds those? If that would happen, we'd fail to add names with your patch, while we'd add them before. The addition of TYPE_NAME looks orthogonal to the TYPE_CANONICAL handling and type hashing. I must also say I'm surprised that the recursive build_complex_type call passes in named too, but as it does type comparison by pointers, perhaps that's ok. Otherwise LGTM. Jakub