On Wed, 28 Aug 2013, Richard Biener wrote: > > That is not easily possible. The thing is, in the C FEs they are created > > from the C/C++ type name (for stdint purposes): > > if (INTPTR_TYPE) > > intptr_type_node = > > TREE_TYPE (identifier_global_value (c_get_ident (INTPTR_TYPE))); > > if (UINTPTR_TYPE) > > uintptr_type_node = > > TREE_TYPE (identifier_global_value (c_get_ident (UINTPTR_TYPE))); > > and are supposed to match the stdint.h previously used type, because > > it is part of ABI etc. (long vs. long long vs. int e.g. when two of these > > are the same precision). > > So the middle-end uintptr type needs to be something different, while it > > ideally should have the same precision, it is not the same language type. > > But it's the C ABI type - and we do need the C ABI types from within > the middle-end. Joseph, any idea?
The possible issues that I see are: * Types getting determined from strings (that are the values of macros such as INTPTR_TYPE) by the front ends. This is no real problem, in that the Fortran front end already emulates what's required in get_typenode_from_name. Of course it would be cleaner for all these macros to be defined to evaluate to enum values rather than strings, so the middle-end doesn't need such emulation of C type name parsing. See the thread starting at <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00964.html> for a conversion to using enum values for the stdint.h macros - that could be updated for current trunk. Of course the aim would be for other macros such as SIZE_TYPE to be converted as well, and indeed to get a conversion to hooks (probably a few separate hooks for different groups of types, taking appropriate enum values as arguments, rather than just one for all the typedefs or a separate hook for every typedef). * Targets still not having the type information in GCC. As I said in <http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00248.html>, listing those targets, it's probably time to deprecate them (and then freely check in changes that break them by requiring those types to be defined). -- Joseph S. Myers jos...@codesourcery.com
