headers
DJ Delorie | 1 Apr 2009 04:12
Picon
Favicon

Re: stdint.h type information needed


> 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;
(Continue reading)

Permalink | Reply |
headers
Joseph S. Myers | 1 Apr 2009 14:42

Re: stdint.h type information needed

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 <at> codesourcery.com
Permalink | Reply |
headers
Dave Korn | 1 Apr 2009 15:03

Re: stdint.h type information needed

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
Permalink | Reply |
headers
Dave Korn | 2 Apr 2009 08:55

Re: stdint.h type information needed

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
(Continue reading)

Permalink | Reply |
headers
Dave Korn | 2 Apr 2009 11:20

Re: stdint.h type information needed

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,
(Continue reading)

Permalink | Reply |
headers
Dave Korn | 3 Apr 2009 11:12

Re: stdint.h type information needed

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
(Continue reading)

Permalink | Reply |

Gmane