Re: stdint.h type information needed

Re: stdint.h type information needed

[FX]

 >> for some reason identifier_global_value() on it returns NULL.
 > ... and this is presumably because it should have /already/ been  
declared somehow.

I have exactly the same issue on darwin, it segfaults on:

>   char16_type_node = TREE_TYPE (identifier_global_value  
> (char16_type_node));

because identifier_global_value (char16_type_node) is NULL. The patch  
I use is attached. Joseph, could you help us to proceed further?

Thanks,
FX





diff -pur trunk.unmodified/gcc/config/darwin.h trunk/gcc/config/darwin.h
--- trunk.unmodified/gcc/config/darwin.h	2009-04-03 10:48:59.000000000  
+0530
+++ trunk/gcc/config/darwin.h	2009-04-03 15:23:31.000000000 +0530
@@ -72,6 +72,38 @@ Boston, MA 02110-1301, USA.  */
  #undef	WCHAR_TYPE_SIZE
  #define WCHAR_TYPE_SIZE 32

+#define INT8_TYPE "signed char"
+#define INT16_TYPE "short int"
+#define INT32_TYPE "int"
+#define INT64_TYPE "long long int"
+#define UINT8_TYPE "unsigned char"
+#define UINT16_TYPE "unsigned short int"
+#define UINT32_TYPE "unsigned int"
+#define UINT64_TYPE "unsigned long long int"
+
+#define INT_LEAST8_TYPE "signed char"
+#define INT_LEAST16_TYPE "short int"
+#define INT_LEAST32_TYPE "int"
+#define INT_LEAST64_TYPE "long long int"
+#define UINT_LEAST8_TYPE "unsigned char"
+#define UINT_LEAST16_TYPE "unsigned short int"
+#define UINT_LEAST32_TYPE "unsigned int"
+#define UINT_LEAST64_TYPE "unsigned long long int"
+
+#define INT_FAST8_TYPE "signed char"
+#define INT_FAST16_TYPE "short int"
+#define INT_FAST32_TYPE "int"
+#define INT_FAST64_TYPE "long long int"
+#define UINT_FAST8_TYPE "unsigned char"
+#define UINT_FAST16_TYPE "unsigned short int"
+#define UINT_FAST32_TYPE "unsigned int"
+#define UINT_FAST64_TYPE "unsigned long long int"
+
+#define INTPTR_TYPE "long int"
+#define UINTPTR_TYPE "unsigned long int"
+
+#define SIG_ATOMIC_TYPE "int"
+
  /* Default to using the NeXT-style runtime, since that's what is
     pre-installed on Darwin systems.  */

pur trunk.unmodified/gcc/config.gcc trunk/gcc/config.gcc
--- trunk.unmodified/gcc/config.gcc	2009-04-03 10:49:00.000000000 +0530
+++ trunk/gcc/config.gcc	2009-04-03 11:04:52.000000000 +0530
@@ -411,6 +411,7 @@ case ${target} in
    extra_objs="darwin.o"
    extra_gcc_objs="darwin-driver.o"
    default_use_cxa_atexit=yes
+  use_gcc_stdint=wrap
    case ${enable_threads} in
      "" | yes | posix) thread_file='posix' ;;
    esac

Re: stdint.h type information needed

[Dave Korn]

FX wrote:
>>> for some reason identifier_global_value() on it returns NULL.
>> ... and this is presumably because it should have /already/ been
> declared somehow.
> 
> I have exactly the same issue on darwin, it segfaults on:
> 
>>   char16_type_node = TREE_TYPE (identifier_global_value
>> (char16_type_node));
> 
> because identifier_global_value (char16_type_node) is NULL. The patch I
> use is attached. Joseph, could you help us to proceed further?

  LOL, I forgot to attach mine didn't I?  It's basically the same, I copied
and pasted the newlib version and tweaked a couple of the definitions so they
were identical to Cygwin's stdint.h.  I suspect we're simply missing some
needed definition somewhere, so I won't send mine now you've sent yours.

  Neither adding /usr/include/uchar.h, nor defining char{16,32}_t in
