This is the mail archive of the
mailing list for the GCC project.
Re: (Broken) stdint.h support for FreeBSD
On Sat, May 30, 2009 at 10:17 PM, Gerald Pfeifer <firstname.lastname@example.org> wrote:
> On Sat, 30 May 2009, Dave Korn wrote:
>>> What happens here is that $OBJDIR/./cc1 segfaults. ?I have a hunch I
>>> must be missing the obvious. :-( ?Does any of you see what might be
>>> wrong here?
>> ? A stack trace? ;-)
> I got one now:
> ?Program received signal SIGSEGV, Segmentation fault.
> ?0x080e0016 in c_common_nodes_and_builtins ()
> ? ? ?at /usr/test/gcc/gcc/c-common.c:4780
> ?4780 ? ? ?char16_type_node = TREE_TYPE (identifier_global_value (char16_type_node));
> char16_type is a type that is _not_ defined by one of the macros in my
> new config/freebsd-stdint.h nor config/glibc-stdint.h, either. ?Hmm...
> Joseph, any chance you could make this mechanism a bit more failure
> resilient? ?A SIGSEGV is a bit harsh and not very constructive. :-]
> On Sat, 30 May 2009, Richard Guenther wrote:
>>>?If it's a segv in c_common_nodes_and_builtins, that means that one of
>>> the name strings you defined in freebsd-stdint.h doesn't match against
>>> any of the predefined types instantiated at the top of that function.
>>> ?Note that it's a simple string match, so ordering of "(un)signed" and
>>> "long/short" must be identical; it's not parsed to be c-type-semantics
>> In which case it is probably "short" vs. "short int" in two places.
> Thanks for the explanation, Dave and Richard. ?The situation appears
> a bit tricky than what I have seen on other platforms, On FreeBSD 7.1
> /usr/include/stdint.h looks as follows:
> ?#include <sys/_types.h>
> ?typedef __int16_t ? ? ? ? ? ? ? int16_t;
> where /usr/include/sys/_types.h has
> ?#include <machine/_types.h>
> which in turns does
> ?typedef short ? ? ? ? ? ? ? ? ? __int16_t;
> Are you saying that I should do
> ?#define INT16_TYPE ? ? ? ?"__int16_t"
> instead of
> ?#define INT16_TYPE ? ? ? ?"short"
> and so forth?
#define INT16_TYPE "short int"
as glibc-stdint.h does.