From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32306 invoked by alias); 30 Oct 2013 20:49:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32292 invoked by uid 89); 30 Oct 2013 20:49:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2013 20:49:27 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Vbchd-0003KW-Ty from joseph_myers@mentor.com ; Wed, 30 Oct 2013 13:49:21 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Oct 2013 13:49:22 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.2.247.3; Wed, 30 Oct 2013 20:49:19 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VbchZ-0007vO-VS; Wed, 30 Oct 2013 20:49:18 +0000 Date: Wed, 30 Oct 2013 20:49:00 -0000 From: "Joseph S. Myers" To: DJ Delorie CC: Subject: Re: proposal to make SIZE_TYPE more flexible In-Reply-To: <201310301917.r9UJHxg7028662@greed.delorie.com> Message-ID: References: <201310300422.r9U4M6Mx002568@greed.delorie.com> <201310301917.r9UJHxg7028662@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-10/txt/msg00321.txt.bz2 On Wed, 30 Oct 2013, DJ Delorie wrote: > > > It is a deficiency that SIZE_TYPE is defined to be a string at all (and > > likewise for all the other target macros for standard typedefs including > > all those for ). Separately, it's a deficiency that these > > things are target macros rather than target hooks. > > My thought was that there'd be a set of target hooks that returned a > TREE for various types. But as an interim solution, the checks that > use strcmp() should fail into a type lookup-by-name. I.e. replace the > gcc_unreachables with expensive table lookups. My reasoning is: * You need to have strings as the expansions of macros such as __SIZE_TYPE__. * You also need to have trees for the types, including in places such as the Fortran front end where converting a C type name into a tree may not be particularly convenient. * So the hook should return a type identifier that can be converted both to strings where those are needed and meaningful (in c-cppbuiltin.c) and into trees where those are needed (somewhere in the language-independent compiler). enum integer_type_kind is, if extended in some way to cover target-specific types, pretty much exactly what's wanted here. * If you do that, you eliminate the fragility of multiple orderings of type specifiers being valid in C but the exact ordering "long unsigned int" being needed in SIZE_TYPE. I hope it might be possible to eliminate the long sequence of record_builtin_type calls with such names, or at least simplify it, given some investigation of how they are used - there's a comment "Define `int' and `char' first so that dbx will output them first.", but since some of the calls use NULL as a type name they can't all be needed in order to provide names for debug info. > > Instead of having an __int128 keyword (target-independent) targets > > would be able to define a set of N for which there are __intN > > keywords and for which everything handling __int128 will equally > > handle __intN. > > That sounds great, and would elide the problem of a target needing to > register their own types for those. I hadn't considered simplifying > the intN_t problem, since you *can* register custom types, I was > mostly just thinking about how to *use* those types for size_t et al. Having a keyword is better than having a built-in typedef registered by the back end (or by c-common.c, in the case of __int128_t and __uint128_t), because a keyword can be used together with "_Complex" and "unsigned" in the same ways you could use "int" or "long", but you can't use a typedef with "_Complex" or "unsigned". -- Joseph S. Myers joseph@codesourcery.com