/usr/include/stdint.h fixed this for me.

    cheers,
      DaveK

Re: stdint.h type information needed

[FX]

>  LOL, I forgot to attach mine didn't I?  It's basically the same, I  
> copied
> and pasted the newlib version and tweaked a couple of the  
> definitions so they
> were identical to Cygwin's stdint.h.  I suspect we're simply missing  
> some
> needed definition somewhere, so I won't send mine now you've sent  
> yours.
>
>  Neither adding /usr/include/uchar.h, nor defining char{16,32}_t in
> /usr/include/stdint.h fixed this for me.

It's simpler than that actually: the node for "unsigned short int" is  
not defined, but that of "short unsigned int" is. So we have to write  
in our target macros the following form: "(short|long|long long)  
unsigned int". I don't understand why, but it appears to work :)

FX

Re: stdint.h type information needed

[Dave Korn]

FX wrote:
>>  LOL, I forgot to attach mine didn't I?  It's basically the same, I
>> copied
>> and pasted the newlib version and tweaked a couple of the definitions
>> so they
>> were identical to Cygwin's stdint.h.  I suspect we're simply missing some
>> needed definition somewhere, so I won't send mine now you've sent yours.
>>
>>  Neither adding /usr/include/uchar.h, nor defining char{16,32}_t in
>> /usr/include/stdint.h fixed this for me.
> 
> It's simpler than that actually: the node for "unsigned short int" is
> not defined, but that of "short unsigned int" is. So we have to write in
> our target macros the following form: "(short|long|long long) unsigned
> int". I don't understand why, but it appears to work :)

  Ah, because it's initially based on string-matching when it creates the
identifiers to find an existing one that already has the binding info set.  I
don't know what the existing one is that's being matched, but that's a simple
solution, thanks for the tip!

  Side note: isn't it wrong to have multi-word identifiers?  Or at any rate
new, unusual and as-yet undocumented?

9.2.2 Identifiers
-----------------

An `IDENTIFIER_NODE' represents a slightly more general concept that
the standard C or C++ concept of identifier.  In particular, an
`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters.

  If we're going to have them, and word ordering is critical in the identifier
but not in the language semantic it represents, it should probably be
mentioned here.  I don't think spaces come under the category of
"extraordinary characters" because they're not just literals here, they are
semantic separators.


    cheers,
      DaveK

[SOLVED] Re: stdint.h type information needed

[Dave Korn]

Dave Korn wrote:
> FX wrote:
>>>  LOL, I forgot to attach mine didn't I?  It's basically the same, I
>>> copied
>>> and pasted the newlib version and tweaked a couple of the definitions
>>> so they
>>> were identical to Cygwin's stdint.h.  I suspect we're simply missing some
>>> needed definition somewhere, so I won't send mine now you've sent yours.
>>>
>>>  Neither adding /usr/include/uchar.h, nor defining char{16,32}_t in
>>> /usr/include/stdint.h fixed this for me.
>> It's simpler than that actually: the node for "unsigned short int" is
>> not defined, but that of "short unsigned int" is. So we have to write in
>> our target macros the following form: "(short|long|long long) unsigned
>> int". I don't understand why, but it appears to work :)
> 
>   Ah, because it's initially based on string-matching when it creates the
> identifiers to find an existing one that already has the binding info set.  I
> don't know what the existing one is that's being matched, but that's a simple
> solution, thanks for the tip!


  Got it: the key is that the types we use in our stdint.h target files have
