public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
@ 2004-08-02 12:14 ` papadopo at shfj dot cea dot fr
2004-08-02 16:33 ` jsm at polyomino dot org dot uk
` (4 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: papadopo at shfj dot cea dot fr @ 2004-08-02 12:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From papadopo at shfj dot cea dot fr 2004-08-02 12:14 -------
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>.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
2004-08-02 12:14 ` [Bug c/448] <stdint.h>-related issues (C99 issues) papadopo at shfj dot cea dot fr
@ 2004-08-02 16:33 ` jsm at polyomino dot org dot uk
2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
` (3 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: jsm at polyomino dot org dot uk @ 2004-08-02 16:33 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm at polyomino dot org dot uk 2004-08-02 16:33 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
2004-08-02 12:14 ` [Bug c/448] <stdint.h>-related issues (C99 issues) papadopo at shfj dot cea dot fr
2004-08-02 16:33 ` jsm at polyomino dot org dot uk
@ 2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
2004-08-19 22:12 ` geoffk at gcc dot gnu dot org
` (2 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2004-08-11 21:05 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |16989
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
` (2 preceding siblings ...)
2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
@ 2004-08-19 22:12 ` geoffk at gcc dot gnu dot org
2004-08-19 22:27 ` jsm at polyomino dot org dot uk
2004-09-24 22:31 ` jsm28 at gcc dot gnu dot org
5 siblings, 0 replies; 28+ messages in thread
From: geoffk at gcc dot gnu dot org @ 2004-08-19 22:12 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From geoffk at gcc dot gnu dot org 2004-08-19 22:12 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
` (3 preceding siblings ...)
2004-08-19 22:12 ` geoffk at gcc dot gnu dot org
@ 2004-08-19 22:27 ` jsm at polyomino dot org dot uk
2004-09-24 22:31 ` jsm28 at gcc dot gnu dot org
5 siblings, 0 replies; 28+ messages in thread
From: jsm at polyomino dot org dot uk @ 2004-08-19 22:27 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jsm at polyomino dot org dot uk 2004-08-19 22:26 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
` (4 preceding siblings ...)
2004-08-19 22:27 ` jsm at polyomino dot org dot uk
@ 2004-09-24 22:31 ` jsm28 at gcc dot gnu dot org
5 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2004-09-24 22:31 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2009-12-27 18:33 ` joseph at codesourcery dot com
@ 2009-12-27 18:37 ` joseph at codesourcery dot com
21 siblings, 0 replies; 28+ messages in thread
From: joseph at codesourcery dot com @ 2009-12-27 18:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2009-12-27 13:38 ` laurent at guerby dot net
@ 2009-12-27 18:33 ` joseph at codesourcery dot com
2009-12-27 18:37 ` joseph at codesourcery dot com
21 siblings, 0 replies; 28+ messages in thread
From: joseph at codesourcery dot com @ 2009-12-27 18:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2009-12-08 17:09 ` jsm28 at gcc dot gnu dot org
@ 2009-12-27 13:38 ` laurent at guerby dot net
2009-12-27 18:33 ` joseph at codesourcery dot com
2009-12-27 18:37 ` joseph at codesourcery dot com
21 siblings, 0 replies; 28+ messages in thread
From: laurent at guerby dot net @ 2009-12-27 13:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2009-07-31 13:57 ` paolo dot carlini at oracle dot com
@ 2009-12-08 17:09 ` jsm28 at gcc dot gnu dot org
2009-12-27 13:38 ` laurent at guerby dot net
` (2 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2009-12-08 17:09 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2009-07-31 13:15 ` paolo dot carlini at oracle dot com
@ 2009-07-31 13:57 ` paolo dot carlini at oracle dot com
2009-12-08 17:09 ` jsm28 at gcc dot gnu dot org
` (3 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-07-31 13:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2009-07-31 13:10 ` joseph at codesourcery dot com
@ 2009-07-31 13:15 ` paolo dot carlini at oracle dot com
2009-07-31 13:57 ` paolo dot carlini at oracle dot com
` (4 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-07-31 13:15 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2009-07-31 13:04 ` paolo dot carlini at oracle dot com
@ 2009-07-31 13:10 ` joseph at codesourcery dot com
2009-07-31 13:15 ` paolo dot carlini at oracle dot com
` (5 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: joseph at codesourcery dot com @ 2009-07-31 13:10 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2009-07-31 12:54 ` joseph at codesourcery dot com
@ 2009-07-31 13:04 ` paolo dot carlini at oracle dot com
2009-07-31 13:10 ` joseph at codesourcery dot com
` (6 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-07-31 13:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2009-07-31 12:41 ` paolo dot carlini at oracle dot com
@ 2009-07-31 12:54 ` joseph at codesourcery dot com
2009-07-31 13:04 ` paolo dot carlini at oracle dot com
` (7 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: joseph at codesourcery dot com @ 2009-07-31 12:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2009-04-08 20:05 ` hp at gcc dot gnu dot org
@ 2009-07-31 12:41 ` paolo dot carlini at oracle dot com
2009-07-31 12:54 ` joseph at codesourcery dot com
` (8 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-07-31 12:41 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2009-04-08 15:49 ` joseph at codesourcery dot com
@ 2009-04-08 20:05 ` hp at gcc dot gnu dot org
2009-07-31 12:41 ` paolo dot carlini at oracle dot com
` (9 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-08 20:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2009-04-08 6:55 ` hp at gcc dot gnu dot org
@ 2009-04-08 15:49 ` joseph at codesourcery dot com
2009-04-08 20:05 ` hp at gcc dot gnu dot org
` (10 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: joseph at codesourcery dot com @ 2009-04-08 15:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2009-04-01 14:26 ` joseph at codesourcery dot com
@ 2009-04-08 6:55 ` hp at gcc dot gnu dot org
2009-04-08 15:49 ` joseph at codesourcery dot com
` (11 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-08 6:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2009-04-01 13:25 ` dominiq at lps dot ens dot fr
@ 2009-04-01 14:26 ` joseph at codesourcery dot com
2009-04-08 6:55 ` hp at gcc dot gnu dot org
` (12 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: joseph at codesourcery dot com @ 2009-04-01 14:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2009-03-31 20:33 ` jsm28 at gcc dot gnu dot org
@ 2009-04-01 13:25 ` dominiq at lps dot ens dot fr
2009-04-01 14:26 ` joseph at codesourcery dot com
` (13 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-04-01 13:25 UTC (permalink / raw)
To: gcc-bugs
------- 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)
/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'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2009-03-31 20:31 ` jsm28 at gcc dot gnu dot org
@ 2009-03-31 20:33 ` jsm28 at gcc dot gnu dot org
2009-04-01 13:25 ` dominiq at lps dot ens dot fr
` (14 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2009-03-31 20:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2008-11-08 0:17 ` jsm28 at gcc dot gnu dot org
@ 2009-03-31 20:31 ` jsm28 at gcc dot gnu dot org
2009-03-31 20:33 ` jsm28 at gcc dot gnu dot org
` (15 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2009-03-31 20:31 UTC (permalink / raw)
To: gcc-bugs
------- 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=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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2008-04-18 14:16 ` jsm28 at gcc dot gnu dot org
@ 2008-11-08 0:17 ` jsm28 at gcc dot gnu dot org
2009-03-31 20:31 ` jsm28 at gcc dot gnu dot org
` (16 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2008-11-08 0:17 UTC (permalink / raw)
To: gcc-bugs
------- 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=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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2008-04-15 19:45 ` jsm28 at gcc dot gnu dot org
@ 2008-04-18 14:16 ` jsm28 at gcc dot gnu dot org
2008-11-08 0:17 ` jsm28 at gcc dot gnu dot org
` (17 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2008-04-18 14:16 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
2006-10-18 12:31 ` fxcoudert at gcc dot gnu dot org
2008-04-15 19:38 ` bkoz at gcc dot gnu dot org
@ 2008-04-15 19:45 ` jsm28 at gcc dot gnu dot org
2008-04-18 14:16 ` jsm28 at gcc dot gnu dot org
` (18 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2008-04-15 19:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
2006-10-18 12:31 ` fxcoudert at gcc dot gnu dot org
@ 2008-04-15 19:38 ` bkoz at gcc dot gnu dot org
2008-04-15 19:45 ` jsm28 at gcc dot gnu dot org
` (19 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2008-04-15 19:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/448] <stdint.h>-related issues (C99 issues)
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
@ 2006-10-18 12:31 ` fxcoudert at gcc dot gnu dot org
2008-04-15 19:38 ` bkoz at gcc dot gnu dot org
` (20 subsequent siblings)
21 siblings, 0 replies; 28+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2006-10-18 12:31 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2009-12-27 18:37 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20000807074601.448.jsm-gccbugs@polyomino.org.uk>
2004-08-02 12:14 ` [Bug c/448] <stdint.h>-related issues (C99 issues) papadopo at shfj dot cea dot fr
2004-08-02 16:33 ` jsm at polyomino dot org dot uk
2004-08-11 21:05 ` jsm28 at gcc dot gnu dot org
2004-08-19 22:12 ` geoffk at gcc dot gnu dot org
2004-08-19 22:27 ` jsm at polyomino dot org dot uk
2004-09-24 22:31 ` jsm28 at gcc dot gnu dot org
[not found] <bug-448-230@http.gcc.gnu.org/bugzilla/>
2006-10-18 12:31 ` fxcoudert at gcc dot gnu dot org
2008-04-15 19:38 ` bkoz at gcc dot gnu dot org
2008-04-15 19:45 ` jsm28 at gcc dot gnu dot org
2008-04-18 14:16 ` jsm28 at gcc dot gnu dot org
2008-11-08 0:17 ` jsm28 at gcc dot gnu dot org
2009-03-31 20:31 ` jsm28 at gcc dot gnu dot org
2009-03-31 20:33 ` jsm28 at gcc dot gnu dot org
2009-04-01 13:25 ` dominiq at lps dot ens dot fr
2009-04-01 14:26 ` joseph at codesourcery dot com
2009-04-08 6:55 ` hp at gcc dot gnu dot org
2009-04-08 15:49 ` joseph at codesourcery dot com
2009-04-08 20:05 ` hp at gcc dot gnu dot org
2009-07-31 12:41 ` paolo dot carlini at oracle dot com
2009-07-31 12:54 ` joseph at codesourcery dot com
2009-07-31 13:04 ` paolo dot carlini at oracle dot com
2009-07-31 13:10 ` joseph at codesourcery dot com
2009-07-31 13:15 ` paolo dot carlini at oracle dot com
2009-07-31 13:57 ` paolo dot carlini at oracle dot com
2009-12-08 17:09 ` jsm28 at gcc dot gnu dot org
2009-12-27 13:38 ` laurent at guerby dot net
2009-12-27 18:33 ` joseph at codesourcery dot com
2009-12-27 18:37 ` joseph at codesourcery dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).