From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26882 invoked by alias); 4 Oct 2014 18:10:51 -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 26871 invoked by uid 89); 4 Oct 2014 18:10:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 04 Oct 2014 18:10:49 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s94IAkr2010803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 4 Oct 2014 14:10:46 -0400 Received: from [10.10.116.27] ([10.10.116.27]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s94IAjY6015402; Sat, 4 Oct 2014 14:10:45 -0400 Message-ID: <54303821.2090205@redhat.com> Date: Sat, 04 Oct 2014 18:10:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: DJ Delorie CC: nathan@codesourcery.com, gcc-patches@gcc.gnu.org Subject: Re: __intN patch 3/5: main __int128 -> __intN conversion. References: <201408132211.s7DMBGBu016387@greed.delorie.com> <201408212123.s7LLNPIQ018746@greed.delorie.com> <201408220515.s7M5Fhpa007479@greed.delorie.com> <201408221924.s7MJOcjB022631@greed.delorie.com> <201408260303.s7Q33nqm024601@greed.delorie.com> <201409302314.s8UNE7LP020494@greed.delorie.com> <542CC4FA.70609@redhat.com> <201410020352.s923qLlm002274@greed.delorie.com> <542D5FA4.6020401@redhat.com> <201410021641.s92GfTcV024373@greed.delorie.com> <542D8F05.7090705@redhat.com> <201410021800.s92I04Nk026647@greed.delorie.com> <542EAD69.9090306@redhat.com> <201410032011.s93KBpc2005414@greed.delorie.com> In-Reply-To: <201410032011.s93KBpc2005414@greed.delorie.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00378.txt.bz2 On 10/03/2014 04:11 PM, DJ Delorie wrote: > Note that there is a separate __int128_t type that isn't part of the > "standard" extension. Maybe it's there for that type? > > Otherwise, I don't see what moving the test would accomplish. If > "long" is never 128 bits, it doesn't matter if the int128 test is > before or after it, and the other intN are never the same size as > standard types, I don't see how you can assert that these will never happen. Why not make the code more correct, while we're touching it? > and we already have code to prefer unsigned for intN types. What I don't see is the intN parallel to this: > if (same_type_p (TYPE_MAIN_VARIANT (t1), long_long_unsigned_type_node) > || same_type_p (TYPE_MAIN_VARIANT (t2), long_long_unsigned_type_node)) > return build_type_attribute_variant (long_long_unsigned_type_node, > attributes); Your patch only compares t1/t2 to int_n_trees[i].signed_type. Jason