to match the exact wording used at the top of c_common_nodes_and_builtins:

  /* `signed' is the same as `int'.  FIXME: the declarations of "signed",
     "unsigned long", "long long unsigned" and "unsigned short" were in C++
     but not C.  Are the conditionals here needed?  */
  if (c_dialect_cxx ())
    record_builtin_type (RID_SIGNED, NULL, integer_type_node);
  record_builtin_type (RID_LONG, "long int", long_integer_type_node);
  record_builtin_type (RID_UNSIGNED, "unsigned int", unsigned_type_node);
  record_builtin_type (RID_MAX, "long unsigned int",
		       long_unsigned_type_node);
  if (c_dialect_cxx ())
    record_builtin_type (RID_MAX, "unsigned long", long_unsigned_type_node);
  record_builtin_type (RID_MAX, "long long int",
		       long_long_integer_type_node);
  record_builtin_type (RID_MAX, "long long unsigned int",
		       long_long_unsigned_type_node);
  if (c_dialect_cxx ())
    record_builtin_type (RID_MAX, "long long unsigned",
			 long_long_unsigned_type_node);
  record_builtin_type (RID_SHORT, "short int", short_integer_type_node);
  record_builtin_type (RID_MAX, "short unsigned int",
		       short_unsigned_type_node);
  if (c_dialect_cxx ())
    record_builtin_type (RID_MAX, "unsigned short",
			 short_unsigned_type_node);

  Other OS maintainers, take note!

    cheers,
      DaveK

Re: stdint.h type information needed

[FX]

Hum, well, only partially solved. I get a failure on c99-stdint-1.c,  
which I can reduce to:

$ cat u.c
#include <stdint.h>

void
test_ptr (void)
{
   __typeof__(INTPTR_MIN) a;
   __typeof__((intptr_t)0 + 0) *b = &a;
}

$ ./gcc/xgcc -B./gcc u.c -std=iso9899:1999 -pedantic-errors -S
u.c: In function ‘test_ptr’:
u.c:7: error: initialization from incompatible pointer type


This is because, for 32-bit for example, intptr_t is "long" and  
INTPTR_MIN is (-2147483647-1), which is of type "int".
The same thing happens on 64-bit, because INTPTR_MIN is  
(-9223372036854775807LL-1), which is of type "long long", while  
intptr_t is still "long".

Is this a bug in darwin's headers?

FX

Re: stdint.h type information needed

[Dave Korn]

FX wrote:
> Hum, well, only partially solved. I get a failure on c99-stdint-1.c,
> which I can reduce to:

> u.c:7: error: initialization from incompatible pointer type

> This is because, for 32-bit for example, intptr_t is "long" and
> INTPTR_MIN is (-2147483647-1), which is of type "int".
> The same thing happens on 64-bit, because INTPTR_MIN is
> (-9223372036854775807LL-1), which is of type "long long", while intptr_t
> is still "long".
> 
> Is this a bug in darwin's headers?

  I think this is the kind of condition Joseph was talking about when he
referred to fixincluding and reporting upstream.

  Oh, read comment #15 in PR448!  Looks like it's already been noticed.

    cheers,
      DaveK

Re: [SOLVED] Re: stdint.h type information needed

[Joseph S. Myers]

On Fri, 3 Apr 2009, Dave Korn wrote:

>   Got it: the key is that the types we use in our stdint.h target files have
> to match the exact wording used at the top of c_common_nodes_and_builtins:

This requirement is documented in tm.texi (under SIZE_TYPE, to which the 
documentation of the other target macros refers).

If the target macros for such types are converted to target hooks in 
future, I imagine they'd return an enum value from enum integer_type_kind 
instead of a string, and take an enum value from enum tree_index or enum 
c_tree_index or some other similar enum to identify the typedef in 
question instead of having one hook per type.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [SOLVED] Re: stdint.h type information needed

[Dave Korn]

Joseph S. Myers wrote:
> On Fri, 3 Apr 2009, Dave Korn wrote:
> 
>>   Got it: the key is that the types we use in our stdint.h target files have
>> to match the exact wording used at the top of c_common_nodes_and_builtins:
> 
> This requirement is documented in tm.texi (under SIZE_TYPE, to which the 
> documentation of the other target macros refers).

  Ah, silly me.  I just read through the patch at that URL you posted at the
head of the thread, and that hunk is not present there.  Thank you.

    cheers,
      DaveK

stdint.h type information needed

[Joseph S. Myers]

