From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-376015-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18649 invoked by alias); 22 Aug 2014 20:24:18 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 18628 invoked by uid 89); 22 Aug 2014 20:24:18 -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,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
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; Fri, 22 Aug 2014 20:24:16 +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 s7MKODrX030334	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);	Fri, 22 Aug 2014 16:24:14 -0400
Received: from greed.delorie.com (ovpn-113-60.phx2.redhat.com [10.3.113.60])	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7MKOBmQ006904	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);	Fri, 22 Aug 2014 16:24:12 -0400
Received: from greed.delorie.com (greed.delorie.com [127.0.0.1])	by greed.delorie.com (8.14.4/8.14.4) with ESMTP id s7MKOBeb029214;	Fri, 22 Aug 2014 16:24:11 -0400
Received: (from dj@localhost)	by greed.delorie.com (8.14.4/8.14.4/Submit) id s7MKOA3D029213;	Fri, 22 Aug 2014 16:24:10 -0400
Date: Fri, 22 Aug 2014 20:24:00 -0000
Message-Id: <201408222024.s7MKOA3D029213@greed.delorie.com>
From: DJ Delorie <dj@redhat.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
CC: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
In-reply-to: <Pine.LNX.4.64.1408222013390.16713@digraph.polyomino.org.uk>	(joseph@codesourcery.com)
Subject: Re: __intN patch 3/5: main __int128 -> __intN conversion.
References: <201408132211.s7DMBGBu016387@greed.delorie.com> <Pine.LNX.4.64.1408212030310.16900@digraph.polyomino.org.uk> <201408212123.s7LLNPIQ018746@greed.delorie.com> <Pine.LNX.4.64.1408212131060.16900@digraph.polyomino.org.uk> <201408220515.s7M5Fhpa007479@greed.delorie.com> <Pine.LNX.4.64.1408221051550.5292@digraph.polyomino.org.uk> <201408221924.s7MJOcjB022631@greed.delorie.com> <Pine.LNX.4.64.1408222013390.16713@digraph.polyomino.org.uk>
X-IsSubscribed: yes
X-SW-Source: 2014-08/txt/msg02224.txt.bz2


> I don't see flag_iso as relevant here (since the macros are in the 
> implementation namespace).  The definitions could reasonably be restricted 
> to c_dialect_cxx (), though, given that they are specifically for use by 
> libstdc++ (and it's easier to add a macro later for C if needed, than to 
> remove one after adding it).

They reflect a previous check in libstdc++ to remove __int128
specializations for non-ISO cases.  Now, though, libstdc++ doesn't
know which types are needed for pointers and which aren't, so the
check was moved to inside gcc, which does know.