On Wed, 30 Oct 2013, DJ Delorie wrote: > My proposal is to allow the target to define its own type for > pointers, sizeof_t, and ptrdiff_t to use, so that gcc can adapt to > weird pointer sizes instead of the target having to use power-of-two > pointer math. > > This means the target would somehow have to register its new types > (int20_t and uint20_t in the MSP430 case, for example), as well as > specify that type to the rest of gcc. There are some problems with > the naive approach, though, and the changes are somewhat pervasive.
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 <stdint.h>). Separately, it's a deficiency that these things are target macros rather than target hooks. I've previously suggested making these into enum values instead of strings (probably first making the target macros into such values, then later converting them into hooks that return such values). Specifically, I suggested that the values should come from enum integer_type_kind, as an existing enumeration of relevant standard integer types, and in <http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02900.html> suggested a possible division into hooks. The thread starting at <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00964.html> had such a conversion for stdint.h macros into enum-valued macros. This doesn't help you with your 20-bit types. I don't think the principle is wrong, though; it's just that the integer_type_kind enumeration should be extensible by targets in some way. Instead of having references to int128 hardcoded in various places in the core compiler, the information about the existence of such a type should go in some config/ file or files only used by those targets that actually support such a type for at least some multilibs (64-bit targets, typically). Regarding that, see various messages of mine to gcc-patches on 1 July 2011 in response to Bernd's 40-bit integer support changes. All the generic fixes (making FRACTIONAL_INT_MODEs work more reliably) went in, but not the changes that would have hardcoded references to 40-bit types in various places in the target-independent compiler. 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. -- Joseph S. Myers jos...@codesourcery.com