GCC now supports providing the header <stdint.h> (required by C99 of 
freestanding implementations) and having information within the compiler 
about the types used in this header.  For further discussion of this and 
its benefits, see 
<http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00305.html>.

Right now, the information is present in GCC for targets using glibc or 
uClibc, bare-metal and RTEMS targets (which are taken to use newlib's 
default stdint.h types) and Solaris targets.  To get the full benefits of 
this support, the information needs adding for all OSes supported by GCC.  
This is information about all the types C99 specifies for <stdint.h>, plus 
sig_atomic_t whose limits go in that header.

To add information for a target OS, put definitions such as those in 
glibc-stdint.h, newlib-stdint.h or sol2.h in a suitable target header, and 
set use_gcc_stdint in config.gcc.  It should be set to "wrap" if the 
system has its own stdint.h header, or "provide" if it doesn't.  (There 
might be special cases when some other arrangement is needed, but I expect 
those two generally to suffice.)  Make sure the new c99-stdint-*.c tests 
pass; if they show up bugs in the system's stdint.h header (as wrapped by 
GCC with the "wrap" setting) then report those upstream and fix them in 
GCC with fixincludes.

If the system does not have stdint.h, then suitable types may be found in 
one of the following places:

* A later OS version.

* inttypes.h (some systems have headers from C9x drafts that had only 
inttypes.h and not stdint.h).

* Other headers such as sys/types.h, including possibly variant type names 
such as u_int32_t in those headers.

* As a last resort, for OSes that are no longer maintained or whose 
maintainers have had no interest in defining those types for the OS, the 
types may be invented for GCC.

At least the following OSes need the information added (for all supported 
architectures):

* Darwin
* FreeBSD
* NetBSD
* OpenBSD
* VxWorks
* alpha*-dec-osf[45]*
* VMS
* SymbianOS
* WinCE
* HP-UX
* DJGPP
* LynxOS
* Netware
* QNX
* Cygwin
* MinGW
* Interix
* IRIX
* AIX
* s390x-ibm-tpf*

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: stdint.h type information needed

[DJ Delorie]

DJGPP has its own <stdint.h>, at least in DJGPP 2.04.

Re: stdint.h type information needed

[Joseph S. Myers]

On Tue, 31 Mar 2009, DJ Delorie wrote:

> DJGPP has its own <stdint.h>, at least in DJGPP 2.04.

I expect most of the OSes listed do; the types should still be entered 
into GCC (so the Fortran front end can know them, for example), and 
use_gcc_stdint set to "wrap" unless there is a particular problem with 
using GCC's version in freestanding mode.  If the OS has its own copy, you 
can just go there to determine the types to enter into the appropriate 
tm.h header, instead of needing to try the other sources I listed.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: stdint.h type information needed

[DJ Delorie]

> I expect most of the OSes listed do; the types should still be entered 
> into GCC (so the Fortran front end can know them, for example), and 

Well, I'm not a big fan of duplicating information, but if that's what
you want to do, here it is.  Enjoy.


/* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2002 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details */
#ifndef __dj_stdint__h_
#define __dj_stdint__h_

