Re: (Broken) stdint.h support for FreeBSD

[Gerald Pfeifer <gerald at pfeifer dot com>]

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 
>> aware.
> 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?

Gerald