| Message ID | 4FCF8724.9020600@verizon.net |
|---|---|
| State | New |
| Headers | show |
On Wed, 6 Jun 2012, rbmj wrote: > The stdint.h doesn't have all the typedefs needed for standards > compliance, so add a hack that adds all of the needed typedefs > to be fully compliant to the standard. Fixes broken libstdc++. If you're touching VxWorks stdint.h perhaps you could also define the relevant target macros for GCC to have built-in knowledge of the types? This is needed for the Fortran C bindings to work correctly, at least, and ensures char16_t and char32_t (C11/C++11) are correct as well. (You could then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's stdint.h for freestanding compilations.)
On 06/12/2012 11:47 AM, Joseph S. Myers wrote: > On Wed, 6 Jun 2012, rbmj wrote: > >> The stdint.h doesn't have all the typedefs needed for standards >> compliance, so add a hack that adds all of the needed typedefs >> to be fully compliant to the standard. Fixes broken libstdc++. > If you're touching VxWorks stdint.h perhaps you could also define the > relevant target macros for GCC to have built-in knowledge of the types? > This is needed for the Fortran C bindings to work correctly, at least, and > ensures char16_t and char32_t (C11/C++11) are correct as well. (You could > then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's > stdint.h for freestanding compilations.) I would be happy to, but I'm not aware of what macros those are. If you could point me to some documentation or explain to me what macros I need to define I'll update the patch. Thanks, Robert
On Tue, 12 Jun 2012, rbmj wrote: > On 06/12/2012 11:47 AM, Joseph S. Myers wrote: > > On Wed, 6 Jun 2012, rbmj wrote: > > > > > The stdint.h doesn't have all the typedefs needed for standards > > > compliance, so add a hack that adds all of the needed typedefs > > > to be fully compliant to the standard. Fixes broken libstdc++. > > If you're touching VxWorks stdint.h perhaps you could also define the > > relevant target macros for GCC to have built-in knowledge of the types? > > This is needed for the Fortran C bindings to work correctly, at least, and > > ensures char16_t and char32_t (C11/C++11) are correct as well. (You could > > then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's > > stdint.h for freestanding compilations.) > I would be happy to, but I'm not aware of what macros those are. If you could > point me to some documentation or explain to me what macros I need to define > I'll update the patch. <http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html> was my original announcement for target OS maintainers. You should define the same set of macros as in gcc/config/glibc-stdint.h (but, obviously, to values appropriate to VxWorks), plus INTMAX_TYPE and UINTMAX_TYPE if the default values of those macros are wrong for VxWorks, and make sure all the c99-stdint-*.c tests pass.
On 06/12/2012 04:20 PM, Joseph S. Myers wrote: > On Tue, 12 Jun 2012, rbmj wrote: > >> On 06/12/2012 11:47 AM, Joseph S. Myers wrote: >>> On Wed, 6 Jun 2012, rbmj wrote: >>> >>>> The stdint.h doesn't have all the typedefs needed for standards >>>> compliance, so add a hack that adds all of the needed typedefs >>>> to be fully compliant to the standard. Fixes broken libstdc++. >>> If you're touching VxWorks stdint.h perhaps you could also define the >>> relevant target macros for GCC to have built-in knowledge of the types? >>> This is needed for the Fortran C bindings to work correctly, at least, and >>> ensures char16_t and char32_t (C11/C++11) are correct as well. (You could >>> then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's >>> stdint.h for freestanding compilations.) >> I would be happy to, but I'm not aware of what macros those are. If you could >> point me to some documentation or explain to me what macros I need to define >> I'll update the patch. > <http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html> was my original > announcement for target OS maintainers. You should define the same set of > macros as in gcc/config/glibc-stdint.h (but, obviously, to values > appropriate to VxWorks), plus INTMAX_TYPE and UINTMAX_TYPE if the default > values of those macros are wrong for VxWorks, and make sure all the > c99-stdint-*.c tests pass. > Since u?int.*_t are already defined, would this work? Or should I use the non-typedef'd versions? Also, I'm not exactly sure how to run the regression tests with a cross compiler. I'm still new to everything, bear with me :-) #define SIG_ATOMIC_TYPE "int" #define INT8_TYPE "int8_t" #define INT16_TYPE "int16_t" #define INT32_TYPE "int32_t" #define INT64_TYPE "int64_t" #define UINT8_TYPE "uint8_t" #define UINT16_TYPE "uint16_t" #define UINT32_TYPE "uint32_t" #define UINT64_TYPE "uint64_t" #define INT_LEAST8_TYPE "int_least8_t" #define INT_LEAST16_TYPE "int_least16_t" #define INT_LEAST32_TYPE "int_least32_t" #define INT_LEAST64_TYPE "int_least64_t" #define UINT_LEAST8_TYPE "uint_least8_t" #define UINT_LEAST16_TYPE "uint_least16_t" #define UINT_LEAST32_TYPE "uint_least32_t" #define UINT_LEAST64_TYPE "uint_least64_t" #define INT_FAST8_TYPE "int_fast8_t" #define INT_FAST16_TYPE "int_fast16_t" #define INT_FAST32_TYPE "int_fast32_t" #define INT_FAST64_TYPE "int_fast64_t" #define UINT_FAST8_TYPE "uint_fast8_t" #define UINT_FAST16_TYPE "uint_fast16_t" #define UINT_FAST32_TYPE "uint_fast32_t" #define UINT_FAST64_TYPE "uint_fast64_t" #define INTPTR_TYPE "intptr_t" #define UINTPTR_TYPE "uintptr_t" Robert
On Wed, 13 Jun 2012, rbmj wrote: > Since u?int.*_t are already defined, would this work? Or should I use the > non-typedef'd versions? Also, I'm not exactly sure how to run the regression > tests with a cross compiler. I'm still new to everything, bear with me :-) You have to use the non-typedef versions, with the keywords in the correct order - see the documentation of SIZE_TYPE in tm.texi for details.
On 06/13/2012 01:59 PM, Joseph S. Myers wrote: > On Wed, 13 Jun 2012, rbmj wrote: > >> Since u?int.*_t are already defined, would this work? Or should I use the >> non-typedef'd versions? Also, I'm not exactly sure how to run the regression >> tests with a cross compiler. I'm still new to everything, bear with me :-) > You have to use the non-typedef versions, with the keywords in the correct > order - see the documentation of SIZE_TYPE in tm.texi for details. > OK, so I've looked everything over a few times, and I know that these are in types/vxTypesOld.h, which is not in the arch directory, so it *should* be architecture independent for vxWorks: typedef signed char INT8; typedef signed short INT16; typedef signed int INT32; typedef signed long long INT64; typedef unsigned char UINT8; typedef unsigned short UINT16; typedef unsigned int UINT32; typedef unsigned long long UINT64; My issue is that I'm uncomfortable with this, as it seems *too* easy. With the number of architectures vxWorks supports, I'm highly skeptical that this actually works across all vxWorks targets. Since I only work with ppc32 targets, perhaps somebody who has knowledge of other vxWorks ports could confirm or dismiss my fears. Sorry for the amount of time it has taken me to respond. Robert
On Jun 20, 2012, at 12:36 PM, rbmj <rbmj@verizon.net> wrote:
> My issue is that I'm uncomfortable with this, as it seems *too* easy.
I'd just be comfortable with a stake in the ground and press forward. I do think this covers most all the cases.
From a50ecd253f6e7fa4a6558ebce0578c5f48ccbc17 Mon Sep 17 00:00:00 2001 From: rbmj <rbmj@verizon.net> Date: Mon, 4 Jun 2012 13:26:57 -0400 Subject: [PATCH 3/7] Add stdint.h wrapper for VxWorks. The stdint.h doesn't have all the typedefs needed for standards compliance, so add a hack that adds all of the needed typedefs to be fully compliant to the standard. Fixes broken libstdc++. Changes: * fixincludes/inclhack.def: Added AAB_vxworks_stdint fix --- fixincludes/inclhack.def | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def index d66b1cb..a7e49cd 100644 --- a/fixincludes/inclhack.def +++ b/fixincludes/inclhack.def @@ -396,6 +396,50 @@ fix = { /* + * Make VxWorks stdint.h a bit more compliant - add typedefs + */ +fix = { + hackname = AAB_vxworks_stdint; + files = stdint.h; + mach = "*-*-vxworks*"; + + replace = <<- _EndOfHeader_ + #ifndef _STDINT_H + #define _STDINT_H + /* get int*_t, uint*_t */ + #include <types/vxTypes.h> + + typedef long intptr_t; + typedef unsigned long uintptr_t; + + typedef int64_t intmax_t; + typedef uint64_t uintmax_t; + + typedef int8_t int_least8_t; + typedef int16_t int_least16_t; + typedef int32_t int_least32_t; + typedef int64_t int_least64_t; + + typedef uint8_t uint_least8_t; + typedef uint16_t uint_least16_t; + typedef uint32_t uint_least32_t; + typedef uint64_t uint_least64_t; + + typedef int8_t int_fast8_t; + typedef int int_fast16_t; + typedef int32_t int_fast32_t; + typedef int64_t int_fast64_t; + + typedef uint8_t uint_fast8_t; + typedef unsigned int uint_fast16_t; + typedef uint32_t uint_fast32_t; + typedef uint64_t uint_fast64_t; + #endif + _EndOfHeader_; +}; + + +/* * complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I, * which only is provided by AIX xlc C99. */ -- 1.7.5.4
The stdint.h doesn't have all the typedefs needed for standards compliance, so add a hack that adds all of the needed typedefs to be fully compliant to the standard. Fixes broken libstdc++. Changes: * fixincludes/inclhack.def: Added AAB_vxworks_stdint fix --- fixincludes/inclhack.def | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-)