#ifdef __cplusplus
extern "C" {
#endif

#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
  || !defined(__STRICT_ANSI__)

typedef signed char int_least8_t;
typedef unsigned char uint_least8_t;
typedef signed char int_fast8_t;
typedef unsigned char uint_fast8_t;
typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef signed short int int_least16_t;
typedef unsigned short int uint_least16_t;
typedef signed int int_fast16_t;
typedef unsigned int uint_fast16_t;
typedef signed short int int16_t;
typedef unsigned short int uint16_t;

typedef signed int int_least32_t;
typedef unsigned int uint_least32_t;
typedef signed int int_fast32_t;
typedef unsigned int uint_fast32_t;
typedef signed long int32_t;
typedef unsigned long uint32_t;

__extension__ typedef signed long long int_least64_t;
__extension__ typedef unsigned long long uint_least64_t;
__extension__ typedef signed long long int_fast64_t;
__extension__ typedef unsigned long long uint_fast64_t;
__extension__ typedef signed long long int64_t;
__extension__ typedef unsigned long long uint64_t;

typedef long int intptr_t;
typedef unsigned long uintptr_t;

__extension__ typedef signed long long intmax_t;
__extension__ typedef unsigned long long uintmax_t;

/* ANSI/ISO C99 says these should not be visible in C++ unless
   explicitly requested.  */

#if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS)

#define INT_LEAST8_MAX	 127
#define UINT_LEAST8_MAX	 255
#define INT_FAST8_MAX	 127
#define UINT_FAST8_MAX	 255
#define INT8_MAX	 127
#define UINT8_MAX	 255 
#define INT_LEAST8_MIN	 (-128)
#define INT_FAST8_MIN	 (-128)
#define INT8_MIN	 (-128)

#define INT_LEAST16_MAX	 32767
#define UINT_LEAST16_MAX 65535
#define INT_FAST16_MAX	 2147483647
#define UINT_FAST16_MAX	 4294967295U
#define INT16_MAX	 32767
#define UINT16_MAX	 65535
#define INT_LEAST16_MIN	 (-32768)
#define INT_FAST16_MIN	 (-2147483647-1)
#define INT16_MIN	 (-32768)

#define INT_LEAST32_MAX	 2147483647
#define UINT_LEAST32_MAX 4294967295U
#define INT_FAST32_MAX	 2147483647
#define UINT_FAST32_MAX	 4294967295U
#define INT32_MAX	 2147483647L
#define UINT32_MAX	 4294967295UL
#define INT_LEAST32_MIN	 (-2147483647-1)
#define INT_FAST32_MIN	 (-2147483647-1)
#define INT32_MIN	 (-2147483647L-1)

#define INT_LEAST64_MAX	 9223372036854775807LL
#define UINT_LEAST64_MAX 18446744073709551615ULL
#define INT_FAST64_MAX	 9223372036854775807LL
#define UINT_FAST64_MAX	 18446744073709551615ULL
#define INT64_MAX	 9223372036854775807LL
#define UINT64_MAX	 18446744073709551615ULL
#define INT_LEAST64_MIN	 (-9223372036854775807LL-1LL)
#define INT_FAST64_MIN	 (-9223372036854775807LL-1LL)
#define INT64_MIN	 (-9223372036854775807LL-1LL)

#define INTPTR_MAX	2147483647L
#define INTPTR_MIN	(-2147483647L-1L)
#define UINTPTR_MAX	0xffffffffUL

#define INTMAX_MAX	9223372036854775807LL
#define UINTMAX_MAX	18446744073709551615ULL
#define INTMAX_MIN	(-9223372036854775807LL-1LL)

#define PTRDIFF_MAX	2147483647
#define PTRDIFF_MIN	(-2147483647-1)
#define SIG_ATOMIC_MAX	2147483647
#define SIG_ATOMIC_MIN	(-2147483647-1)
#define SIZE_MAX	4294967295U

  /* These are defined by limits.h, so make them conditional.  */
#ifndef WCHAR_MAX
#define WCHAR_MAX	65535
#endif
#ifndef WCHAR_MIN
#define WCHAR_MIN	0
#endif
#ifndef WINT_MAX
#define WINT_MAX	2147483647
#endif
#ifndef WINT_MIN
#define WINT_MIN	(-2147483647-1)
#endif

#endif /* !__cplusplus || __STDC_LIMIT_MACROS */


#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)

#define INT8_C(x)	x
#define UINT8_C(x)	x ## U
#define INT16_C(x)	x
#define UINT16_C(x)	x ## U
#define INT32_C(x)	x
#define UINT32_C(x)	x ## U
#define INT64_C(x)	x ## LL
#define UINT64_C(x)	x ## ULL

#define INTMAX_C(x)	x ## LL
#define UINTMAX_C(x)	x ## ULL

#endif /* !__cplusplus || __STDC_CONSTANT_MACROS */

#endif /* (__STDC_VERSION__ >= 199901L) || !__STRICT_ANSI__ */

#ifndef __dj_ENFORCE_ANSI_FREESTANDIGN

#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
  || !defined(__STRICT_ANSI__)

#endif /* (__STDC_VERSION__ >= 199901L) || !__STRICT_ANSI__ */

#ifndef __STRICT_ANSI__

#ifndef _POSIX_SOURCE

#endif /* !_POSIX_SOURCE */
#endif /* !__STRICT_ANSI__ */
#endif /* !__dj_ENFORCE_ANSI_FREESTANDING */

#ifndef __dj_ENFORCE_FUNCTION_CALLS
#endif /* !__dj_ENFORCE_FUNCTION_CALLS */

#ifdef __cplusplus
}
#endif

