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