From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-181075-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24773 invoked by alias); 21 Nov 2013 22:41:55 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 24764 invoked by uid 89); 21 Nov 2013 22:41:54 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2
X-HELO: mx1.redhat.com
Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Nov 2013 22:41:11 +0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rALMf3mI000440	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Thu, 21 Nov 2013 17:41:03 -0500
Received: from greed.delorie.com (ovpn-113-31.phx2.redhat.com [10.3.113.31])	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rALMf2q0011445	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);	Thu, 21 Nov 2013 17:41:03 -0500
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 rALMf1UN028022;	Thu, 21 Nov 2013 17:41:01 -0500
Received: (from dj@localhost)	by greed.delorie.com (8.14.4/8.14.4/Submit) id rALMf15B028014;	Thu, 21 Nov 2013 17:41:01 -0500
Date: Thu, 21 Nov 2013 22:41:00 -0000
Message-Id: <201311212241.rALMf15B028014@greed.delorie.com>
From: DJ Delorie <dj@redhat.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
CC: richard.guenther@gmail.com, gcc@gcc.gnu.org
In-reply-to: <Pine.LNX.4.64.1311161211240.32731@digraph.polyomino.org.uk>	(joseph@codesourcery.com)
Subject: Re: proposal to make SIZE_TYPE more flexible
References: <201310300422.r9U4M6Mx002568@greed.delorie.com> <Pine.LNX.4.64.1310301535400.22878@digraph.polyomino.org.uk> <201310301917.r9UJHxg7028662@greed.delorie.com> <Pine.LNX.4.64.1310302035190.29408@digraph.polyomino.org.uk> <201310302219.r9UMJg9e001309@greed.delorie.com> <Pine.LNX.4.64.1310302249250.29408@digraph.polyomino.org.uk> <201311140158.rAE1wCkg006136@greed.delorie.com> <Pine.LNX.4.64.1311141318300.21407@digraph.polyomino.org.uk> <201311152338.rAFNc9CJ007961@greed.delorie.com> <b69fa903-a837-4d4e-aa00-c2a22b06c1c4@email.android.com> <Pine.LNX.4.64.1311161211240.32731@digraph.polyomino.org.uk>
X-IsSubscribed: yes
X-SW-Source: 2013-11/txt/msg00425.txt.bz2


I did an audit of the core files for "integer_type_node" and didn't
see much beyond what was already noted (i.e. mostly builtins and
constants).

Since core builtins shouldn't be using intN types anyway, I don't
think there are many cases left where the core needs to "know" about
all the types, once the types are initialized.  It's mostly the FE
that need to know about the new intN types.

(my personal worry is how much of the core assumes that types are
powers-of-two)

So where can we begin on all this?