#endif /* !__dj_stdint__h_ */

Re: stdint.h type information needed

[Joseph S. Myers]

On Tue, 31 Mar 2009, DJ Delorie wrote:

> > I expect most of the OSes listed do; the types should still be entered 
> > into GCC (so the Fortran front end can know them, for example), and 
> 
> Well, I'm not a big fan of duplicating information, but if that's what
> you want to do, here it is.  Enjoy.

I'm hoping the maintainers of OS support in GCC, or other people set up to 
test on each OS, will put the types in an appropriate tm.h header and test 
that the c99-stdint-*.c tests pass.  Adding the information myself without 
testing is very much a last resort.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: stdint.h type information needed

[Dave Korn]

Joseph S. Myers wrote:

> I'm hoping the maintainers of OS support in GCC, or other people set up to 
> test on each OS, will put the types in an appropriate tm.h header and test 
> that the c99-stdint-*.c tests pass.  Adding the information myself without 
> testing is very much a last resort.

  I'll take care of this during the week for Cygwin.  (It'll take me at least
a few days).

    cheers,
      DaveK

Re: stdint.h type information needed

[Dave Korn]

Dave Korn wrote:
> Joseph S. Myers wrote:
> 
>> I'm hoping the maintainers of OS support in GCC, or other people set up
>> to test on each OS, will put the types in an appropriate tm.h header and
>> test that the c99-stdint-*.c tests pass.  Adding the information myself
>> without testing is very much a last resort.
> 
> I'll take care of this during the week for Cygwin.  (It'll take me at least
>  a few days).

  First attempt (attached) didn't go so well.  When building libgcc2, I get an
ICE in the preprocessor, here:

Program received signal SIGSEGV, Segmentation fault.
0x004e8fdc in c_common_nodes_and_builtins ()
    at /gnu/gcc/gcc/gcc/c-common.c:4909
4909      char16_type_node = TREE_TYPE (identifier_global_value
(char16_type_node));
(gdb) bt
#0  0x004e8fdc in c_common_nodes_and_builtins ()
    at /gnu/gcc/gcc/gcc/c-common.c:4909
#1  0x0043fad8 in c_init_decl_processing () at /gnu/gcc/gcc/gcc/c-decl.c:2780
#2  0x0052d4f9 in c_objc_common_init () at /gnu/gcc/gcc/gcc/c-objc-common.c:70
#3  0x00b521d4 in lang_dependent_init (
    name=0x687cc9c "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c")
    at /gnu/gcc/gcc/gcc/toplev.c:2116
#4  0x00b523ca in do_compile () at /gnu/gcc/gcc/gcc/toplev.c:2237
#5  0x00b52438 in toplev_main (argc=68, argv=0x7279b98)
    at /gnu/gcc/gcc/gcc/toplev.c:2270
