Bug 448 - <stdint.h>-related issues (C99 issues)
Summary: <stdint.h>-related issues (C99 issues)
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 2.96
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 16989 14325 24107 35915 39644
  Show dependency treegraph
 
Reported: 2000-08-07 07:46 UTC by Joseph S. Myers
Modified: 2014-06-08 16:36 UTC (History)
5 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2008-04-15 19:37:34


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph S. Myers 2000-08-07 07:46:01 UTC
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
Comment 1 Joseph S. Myers 2001-04-03 16:30:58 UTC
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.
Comment 2 Joseph S. Myers 2001-04-03 20:30:58 UTC
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
Comment 3 Joseph S. Myers 2003-07-03 19:05:42 UTC
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.

Comment 4 papadopo 2004-08-02 12:14:50 UTC
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>.
Comment 5 Joseph S. Myers 2004-08-02 16:33:13 UTC
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.

Comment 6 Geoff Keating 2004-08-19 22:12:13 UTC
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.
Comment 7 Joseph S. Myers 2004-08-19 22:26:59 UTC
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.

Comment 8 Francois-Xavier Coudert 2006-10-18 12:31:30 UTC
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.
Comment 9 Benjamin Kosnik 2008-04-15 19:37:34 UTC
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.
Comment 10 Joseph S. Myers 2008-04-15 19:44:42 UTC
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).
Comment 11 Joseph S. Myers 2008-04-18 14:15:20 UTC
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.
Comment 12 Joseph S. Myers 2008-11-08 00:15:46 UTC
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

Comment 13 Joseph S. Myers 2009-03-31 20:31:11 UTC
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

Comment 14 Joseph S. Myers 2009-03-31 20:33:15 UTC
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.
Comment 15 Dominique d'Humieres 2009-04-01 13:25:15 UTC
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'

Comment 16 joseph@codesourcery.com 2009-04-01 14:26:40 UTC
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.

Comment 17 Hans-Peter Nilsson 2009-04-08 06:55:02 UTC
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.)
Comment 18 joseph@codesourcery.com 2009-04-08 15:49:39 UTC
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.

Comment 19 Hans-Peter Nilsson 2009-04-08 20:05:10 UTC
(In reply to comment #18)
> Someone should also fix newlib upstream 
> to provide the limits

See <http://sourceware.org/ml/newlib/2009/msg00451.html>.
Comment 20 Paolo Carlini 2009-07-31 12:40:56 UTC
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.
Comment 21 joseph@codesourcery.com 2009-07-31 12:54:37 UTC
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.

Comment 22 Paolo Carlini 2009-07-31 13:04:40 UTC
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...
Comment 23 joseph@codesourcery.com 2009-07-31 13:09:57 UTC
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>.

Comment 24 Paolo Carlini 2009-07-31 13:14:57 UTC
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.
Comment 25 Paolo Carlini 2009-07-31 13:57:17 UTC
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.  */
Comment 26 Joseph S. Myers 2009-12-08 17:08:41 UTC
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.
Comment 27 Laurent GUERBY 2009-12-27 13:37:44 UTC
Hi,

Is the following page up to date?

http://gcc.gnu.org/c99status.html
Comment 28 joseph@codesourcery.com 2009-12-27 18:33:32 UTC
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).

Comment 29 joseph@codesourcery.com 2009-12-27 18:37:42 UTC
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>.