[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #27 from laurent at guerby dot net 2009-12-27 13:37 --- Hi, Is the following page up to date? http://gcc.gnu.org/c99status.html -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #28 from joseph at codesourcery dot com 2009-12-27 18:33 --- 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). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #29 from joseph at codesourcery dot com 2009-12-27 18:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #26 from jsm28 at gcc dot gnu dot org 2009-12-08 17:08 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #20 from paolo dot carlini at oracle dot com 2009-07-31 12:40 --- 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 ] 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. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #21 from joseph at codesourcery dot com 2009-07-31 12:54 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #22 from paolo dot carlini at oracle dot com 2009-07-31 13:04 --- 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... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #23 from joseph at codesourcery dot com 2009-07-31 13:09 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #24 from paolo dot carlini at oracle dot com 2009-07-31 13:14 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #25 from paolo dot carlini at oracle dot com 2009-07-31 13:57
---
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. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #17 from hp at gcc dot gnu dot org 2009-04-08 06:55 --- 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.) -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org OtherBugsDependingO||39644 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #18 from joseph at codesourcery dot com 2009-04-08 15:49 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #19 from hp at gcc dot gnu dot org 2009-04-08 20:05 --- (In reply to comment #18) Someone should also fix newlib upstream to provide the limits See http://sourceware.org/ml/newlib/2009/msg00451.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #15 from dominiq at lps dot ens dot fr 2009-04-01 13:25 --- 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)
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #16 from joseph at codesourcery dot com 2009-04-01 14:26 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #13 from jsm28 at gcc dot gnu dot org 2009-03-31 20:31 --- Subject: Bug 448 Author: jsm28 Date: Tue Mar 31 20:30:31 2009 New Revision: 145372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=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__,
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #14 from jsm28 at gcc dot gnu dot org 2009-03-31 20:33 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #12 from jsm28 at gcc dot gnu dot org 2008-11-08 00:15 --- Subject: Bug 448 Author: jsm28 Date: Sat Nov 8 00:14:26 2008 New Revision: 141697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=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__,
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-04-18 14:15 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-15 19:37 --- 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. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-10-18 12:31:30 |2008-04-15 19:37:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #10 from jsm28 at gcc dot gnu dot org 2008-04-15 19:44 --- 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). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
[Bug c/448] stdint.h-related issues (C99 issues)
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-18 12:31 --- 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. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-12-28 06:06:29 |2006-10-18 12:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