#6  0x005a7cc0 in main (argc=68, argv=0x7279b98) at /gnu/gcc/gcc/gcc/main.c:35
(gdb) print char16_type_node
No symbol "char16_type_node" in current context.
(gdb) list
4904      wchar_array_type_node
4905        = build_array_type (wchar_type_node, array_domain_type);
4906
4907      /* Define 'char16_t'.  */
4908      char16_type_node = get_identifier (CHAR16_TYPE);
4909      char16_type_node = TREE_TYPE (identifier_global_value
(char16_type_node));
4910      char16_type_size = TYPE_PRECISION (char16_type_node);
4911      if (c_dialect_cxx ())
4912        {
4913          char16_type_node = make_unsigned_type (char16_type_size);
(gdb) print CHAR16_TYPE
No symbol "CHAR16_TYPE" in current context.


  As far as I can tell, CHAR16_TYPE is:

(gdb) x/s 0x1fdb0f6
0x1fdb0f6 <__FUNCTION__.59453+167>:      "unsigned short"
(gdb)

  Is this perhaps related to the way all the short, long and longlong types in
cygwin-stdint.h omit "int"?

    cheers,
      DaveK

Re: stdint.h type information needed

[Dave Korn]

Dave Korn wrote:

> First attempt (attached) didn't go so well.  When building libgcc2, I get
> an ICE in the preprocessor, here:

> As far as I can tell, CHAR16_TYPE is:
> 
> (gdb) x/s 0x1fdb0f6 0x1fdb0f6 <__FUNCTION__.59453+167>:      "unsigned
> short" (gdb)
> 
> Is this perhaps related to the way all the short, long and longlong types
> in cygwin-stdint.h omit "int"?

  Answering my own question: no, it's not.

  char16_type_node exists, and looks like a valid type declaration to me, but
for some reason identifier_global_value() on it returns NULL.

$1 = (union tree_node *) 0x7ff31ab0
$2 = {base = {code = IDENTIFIER_NODE, side_effects_flag = 0,
    constant_flag = 0, addressable_flag = 0, volatile_flag = 0,
    readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0,
    nowarning_flag = 0, used_flag = 0, nothrow_flag = 0, static_flag = 0,
    public_flag = 0, private_flag = 0, protected_flag = 0,
    deprecated_flag = 0, saturating_flag = 0, default_def_flag = 0,
    lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0,
    lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, visited = 0,
    spare = 0, ann = 0x0}, common = {base = {code = IDENTIFIER_NODE,
      side_effects_flag = 0, constant_flag = 0, addressable_flag = 0,
      volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0,
      asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
      nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
      protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
      default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0,
      lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
      lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0,
    type = 0x0}, int_cst = {common = {base = {code = IDENTIFIER_NODE,
                              . . .
    imag = 0x12}, identifier = {common = {base = {code = IDENTIFIER_NODE,
        side_effects_flag = 0, constant_flag = 0, addressable_flag = 0,
        volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0,
        asm_written_flag = 0, nowarning_flag = 0, used_flag = 0,
        nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0,
        protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
        default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0,
        lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
        lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0,
      type = 0x0}, id = {str = 0x7ff00f20 "unsigned short int", len = 18,
      hash_value = 1006702630}}, decl_minimal = {common = {base = {

  Not sure yet what's wrong with it or why identifier_global_value is unhappy.

    cheers,
      DaveK

Re: stdint.h type information needed

[Dave Korn]

Dave Korn wrote:
> Dave Korn wrote:
> 
>> First attempt (attached) didn't go so well.  When building libgcc2, I get
>> an ICE in the preprocessor, here:
> 
>> As far as I can tell, CHAR16_TYPE is:
>>
>> (gdb) x/s 0x1fdb0f6 0x1fdb0f6 <__FUNCTION__.59453+167>:      "unsigned
>> short" (gdb)
>>
>> Is this perhaps related to the way all the short, long and longlong types
>> in cygwin-stdint.h omit "int"?
> 
>   Answering my own question: no, it's not.
> 
>   char16_type_node exists, and looks like a valid type declaration to me, but

s/type declaration/identifier node/

> for some reason identifier_global_value() on it returns NULL.

... and this is presumably because it should have /already/ been declared somehow.

  Does the implementation perhaps implicitly expect us to have provided
char16/32_t?  (Cygwin is a little backward in unicode support!)  I'll try
hacking up a quick "uchar.h" and see if that helps.

    cheers,
      DaveK

Re: stdint.h type information needed

[Bernd Roesch]

Hello Joseph

On 01.04.09, you wrote:

I add this file some time ago to Amiga OS 68k target, and build compiler, in
config.log files during compiler build, it seem detect right, are there
still defines in config.gcc need and other defines ?

configure:3626: $? = 0
configure:3629: test -s conftest.o
configure:3632: $? = 0
configure:3643: result: yes
configure:3597: checking for stdint.h
configure:3613: m68k-amigaos-gcc -c   conftest.c >&5
configure:3619: $? = 0
configure:3623: test -z 
             || test ! -s conftest.err
configure:3626: $? = 0
configure:3629: test -s conftest.o
configure:3632: $? = 0
configure:3643: result: yes 

Also in libstdc++ defines it is detect right automatic.

/* Define to 1 if you have the <stdint.h> header file. */
#define _GLIBCXX_HAVE_STDINT_H 1

/* Define to 1 if you have the <stdlib.h> header file. */
#define _GLIBCXX_HAVE_STDLIB_H 1 


> GCC now supports providing the header <stdint.h> (required by C99 of 
> freestanding implementations) and having information within the compiler 
> about the types used in this header.  For further discussion of this and 
> its benefits, see 
> <http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00305.html>.
> 
> Right now, the information is present in GCC for targets using glibc or
> uClibc, bare-metal and RTEMS targets (which are taken to use newlib's
> default stdint.h types) and Solaris targets. To get the full benefits of
> this support, the information needs adding for all OSes supported by GCC.
> This is information about all the types C99 specifies for <stdint.h>, plus
> sig_atomic_t whose limits go in that header.
> 
> To add information for a target OS, put definitions such as those in
> glibc-stdint.h, newlib-stdint.h or sol2.h in a suitable target header, and
> set use_gcc_stdint in config.gcc. It should be set to "wrap" if the system
> has its own stdint.h header, or "provide" if it doesn't. (There might be
> special cases when some other arrangement is needed, but I expect those
> two generally to suffice.) Make sure the new c99-stdint-*.c tests pass; if
> they show up bugs in the system's stdint.h header (as wrapped by GCC with
> the "wrap" setting) then report those upstream and fix them in GCC with
> fixincludes.
> 
> If the system does not have stdint.h, then suitable types may be found in 
> one of the following places:
> 
> * A later OS version.
> 
> * inttypes.h (some systems have headers from C9x drafts that had only 
> inttypes.h and not stdint.h).
> 
> * Other headers such as sys/types.h, including possibly variant type names
> such as u_int32_t in those headers.
> 
> * As a last resort, for OSes that are no longer maintained or whose 
> maintainers have had no interest in defining those types for the OS, the 
> types may be invented for GCC.
> 
> At least the following OSes need the information added (for all supported 
> architectures):
> 
> * Darwin
> * FreeBSD
> * NetBSD
> * OpenBSD
> * VxWorks
> * alpha*-dec-osf[45]*
> * VMS
> * SymbianOS
> * WinCE
> * HP-UX
> * DJGPP
> * LynxOS
> * Netware
> * QNX
> * Cygwin
> * MinGW
> * Interix
> * IRIX
> * AIX
> * s390x-ibm-tpf*
> 
Regards

Re: stdint.h type information needed

[Joseph S. Myers]

On Wed, 1 Apr 2009, Bernd Roesch wrote:

> Hello Joseph
> 
> On 01.04.09, you wrote:
> 
> I add this file some time ago to Amiga OS 68k target, and build compiler, in
> config.log files during compiler build, it seem detect right, are there
> still defines in config.gcc need and other defines ?

Yes, the main changes needed are definitions in a tm.h header like those 
in sol2.h:

#define INT8_TYPE "char"
#define INT16_TYPE "short int"
...

after which a definition of use_gcc_stdint can be added to config.gcc.

-- 
Joseph S. Myers
joseph@codesourcery.com