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

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 th

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

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 tar

Re: stdint.h type information needed

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

Re: stdint.h type information needed

Hum, well, only partially solved. I get a failure on c99-stdint-1.c, which I can reduce to: $ cat u.c #include 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

[SOLVED] Re: stdint.h type information needed

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 s

Re: stdint.h type information needed

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

Re: stdint.h type information needed

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

Re: stdint.h type information needed

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

Re: stdint.h type information needed

>> 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)); beca

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

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 w

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 m

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.

Re: stdint.h type information needed

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 ? Ye

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. Enj

Re: stdint.h type information needed

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

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 COPYI

Re: stdint.h type information needed

On Tue, 31 Mar 2009, DJ Delorie wrote: > DJGPP has its own , 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

Re: stdint.h type information needed

DJGPP has its own , at least in DJGPP 2.04.

stdint.h type information needed

GCC now supports providing the header (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 . Right now, t