User account creation filtered due to spam.
This PR is to track the existence of issues that will need to be fixed for full C99 support, and the reason for some XFAILs. For printf and scanf format checking to properly support C99 %j formats, GCC needs an internal notion of the intmax_t and uintmax_t types, meaning intmax_type_node and uintmax_type_node tree nodes for appropriate types specified in the target-specific headers. It also needs to communicate this information somehow to the tests c99-printf-1.c (which presently has XFAILs for the %j tests) and c90-printf-2.c (which presently has a generally incorrect definition of intmax_t but no XFAILSs). In general, GCC needs to be able to provide a <stdint.h> header, since this header is required by C99 for conforming freestanding implementations. See the thread starting at <URL:http://gcc.gnu.org/ml/gcc/2000-07/msg00142.html> for discussion of the associated issues. If GCC provides a <stdint.h>, then its inclusion in the relevant testcases seems a reasonable way of providing the definition without needing more special macros or typedefs. The thread starting at <URL:http://gcc.gnu.org/ml/gcc/2000-07/msg00504.html> shows significant controversy over whether GCC should install the headers required of freestanding implementations on all targets; in particular some targets have their own <stddef.h> and <limits.h> which can cause problems, although glibc knows what headers GCC provides and expects them to be provided by GCC (but at present has its own <stdint.h>). The mutual recursion between GCC's <limits.h> and glibc's <limits.h>, and the more general problems of interaction between <limits.h> headers to provide where appropriate the additional constants specified by POSIX but not by the C standard is very confusing and fragile. On some targets (e.g. aix64) the ABI can be changed by compiler options and the headers need to follow. The existing methods for this to work with <limits.h> are fragile; on the more unusual targets (e.g. c4x), GCC's <limits.h> is simply broken. Conclusion ========== GCC needs the mechanisms to provide correct <limits.h> and <stdint.h> headers for use with embedded targets and targets lacking those headers (especially <stdint.h>) in their C libraries. In some cases it might defer to the system headers if correct, but the ability to interact with system headers knowing what GCC provides on systems where GCC is the native compiler (e.g. glibc) also seems useful at present. Fragile conditionals in the headers to allow for ABI choices by compiler options seem a bad way to go ahead. A more promising approach might be to generate the headers for each multilib. The existing mechanisms could run a generation program for each set of multilib options used; I have some proof-of-concept shell scripts that will generate limits.h (treating the compiler plus options as a black box) and most of stdint.h could be created on the same basis (with hints possibly provided by the compiler, e.g. through preprocessor defines, where unusual choices of types are made and the types can't simply be deduced from existing system headers). Release: 2.96 Environment: System: Linux decomino 2.2.16 #1 Thu Jun 8 00:26:22 UTC 2000 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu
State-Changed-From-To: open->analyzed State-Changed-Why: Confirming my own PR. GCC now has an internal notion of intmax_t and uintmax_t, but no <stdint.h> header. The most recently suggested mechanism for a less fragile <limits.h>, which would also apply to this, would be to have an "enquire"-like program that generates sample <limits.h> and <stdint.h> headers for a given target, then include them in the distribution as with <float.h>. Where the sizes of types can vary on a target, either the target-specific header would need to contain appropriate (potentially fragile) conditionals, or appropriate variant headers would need to be installed in multilib directories.
From: jsm28@gcc.gnu.org To: gcc-gnats@gcc.gnu.org, jsm28@cam.ac.uk, nobody@gcc.gnu.org Cc: Subject: Re: c/448 Date: 3 Apr 2001 20:30:58 -0000 Synopsis: <stdint.h>-related issues State-Changed-From-To: open->analyzed State-Changed-By: jsm28 State-Changed-When: Tue Apr 3 16:30:58 2001 State-Changed-Why: Confirming my own PR. GCC now has an internal notion of intmax_t and uintmax_t, but no <stdint.h> header. The most recently suggested mechanism for a less fragile <limits.h>, which would also apply to this, would be to have an "enquire"-like program that generates sample <limits.h> and <stdint.h> headers for a given target, then include them in the distribution as with <float.h>. Where the sizes of types can vary on a target, either the target-specific header would need to contain appropriate (potentially fragile) conditionals, or appropriate variant headers would need to be installed in multilib directories. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=448&database=gcc
Subject: Re: stdint.h On Thu, 3 Jul 2003, Shaun Jackman wrote: > Why does gcc leave stdint.h for libc to provide? I'm looking at newlib > now, and am wondering if newlib should be modified to provide stdint.h, > or if gcc is the proper home for it (like stdbool.h and others). GCC should provide it. Now that cpp is fully integrated into cc1, this can work by defining lots of internal macros that a single system-independent <stdint.h> then uses, as for <limits.h> and <float.h>, so much of the discussion linked to from bug 448 is no longer applicable. [Note that I'm CC:ing gcc-bugzilla to track this discussion in that bug.] Note that GCC will need to acquire knowledge of what the target library's sig_atomic_t is, which previously wasn't necessary. (See also DR#248: some systems may not have a sig_atomic_t at all.) It will also need to know what types are chosen for various of the <stdint.h> types where there is a reasonable scope for choice and the target system library already has made its choices, including on systems such as Solaris with <inttypes.h> but not <stdint.h> (which may need fixincludes work). That GCC's choice of sig_atomic_t agrees with the system <signal.h> can be tested in the testsuite in the same manner as gcc.dg/wchar_t-1.c and gcc.dg/wint_t-1.c. For any <stdint.h> work, be sure to have TC1 to hand along with C99, as there were significant defects in the original specification.
For what it's worth some systems provide the functionality in a header with a different name. For example Solaris 8 provides a file <sys/int_types.h> and <sys/int_limits.h> that seem to define all of the types and constants of needed by <stdint.h>.
Subject: Re: <stdint.h>-related issues (C99 issues) On Mon, 2 Aug 2004, papadopo at shfj dot cea dot fr wrote: > For what it's worth some systems provide the functionality in a header with a > different name. For example Solaris 8 provides a file <sys/int_types.h> and > <sys/int_limits.h> that seem to define all of the types and constants of needed > by <stdint.h>. Those headers are included by Solaris's <inttypes.h>. An implementation of <stdint.h> in GCC of course needs to be compatible with such pre-C99 system libraries providing <inttypes.h> but not <stdint.h>, and allow for user programs to include both, probably by fixincluding <inttypes.h> to use GCC's header rather than the internal ones. See <http://gcc.gnu.org/ml/gcc/2003-10/msg00397.html> for my current thinking on the implementation of <stdint.h>. The volunteer in that instance seems to have disappeared.
My suggestion on how to implement this is to have stdint.h essentially contain a single line, #pragma GNUC stdint which defines the typedefs based on information in the machine description. That information doesn't exist yet, so you'd have to add it, with suitable defaults computed from the sizes of the types (perhaps using the same algorithm that __attribute__((mode)) uses. The information has to match the system's idea from inttypes.h, including such details as 'long' vs. 'int' even if they are both the same size. On some systems, the same types can be defined in other headers, so the #pragma would need to only define a particular type if it hasn't been defined already. You could theoretically do this with a huge collection of preprocessor macros, like stddef.h or limits.h, but this would be pretty painful, so don't. A good testcase is to use -Wall and check that all the PRI* and SCN* macros from inttypes.h don't produce warnings when used in scanf and printf with the correct type.
Subject: Re: <stdint.h>-related issues (C99 issues) On Thu, 19 Aug 2004, geoffk at gcc dot gnu dot org wrote: > which defines the typedefs based on information in the machine > description. That information doesn't exist yet, so you'd have to add > it, with suitable defaults computed from the sizes of the types (perhaps > using the same algorithm that __attribute__((mode)) uses. The > information has to match the system's idea from inttypes.h, including > such details as 'long' vs. 'int' even if they are both the same size. You will, in any case, need lots of target macros to allow for the defaults to be overridden. The logic isn't currently present to get the type of the macros for type limits such as UINT16_MAX correct (when an unsigned type has a limit of type int because the type promotes to int), but this is easy to do. (At present that logic for USHRT_MAX and UCHAR_MAX is in <limits.h>.) The INTN_C, INTMAX_C macros also need to be defined (to concatenate an appropriate suffix). Note the footnotes about __STDC_LIMIT_MACROS, __STDC_CONSTANT_MACROS and C++. > On some systems, the same types can be defined in other headers, so the > #pragma would need to only define a particular type if it hasn't been > defined already. Equally, other headers may want to redefine the types later. Either you make sure duplication is OK for both C and C++ or you interoperate with the existing systems used in system headers. For example, current glibc uses /* There is some amount of overlap with <sys/types.h> as known by inet code */ #ifndef __int8_t_defined # define __int8_t_defined typedef signed char int8_t; ... whereas older glibc used in some places a convention of the form # ifndef intptr_t typedef long int intptr_t; ... You should arrange for error messages mentioning definitions from the pragma to give the line number of the #pragma in <stdint.h> as the line number of both the typedefs and the macro definitions, to avoid making this approach too confusing.
The Fortran people are interested in this. For full F2003 support, we need the Fortran front-end to know during code generation which integer mode correspond to certain C integer types, including the int_fastN_t, intmax_t and size_t types.
C++ folks also. Note that GCC_HEADER_STDINT(gstdint.h) solution is used by: libgomp libgfortran libdecnumber and soon by libstdc++. This does use the native stdint.h when possible. I'm with Geoff in that another stddef.h macro-nest is to be avoided. That file is ridiculous.
GCC allows duplicate typedefs in system headers, which should simplify this header a bit. See http://gcc.gnu.org/ml/gcc/2008-03/msg00558.html for the latest partial attempt at giving the compiler knowledge of these types, and my followups on how to handle OSes where GCC lacks knowledge of the types but the OS might have some or all (don't provide the header), OSes where a newer version has the types (take the types from the newer version) and unmaintained OSes or OSes that otherwise won't be updated to have these types themselves (only in that case make a GCC-local choice of types).
When GCC knows about these types on a target, CHAR16_TYPE and CHAR32_TYPE should be defined to be the same as uint_least16_t and uint_least32_t.
Subject: Bug 448 Author: jsm28 Date: Sat Nov 8 00:14:26 2008 New Revision: 141697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141697 Log: PR c/448 fixincludes: * inclhack.def (newlib_stdint_1, newlib_stdint_2): New fixes. * fixincl.x: Regenerate. * tests/base/stdint.h: Update. gcc: * Makefile.in (USE_GCC_STDINT): Define. (stmp-int-hdrs): Install stdint.h if applicable. * c-common.c (CHAR16_TYPE): Define in terms of UINT_LEAST16_TYPE if known. (CHAR32_TYPE): Define in terms of UINT_LEAST32_TYPE if known. (SIG_ATOMIC_TYPE, INT8_TYPE, INT16_TYPE, INT32_TYPE, INT64_TYPE, UINT8_TYPE, UINT16_TYPE, UINT32_TYPE, UINT64_TYPE, INT_LEAST8_TYPE, INT_LEAST16_TYPE, INT_LEAST32_TYPE, INT_LEAST64_TYPE, UINT_LEAST8_TYPE, UINT_LEAST16_TYPE, UINT_LEAST32_TYPE, UINT_LEAST64_TYPE, INT_FAST8_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST8_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Define. (c_common_nodes_and_builtins): Initialize underlying_wchar_type_node. Do not initialize signed_wchar_type_node or unsigned_wchar_type_node. Initialize nodes for new types. (c_stddef_cpp_builtins): Define macros for new types. * c-common.h (CTI_SIGNED_WCHAR_TYPE, CTI_UNSIGNED_WCHAR_TYPE): Remove. (CTI_UNDERLYING_WCHAR_TYPE, CTI_SIG_ATOMIC_TYPE, CTI_INT8_TYPE, CTI_INT16_TYPE, CTI_INT32_TYPE, CTI_INT64_TYPE, CTI_UINT8_TYPE, CTI_UINT16_TYPE, CTI_UINT32_TYPE, CTI_UINT64_TYPE, CTI_INT_LEAST8_TYPE, CTI_INT_LEAST16_TYPE, CTI_INT_LEAST32_TYPE, CTI_INT_LEAST64_TYPE, CTI_UINT_LEAST8_TYPE, CTI_UINT_LEAST16_TYPE, CTI_UINT_LEAST32_TYPE, CTI_UINT_LEAST64_TYPE, CTI_INT_FAST8_TYPE, CTI_INT_FAST16_TYPE, CTI_INT_FAST32_TYPE, CTI_INT_FAST64_TYPE, CTI_UINT_FAST8_TYPE, CTI_UINT_FAST16_TYPE, CTI_UINT_FAST32_TYPE, CTI_UINT_FAST64_TYPE, CTI_INTPTR_TYPE, CTI_UINTPTR_TYPE): Define. (signed_wchar_type_node, unsigned_wchar_type_node): Remove. (underlying_wchar_type_node, sig_atomic_type_node, int8_type_node, int16_type_node, int32_type_node, int64_type_node, uint8_type_node, uint16_type_node, c_uint32_type_node, c_uint64_type_node, int_least8_type_node, int_least16_type_node, int_least32_type_node, int_least64_type_node, uint_least8_type_node, uint_least16_type_node, uint_least32_type_node, uint_least64_type_node, int_fast8_type_node, int_fast16_type_node, int_fast32_type_node, int_fast64_type_node, uint_fast8_type_node, uint_fast16_type_node, uint_fast32_type_node, uint_fast64_type_node, intptr_type_node, uintptr_type_node): Define. * c-cppbuiltin.c (builtin_define_constants, builtin_define_type_minmax): New. (builtin_define_stdint_macros): Define more macros. (c_cpp_builtins): Define more limit macros. (type_suffix): New. (builtin_define_type_max): Define in terms of builtin_define_type_minmax. Remove is_long parameter. All callers changed. * config.gcc (use_gcc_stdint): Define. (tm_file): Add glibc-stdint.h for targets using glibc or uClibc. Add newlib-stdint.h for generic targets. * config/glibc-stdint.h, config/newlib-stdint.h, ginclude/stdint-gcc.h, ginclude/stdint-wrap.h: New. * config/m32c/m32c.h (UINTPTR_TYPE): Define. * config/score/score.h (UINTPTR_TYPE): Define. * config/sol2.h (SIG_ATOMIC_TYPE, INT8_TYPE, INT16_TYPE, INT32_TYPE, INT64_TYPE, UINT8_TYPE, UINT16_TYPE, UINT32_TYPE, UINT64_TYPE, INT_LEAST8_TYPE, INT_LEAST16_TYPE, INT_LEAST32_TYPE, INT_LEAST64_TYPE, UINT_LEAST8_TYPE, UINT_LEAST16_TYPE, UINT_LEAST32_TYPE, UINT_LEAST64_TYPE, INT_FAST8_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST8_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Define. * config/spu/spu.h (STDINT_LONG32): Define. * configure.ac (use_gcc_stdint): Substitute. * configure: Regenerate. * doc/cpp.texi (__SIG_ATOMIC_TYPE__, __INT8_TYPE__, __INT16_TYPE__, __INT32_TYPE__, __INT64_TYPE__, __UINT8_TYPE__, __UINT16_TYPE__, __UINT32_TYPE__, __UINT64_TYPE__, __INT_LEAST8_TYPE__, __INT_LEAST16_TYPE__, __INT_LEAST32_TYPE__, __INT_LEAST64_TYPE__, __UINT_LEAST8_TYPE__, __UINT_LEAST16_TYPE__, __UINT_LEAST32_TYPE_, __UINT_LEAST64_TYPE__, __INT_FAST8_TYPE__, __INT_FAST16_TYPE__, __INT_FAST32_TYPE__, __INT_FAST64_TYPE__, __UINT_FAST8_TYPE__, __UINT_FAST16_TYPE__, __UINT_FAST32_TYPE__, __UINT_FAST64_TYPE__, __INTPTR_TYPE__, __UINTPTR_TYPE__, __WINT_MAX__, __SIZE_MAX__, __PTRDIFF_MAX__, __UINTMAX_MAX__, __SIG_ATOMIC_MAX__, __INT8_MAX__, __INT16_MAX__, __INT32_MAX__, __INT64_MAX__, __UINT8_MAX__, __UINT16_MAX__, __UINT32_MAX__, __UINT64_MAX__, __INT_LEAST8_MAX__, __INT_LEAST16_MAX__, __INT_LEAST32_MAX__, __INT_LEAST64_MAX__, __UINT_LEAST8_MAX__, __UINT_LEAST16_MAX__, __UINT_LEAST32_MAX__, __UINT_LEAST64_MAX__, __INT_FAST8_MAX__, __INT_FAST16_MAX__, __INT_FAST32_MAX__, __INT_FAST64_MAX__, __UINT_FAST8_MAX__, __UINT_FAST16_MAX__, __UINT_FAST32_MAX__, __UINT_FAST64_MAX__, __INTPTR_MAX__, __UINTPTR_MAX__, __WCHAR_MIN__, __WINT_MIN__, __SIG_ATOMIC_MIN__, __INT8_C, __INT16_C, __INT32_C, __INT64_C, __UINT8_C, __UINT16_C, __UINT32_C, __UINT64_C, __INTMAX_C, __UINTMAX_C): Document. * doc/tm.texi (SIG_ATOMIC_TYPE, INT8_TYPE, INT16_TYPE, INT32_TYPE, INT64_TYPE, UINT8_TYPE, UINT16_TYPE, UINT32_TYPE, UINT64_TYPE, INT_LEAST8_TYPE, INT_LEAST16_TYPE, INT_LEAST32_TYPE, INT_LEAST64_TYPE, UINT_LEAST8_TYPE, UINT_LEAST16_TYPE, UINT_LEAST32_TYPE, UINT_LEAST64_TYPE, INT_FAST8_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST8_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Document. gcc/testsuite: * lib/target-supports.exp (check_effective_target_stdint_types): Update comment. (check_effective_target_inttypes_types): New. * gcc.dg/c99-stdint-1.c, gcc.dg/c99-stdint-2.c, gcc.dg/c99-stdint-3.c, gcc.dg/c99-stdint-4.c, gcc.dg/c99-stdint-5.c, gcc.dg/c99-stdint-6.c: New tests. Added: branches/c-4_5-branch/gcc/config/glibc-stdint.h branches/c-4_5-branch/gcc/config/newlib-stdint.h branches/c-4_5-branch/gcc/ginclude/stdint-gcc.h branches/c-4_5-branch/gcc/ginclude/stdint-wrap.h branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-stdint-1.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-stdint-2.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-stdint-3.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-stdint-4.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-stdint-5.c branches/c-4_5-branch/gcc/testsuite/gcc.dg/c99-stdint-6.c Modified: branches/c-4_5-branch/fixincludes/ChangeLog.c45 branches/c-4_5-branch/fixincludes/fixincl.x branches/c-4_5-branch/fixincludes/inclhack.def branches/c-4_5-branch/fixincludes/tests/base/stdint.h branches/c-4_5-branch/gcc/ChangeLog.c45 branches/c-4_5-branch/gcc/Makefile.in branches/c-4_5-branch/gcc/c-common.c branches/c-4_5-branch/gcc/c-common.h branches/c-4_5-branch/gcc/c-cppbuiltin.c branches/c-4_5-branch/gcc/config.gcc branches/c-4_5-branch/gcc/config/m32c/m32c.h branches/c-4_5-branch/gcc/config/score/score.h branches/c-4_5-branch/gcc/config/sol2.h branches/c-4_5-branch/gcc/config/spu/spu.h branches/c-4_5-branch/gcc/configure branches/c-4_5-branch/gcc/configure.ac branches/c-4_5-branch/gcc/doc/cpp.texi branches/c-4_5-branch/gcc/doc/tm.texi branches/c-4_5-branch/gcc/testsuite/ChangeLog.c45 branches/c-4_5-branch/gcc/testsuite/lib/target-supports.exp
Subject: Bug 448 Author: jsm28 Date: Tue Mar 31 20:30:31 2009 New Revision: 145372 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145372 Log: PR c/448 fixincludes: * inclhack.def (newlib_stdint_1, newlib_stdint_2): New fixes. * fixincl.x: Regenerate. * tests/base/stdint.h: Update. gcc: * Makefile.in (USE_GCC_STDINT): Define. (stmp-int-hdrs): Install stdint.h if applicable. * c-common.c (CHAR16_TYPE): Define in terms of UINT_LEAST16_TYPE if known. (CHAR32_TYPE): Define in terms of UINT_LEAST32_TYPE if known. (SIG_ATOMIC_TYPE, INT8_TYPE, INT16_TYPE, INT32_TYPE, INT64_TYPE, UINT8_TYPE, UINT16_TYPE, UINT32_TYPE, UINT64_TYPE, INT_LEAST8_TYPE, INT_LEAST16_TYPE, INT_LEAST32_TYPE, INT_LEAST64_TYPE, UINT_LEAST8_TYPE, UINT_LEAST16_TYPE, UINT_LEAST32_TYPE, UINT_LEAST64_TYPE, INT_FAST8_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST8_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Define. (c_common_nodes_and_builtins): Initialize underlying_wchar_type_node. Do not initialize signed_wchar_type_node or unsigned_wchar_type_node. Initialize nodes for new types. (c_stddef_cpp_builtins): Define macros for new types. * c-common.h (CTI_SIGNED_WCHAR_TYPE, CTI_UNSIGNED_WCHAR_TYPE): Remove. (CTI_UNDERLYING_WCHAR_TYPE, CTI_SIG_ATOMIC_TYPE, CTI_INT8_TYPE, CTI_INT16_TYPE, CTI_INT32_TYPE, CTI_INT64_TYPE, CTI_UINT8_TYPE, CTI_UINT16_TYPE, CTI_UINT32_TYPE, CTI_UINT64_TYPE, CTI_INT_LEAST8_TYPE, CTI_INT_LEAST16_TYPE, CTI_INT_LEAST32_TYPE, CTI_INT_LEAST64_TYPE, CTI_UINT_LEAST8_TYPE, CTI_UINT_LEAST16_TYPE, CTI_UINT_LEAST32_TYPE, CTI_UINT_LEAST64_TYPE, CTI_INT_FAST8_TYPE, CTI_INT_FAST16_TYPE, CTI_INT_FAST32_TYPE, CTI_INT_FAST64_TYPE, CTI_UINT_FAST8_TYPE, CTI_UINT_FAST16_TYPE, CTI_UINT_FAST32_TYPE, CTI_UINT_FAST64_TYPE, CTI_INTPTR_TYPE, CTI_UINTPTR_TYPE): Define. (signed_wchar_type_node, unsigned_wchar_type_node): Remove. (underlying_wchar_type_node, sig_atomic_type_node, int8_type_node, int16_type_node, int32_type_node, int64_type_node, uint8_type_node, uint16_type_node, c_uint32_type_node, c_uint64_type_node, int_least8_type_node, int_least16_type_node, int_least32_type_node, int_least64_type_node, uint_least8_type_node, uint_least16_type_node, uint_least32_type_node, uint_least64_type_node, int_fast8_type_node, int_fast16_type_node, int_fast32_type_node, int_fast64_type_node, uint_fast8_type_node, uint_fast16_type_node, uint_fast32_type_node, uint_fast64_type_node, intptr_type_node, uintptr_type_node): Define. * c-cppbuiltin.c (builtin_define_constants, builtin_define_type_minmax): New. (builtin_define_stdint_macros): Define more macros. (c_cpp_builtins): Define more limit macros. (type_suffix): New. (builtin_define_type_max): Define in terms of builtin_define_type_minmax. Remove is_long parameter. All callers changed. * config.gcc (use_gcc_stdint): Define. (tm_file): Add glibc-stdint.h for targets using glibc or uClibc. Add newlib-stdint.h for generic targets. * config/glibc-stdint.h, config/newlib-stdint.h, ginclude/stdint-gcc.h, ginclude/stdint-wrap.h: New. * config/m32c/m32c.h (UINTPTR_TYPE): Define. * config/score/score.h (UINTPTR_TYPE): Define. * config/sol2.h (SIG_ATOMIC_TYPE, INT8_TYPE, INT16_TYPE, INT32_TYPE, INT64_TYPE, UINT8_TYPE, UINT16_TYPE, UINT32_TYPE, UINT64_TYPE, INT_LEAST8_TYPE, INT_LEAST16_TYPE, INT_LEAST32_TYPE, INT_LEAST64_TYPE, UINT_LEAST8_TYPE, UINT_LEAST16_TYPE, UINT_LEAST32_TYPE, UINT_LEAST64_TYPE, INT_FAST8_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST8_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Define. * config/spu/spu.h (STDINT_LONG32): Define. * configure.ac (use_gcc_stdint): Substitute. * configure: Regenerate. * doc/cpp.texi (__SIG_ATOMIC_TYPE__, __INT8_TYPE__, __INT16_TYPE__, __INT32_TYPE__, __INT64_TYPE__, __UINT8_TYPE__, __UINT16_TYPE__, __UINT32_TYPE__, __UINT64_TYPE__, __INT_LEAST8_TYPE__, __INT_LEAST16_TYPE__, __INT_LEAST32_TYPE__, __INT_LEAST64_TYPE__, __UINT_LEAST8_TYPE__, __UINT_LEAST16_TYPE__, __UINT_LEAST32_TYPE_, __UINT_LEAST64_TYPE__, __INT_FAST8_TYPE__, __INT_FAST16_TYPE__, __INT_FAST32_TYPE__, __INT_FAST64_TYPE__, __UINT_FAST8_TYPE__, __UINT_FAST16_TYPE__, __UINT_FAST32_TYPE__, __UINT_FAST64_TYPE__, __INTPTR_TYPE__, __UINTPTR_TYPE__, __WINT_MAX__, __SIZE_MAX__, __PTRDIFF_MAX__, __UINTMAX_MAX__, __SIG_ATOMIC_MAX__, __INT8_MAX__, __INT16_MAX__, __INT32_MAX__, __INT64_MAX__, __UINT8_MAX__, __UINT16_MAX__, __UINT32_MAX__, __UINT64_MAX__, __INT_LEAST8_MAX__, __INT_LEAST16_MAX__, __INT_LEAST32_MAX__, __INT_LEAST64_MAX__, __UINT_LEAST8_MAX__, __UINT_LEAST16_MAX__, __UINT_LEAST32_MAX__, __UINT_LEAST64_MAX__, __INT_FAST8_MAX__, __INT_FAST16_MAX__, __INT_FAST32_MAX__, __INT_FAST64_MAX__, __UINT_FAST8_MAX__, __UINT_FAST16_MAX__, __UINT_FAST32_MAX__, __UINT_FAST64_MAX__, __INTPTR_MAX__, __UINTPTR_MAX__, __WCHAR_MIN__, __WINT_MIN__, __SIG_ATOMIC_MIN__, __INT8_C, __INT16_C, __INT32_C, __INT64_C, __UINT8_C, __UINT16_C, __UINT32_C, __UINT64_C, __INTMAX_C, __UINTMAX_C): Document. * doc/tm.texi (SIG_ATOMIC_TYPE, INT8_TYPE, INT16_TYPE, INT32_TYPE, INT64_TYPE, UINT8_TYPE, UINT16_TYPE, UINT32_TYPE, UINT64_TYPE, INT_LEAST8_TYPE, INT_LEAST16_TYPE, INT_LEAST32_TYPE, INT_LEAST64_TYPE, UINT_LEAST8_TYPE, UINT_LEAST16_TYPE, UINT_LEAST32_TYPE, UINT_LEAST64_TYPE, INT_FAST8_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST8_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Document. gcc/testsuite: * lib/target-supports.exp (check_effective_target_stdint_types): Update comment. (check_effective_target_inttypes_types): New. * gcc.dg/c99-stdint-1.c, gcc.dg/c99-stdint-2.c, gcc.dg/c99-stdint-3.c, gcc.dg/c99-stdint-4.c, gcc.dg/c99-stdint-5.c, gcc.dg/c99-stdint-6.c: New tests. Added: trunk/gcc/config/glibc-stdint.h trunk/gcc/config/newlib-stdint.h trunk/gcc/ginclude/stdint-gcc.h trunk/gcc/ginclude/stdint-wrap.h trunk/gcc/testsuite/gcc.dg/c99-stdint-1.c trunk/gcc/testsuite/gcc.dg/c99-stdint-2.c trunk/gcc/testsuite/gcc.dg/c99-stdint-3.c trunk/gcc/testsuite/gcc.dg/c99-stdint-4.c trunk/gcc/testsuite/gcc.dg/c99-stdint-5.c trunk/gcc/testsuite/gcc.dg/c99-stdint-6.c Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def trunk/fixincludes/tests/base/stdint.h trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-cppbuiltin.c trunk/gcc/config.gcc trunk/gcc/config/m32c/m32c.h trunk/gcc/config/score/score.h trunk/gcc/config/sol2.h trunk/gcc/config/spu/spu.h trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/cpp.texi trunk/gcc/doc/tm.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
Note that the patch committed does not completely fix the issue; work is needed for each target to tell GCC about the types on that target, and the patch only does that for glibc/uClibc, newlib and Solaris.
On *-darwin* we have FAIL: gcc.dg/c99-stdint-1.c (test for excess errors) FAIL: gcc.dg/c99-stdint-2.c (test for excess errors) FAIL: gcc.dg/c99-stdint-5.c (test for excess errors) FAIL: gcc.dg/c99-stdint-6.c (test for excess errors) see http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00037.html Errors for 99-stdint-[12].c: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function 'test_ptr': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error: initialization from incompatible pointer type /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error: initialization from incompatible pointer type /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:189: error: initialization from incompatible pointer type /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function 'test_misc_limits': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:217: error: initialization from incompatible pointer type /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function 'test_constants': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer targets in initialization differ in signedness /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer targets in initialization differ in signedness /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer targets in initialization differ in signedness /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer targets in initialization differ in signedness /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer targets in initialization differ in signedness /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer targets in initialization differ in signedness and for c99-stdint-[56].c: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c: In function 'check_types': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:40: error: '__INT_LEAST8_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:40: error: (Each undeclared identifier is reported only once /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:40: error: for each function it appears in.) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:40: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:40: error: 'a' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:40: error: 'd' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:41: error: '__INT_LEAST16_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:41: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:42: error: '__INT_LEAST32_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:42: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:43: error: '__INT_LEAST64_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:43: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:44: error: '__UINT_LEAST8_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:44: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:45: error: '__UINT_LEAST16_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:45: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:46: error: '__UINT_LEAST32_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:46: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:47: error: '__UINT_LEAST64_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:47: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:48: error: '__INT_FAST8_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:48: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:49: error: '__INT_FAST16_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:49: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:50: error: '__INT_FAST32_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:50: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:51: error: '__INT_FAST64_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:51: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:52: error: '__UINT_FAST8_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:52: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:53: error: '__UINT_FAST16_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:53: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:54: error: '__UINT_FAST32_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:54: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:55: error: '__UINT_FAST64_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:55: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:64: error: '__SIG_ATOMIC_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-5.c:64: error: expected ';' before 'a' or ... /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:49: error: '__INT_FAST8_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:49: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:50: error: '__INT_FAST16_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:50: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:51: error: '__INT_FAST32_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:51: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:52: error: '__INT_FAST64_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:52: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:53: error: '__UINT_FAST8_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:53: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:54: error: '__UINT_FAST16_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:54: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:55: error: '__UINT_FAST32_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:55: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:56: error: '__UINT_FAST64_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:56: error: expected ';' before 'a' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:66: error: '__SIG_ATOMIC_TYPE__' undeclared (first use in this function) /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-6.c:66: error: expected ';' before 'a'
Subject: Re: <stdint.h>-related issues (C99 issues) On Wed, 1 Apr 2009, dominiq at lps dot ens dot fr wrote: > On *-darwin* we have > > FAIL: gcc.dg/c99-stdint-1.c (test for excess errors) > FAIL: gcc.dg/c99-stdint-2.c (test for excess errors) > FAIL: gcc.dg/c99-stdint-5.c (test for excess errors) > FAIL: gcc.dg/c99-stdint-6.c (test for excess errors) Errors are expected until someone adds the relevant type information for Darwin to GCC and fixes any bugs in its system stdint.h. > Errors for 99-stdint-[12].c: > > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function > 'test_ptr': > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error: > initialization from incompatible pointer type > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error: > initialization from incompatible pointer type > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:189: error: > initialization from incompatible pointer type This means there is something wrong with the definitions of intptr_t, uintptr_t and their limits in the system stdint.h. It can be fixed in GCC with fixincludes, but should also be reported upstream. > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function > 'test_misc_limits': > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:217: error: > initialization from incompatible pointer type Either the size_t limits are wrong or GCC disagrees with the system on what type size_t should be. > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function > 'test_constants': > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer > targets in initialization differ in signedness > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer > targets in initialization differ in signedness > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer > targets in initialization differ in signedness > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer > targets in initialization differ in signedness > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer > targets in initialization differ in signedness > /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer > targets in initialization differ in signedness The Darwin header wrongly uses unsigned types for the results of UINT8_C and UINT16_C. Report the bug upstream (with reference to C99 TC1), fix with fixincludes. > and for c99-stdint-[56].c: These will fail until GCC knows internally what the types are.
Adding the libstdc++ regressions I've seen as a dependent, see PR39644 comment #23. (That is, the PR448 solution in progress relies on newlib providing the missing INTPTR_MAX, INTPTR_MIN and UINTPTR_MAX which it doesn't do - yet.)
Subject: Re: <stdint.h>-related issues (C99 issues) On Wed, 8 Apr 2009, hp at gcc dot gnu dot org wrote: > Adding the libstdc++ regressions I've seen as a dependent, see PR39644 comment > #23. > (That is, the PR448 solution in progress relies on newlib providing the missing > INTPTR_MAX, INTPTR_MIN and UINTPTR_MAX which it doesn't do - yet.) Thanks for pointing this out - the intptr_t and uintptr_t types are optional, but the limits are required if the types are provided. I'll look at adding extra testcases verifying that GCC and the header agree on whether the limits are available. Someone should also fix newlib upstream to provide the limits and add appropriate fixincludes to GCC to fix older newlib headers.
(In reply to comment #18) > Someone should also fix newlib upstream > to provide the limits See <http://sourceware.org/ml/newlib/2009/msg00451.html>.
I'm wondering if there is something we can/should do here about C++1x: in the new Standard (see 18.4.1/2 in n2914, for example), for <cstdint> we have: The header defines all functions, types, and macros the same as C99 7.18. [ Note: The macros defined by <cstdint> are provided unconditionally. In particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. 容nd note ] and since the implementation of <cstdint> can, conformingly, include <stdint.h> and do little more, I would guess a little of support in <stdint.h> to its C++ uses would make the life of the implementors *much* easier... For the record, at the moment we are just defining the macros as part of <cstdint>, at the top, before including <stdint.h>, but of course the solution isn't too good, it breaks immediately if the user code for some reason includes <stdint.h> before <cstdint> without defining the macros.
Subject: Re: <stdint.h>-related issues (C99 issues) On Fri, 31 Jul 2009, paolo dot carlini at oracle dot com wrote: > I'm wondering if there is something we can/should do here about C++1x: in the > new Standard (see 18.4.1/2 in n2914, for example), for <cstdint> we have: > > The header defines all functions, types, and macros the same as C99 7.18. [ > Note: The macros defined by <cstdint> are provided unconditionally. In > particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS > (mentioned in C99 footnotes 219, 220, and 222) play no role in C++. end note ] I would suggest predefining those macros in C++1x mode; that should make things work with all existing stdint.h implementations that care about those macros. If you need help beyond that - for example, to ensure that each of <stdint.h> and <cstdint> puts things in the right namespaces - then stdint-gcc.h could certainly be adjusted to know about C++ requirements, but systems with their own stdint.h generally only use stdint-gcc.h for freestanding compilations so further help from libc implementors may be needed.
Note, in C++1x, those macros should be effectively predefined *only* when <cstdint> is included, not when <stdint.h> is included. Thus, I agree - note I'm not completely sure to get all your points - for those targets such as GCC just uses the system provided <stdint.h>, I agree GCC probably can't do much...
Subject: Re: <stdint.h>-related issues (C99 issues) On Fri, 31 Jul 2009, paolo dot carlini at oracle dot com wrote: > Note, in C++1x, those macros should be effectively predefined *only* when > <cstdint> is included, not when <stdint.h> is included. Thus, I agree - note That's not how I read N2914; it appears to say <stdint.h> is a strict superset of <cstdint>.
Oops, now I understand, was overlooking 18.4.2. Great. Thus we could just arrange for those feature macros to be automagically defined when -std=c++0x (gnu++0x). Do we have already have something similar elsewhere? I can prepare a patch. I'm still not completely sure that solution makes for a perfect implementation (what happens if the user code explicitly undefines the macros?) but it would be a progress. Then, eventually, <stdint.h> will just have to support those C++1x uses, by ignoring the value of the feature macros when C++1x and providing the macros unconditionally.
Something like this should be enough, barring objections, I'll polish it, add a testcase and submit it. Index: c-cppbuiltin.c =================================================================== --- c-cppbuiltin.c (revision 150315) +++ c-cppbuiltin.c (working copy) @@ -561,7 +561,15 @@ if (flag_rtti) cpp_define (pfile, "__GXX_RTTI"); if (cxx_dialect == cxx0x) - cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__"); + { + cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__"); + /* Note that this is a temporary solution: eventually the + <stdint.h> and <inttypes.h> headers will have to know about + C++0x mode and provide the macros unconditionally. */ + cpp_define (pfile, "__STDC_LIMIT_MACROS"); + cpp_define (pfile, "__STDC_CONSTANT_MACROS"); + cpp_define (pfile, "__STDC_FORMAT_MACROS"); + } } /* Note that we define this for C as well, so that we know if __attribute__((cleanup)) will interface with EH. */
List of remaining target OSes without stdint.h type information added to 4.5 release notes: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00441.html NetBSD, VxWorks, VMS, SymbianOS, WinCE, LynxOS, Netware, QNX, Interix, IRIX, TPF.
Hi, Is the following page up to date? http://gcc.gnu.org/c99status.html
Subject: Re: <stdint.h>-related issues (C99 issues) On Sun, 27 Dec 2009, laurent at guerby dot net wrote: > Is the following page up to date? > > http://gcc.gnu.org/c99status.html The table appears to be up to date. The note about bug 30789 should be removed and the note about math_errhandling updated to indicate that glibc now has such more limited math_errhandling implementation as can be done without compiler support (see glibc's CONFORMANCE file for details).
Subject: Re: <stdint.h>-related issues (C99 issues) Actually, the Broken marker for complex numbers support should now be Done, as per what I said in <http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00460.html>.
Is anything still outstanding here or can the bug be resolved as fixed?
The following targets still appear to be missing this type information in GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), VxWorks, SymbianOS, LynxOS, QNX, TPF. Others have either been fixed, or obsoleted and removed.
Thanks. I wonder if the incomplete support on those targets should be handled as separate bug reports raised by users if/when they run into problems. That way this large bug could be closed as resolved. Would that work for you?
I think it's appropriate for this bug to track the missing pieces, whether directly or through dependencies on a series of bugs for each target OS.
A __typeof__-Problem on s390x: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358