This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal to make SIZE_TYPE more flexible
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: <richard dot guenther at gmail dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 22 Nov 2013 12:42:58 +0000
- Subject: Re: proposal to make SIZE_TYPE more flexible
- Authentication-results: sourceware.org; auth=none
- References: <201310300422 dot r9U4M6Mx002568 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310301535400 dot 22878 at digraph dot polyomino dot org dot uk> <201310301917 dot r9UJHxg7028662 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310302035190 dot 29408 at digraph dot polyomino dot org dot uk> <201310302219 dot r9UMJg9e001309 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310302249250 dot 29408 at digraph dot polyomino dot org dot uk> <201311140158 dot rAE1wCkg006136 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311141318300 dot 21407 at digraph dot polyomino dot org dot uk> <201311152338 dot rAFNc9CJ007961 at greed dot delorie dot com> <b69fa903-a837-4d4e-aa00-c2a22b06c1c4 at email dot android dot com> <Pine dot LNX dot 4 dot 64 dot 1311161211240 dot 32731 at digraph dot polyomino dot org dot uk> <201311212241 dot rALMf15B028014 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311212258320 dot 26755 at digraph dot polyomino dot org dot uk> <201311220828 dot rAM8Ss0q011135 at greed dot delorie dot com>
On Fri, 22 Nov 2013, DJ Delorie wrote:
> If I come up with some table-driven API to register
> "integer-like-types" and search/sort/choose from them, would that be a
> good starting point? Then we can #define *_type_node to a function
> call perhaps.
I am doubtful that it's appropriate for e.g. integer_type_node to be a
function call. I can believe it makes sense for int128_integer_type_node
to be such a call (more precisely, for int128_integer_type_node to cease
to exist and for any front-end places needing it to call a function, with
a type size that should not be a constant 128). I can also believe it's
appropriate for the global nodes for trees reflecting C ABI types to go
somewhere other than tree.h.
I've no idea whether a table-driven API for anything would be a good
starting point. That depends on a detailed analysis of the current
situation and its deficiencies for whatever you are proposing replacing
with such an API.
I *am* reasonably confident that the places handling hardcoded lists of
intQI_type_node, intHI_type_node, ... would better iterate over whatever
supported integer modes may be present in the particular compiler
configuration (and have some set of signed / unsigned / atomic types
associated with integer modes) rather than hardcoding a list.
It would not surprise me if some of the global type nodes either aren't
needed at all or, being only used for built-in functions, should actually
be defined in builtin-types.def rather than tree.[ch]. For example,
complex_integer_type_node and float_ptr_type_node. But I don't think
cleaning up those would actually help in any way towards your goal; it
would be a completely orthogonal cleanup.
--
Joseph S. Myers
joseph@codesourcery.com