From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-366929-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10374 invoked by alias); 9 May 2014 02:21:52 -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 10344 invoked by uid 89); 9 May 2014 02:21:51 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-4.0 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 ESMTP; Fri, 09 May 2014 02:21:49 +0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s492LlLe010889	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);	Thu, 8 May 2014 22:21:47 -0400
Received: from greed.delorie.com (ovpn-113-109.phx2.redhat.com [10.3.113.109])	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s492Lk86020832	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);	Thu, 8 May 2014 22:21:47 -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 s492Ljso005861;	Thu, 8 May 2014 22:21:45 -0400
Received: (from dj@localhost)	by greed.delorie.com (8.14.4/8.14.4/Submit) id s492LjKD005860;	Thu, 8 May 2014 22:21:45 -0400
Date: Fri, 09 May 2014 02:21:00 -0000
Message-Id: <201405090221.s492LjKD005860@greed.delorie.com>
From: DJ Delorie <dj@redhat.com>
To: libstdc++@gcc.gnu.org
CC: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
In-reply-to: <alpine.DEB.2.10.1405090211170.3709@laptop-mg.saclay.inria.fr>	(message from Marc Glisse on Fri, 9 May 2014 02:26:20 +0200 (CEST))
Subject: Re: [patch] change specific int128 -> generic intN
References: <201404142303.s3EN3ONP009938@greed.delorie.com> <201405082334.s48NYZni001625@greed.delorie.com> <alpine.DEB.2.10.1405090211170.3709@laptop-mg.saclay.inria.fr>
X-IsSubscribed: yes
X-SW-Source: 2014-05/txt/msg00544.txt.bz2


> Assuming that the formula sizeof(type)*char_bit==precision works for all 

It doesn't.  THe MSP430 has __int20 for example.

Would it be acceptable for the compiler to always define a set of
macros for each of the intN types?  I would have thought that would be
discouraged, but it would be an easier way to handle it.