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
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
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
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
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
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
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
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
>> 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
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
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
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
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.
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
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
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
> 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
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
DJGPP has its own , at least in DJGPP 2.04.
19 matches
Mail list logo
