[Libiberty] : Handle VMS as a LLP64 platform in splay-tree.h

On Apr 4, 2012, at 3:58 PM, Ian Lance Taylor wrote:

> Tristan Gingold <gingold@adacore.com> writes:
> 
>> include/
>> 2012-04-04  Tristan Gingold  <gingold@adacore.com>
>> 
>> 	* splay-tree.h: Use LLP64 definitions of libi_shostptr_t and
>> 	libi_hostptr_t for VMS with 64bit pointers.
> 
> I was strongly opposed to adding a _WIN64 define here and this is just
> making it worse.

Understood.

Would something like that be acceptable ?
I have just checked that I can still build gcc with that patch.  If you like this approach I will properly submit a patch.

Tristan.

Tristan Gingold <gingold@adacore.com> writes:

> Would something like that be acceptable ?
> I have just checked that I can still build gcc with that patch.  If you like this approach I will properly submit a patch.

Thanks.

You should also test that gdb continues to build with this patch.

I guess the question here is portability.  Do we still care about
portability to systems that have neither inttypes.h nor stdint.h?  I'm
willing to try this and see if anybody complains.

Ian


> --- a/include/splay-tree.h
> +++ b/include/splay-tree.h
> @@ -37,18 +37,11 @@ extern "C" {
>  
>  #include "ansidecl.h"
>  
> -#ifndef _WIN64
> -  typedef unsigned long int libi_uhostptr_t;
> -  typedef long int libi_shostptr_t;
> -#else
> -#ifdef __GNUC__
> -  __extension__
> +#ifdef HAVE_STDINT_H
> +#include <stdint.h>
>  #endif
> -  typedef unsigned long long libi_uhostptr_t;
> -#ifdef __GNUC__
> -  __extension__
> -#endif
> -  typedef long long libi_shostptr_t;
> +#ifdef HAVE_INTTYPES_H
> +#include <inttypes.h>
>  #endif
>  
>  #ifndef GTY
> @@ -59,8 +52,8 @@ extern "C" {
>     these types, if necessary.  These types should be sufficiently wide
>     that any pointer or scalar can be cast to these types, and then
>     cast back, without loss of precision.  */
> -typedef libi_uhostptr_t splay_tree_key;
> -typedef libi_uhostptr_t splay_tree_value;
> +typedef uintptr_t splay_tree_key;
> +typedef uintptr_t splay_tree_value;
>  
>  /* Forward declaration for a node in the tree.  */
>  typedef struct splay_tree_node_s *splay_tree_node;
>
>
> index 7450eeb..fa45392 100644
> --- a/gcc/gengtype.c
> +++ b/gcc/gengtype.c
> @@ -4976,6 +4976,7 @@ main (int argc, char **argv)
>        POS_HERE (do_scalar_typedef ("double_int", &pos));
>        POS_HERE (do_scalar_typedef ("uint64_t", &pos));
>        POS_HERE (do_scalar_typedef ("uint8", &pos));
> +      POS_HERE (do_scalar_typedef ("uintptr_t", &pos));
>        POS_HERE (do_scalar_typedef ("jword", &pos));
>        POS_HERE (do_scalar_typedef ("JCF_u2", &pos));
>        POS_HERE (do_scalar_typedef ("void", &pos));

On Apr 4, 2012, at 5:07 PM, Ian Lance Taylor wrote:

> Tristan Gingold <gingold@adacore.com> writes:
> 
>> Would something like that be acceptable ?
>> I have just checked that I can still build gcc with that patch.  If you like this approach I will properly submit a patch.
> 
> Thanks.
> 
> You should also test that gdb continues to build with this patch.

Argh, good point.

> I guess the question here is portability.  Do we still care about
> portability to systems that have neither inttypes.h nor stdint.h?  I'm
> willing to try this and see if anybody complains.

In this case, autoconf defines uintptr_t so I don't think there is an issue here.

Tristan.

> 
> Ian
> 
> 
>> --- a/include/splay-tree.h
>> +++ b/include/splay-tree.h
>> @@ -37,18 +37,11 @@ extern "C" {
>> 
>> #include "ansidecl.h"
>> 
>> -#ifndef _WIN64
>> -  typedef unsigned long int libi_uhostptr_t;
>> -  typedef long int libi_shostptr_t;
>> -#else
>> -#ifdef __GNUC__
>> -  __extension__
>> +#ifdef HAVE_STDINT_H
>> +#include <stdint.h>
>> #endif
>> -  typedef unsigned long long libi_uhostptr_t;
>> -#ifdef __GNUC__
>> -  __extension__
>> -#endif
>> -  typedef long long libi_shostptr_t;
>> +#ifdef HAVE_INTTYPES_H
>> +#include <inttypes.h>
>> #endif
>> 
>> #ifndef GTY
>> @@ -59,8 +52,8 @@ extern "C" {
>>    these types, if necessary.  These types should be sufficiently wide
>>    that any pointer or scalar can be cast to these types, and then
>>    cast back, without loss of precision.  */
>> -typedef libi_uhostptr_t splay_tree_key;
>> -typedef libi_uhostptr_t splay_tree_value;
>> +typedef uintptr_t splay_tree_key;
>> +typedef uintptr_t splay_tree_value;
>> 
>> /* Forward declaration for a node in the tree.  */
>> typedef struct splay_tree_node_s *splay_tree_node;
>> 
>> 
>> index 7450eeb..fa45392 100644
>> --- a/gcc/gengtype.c
>> +++ b/gcc/gengtype.c
>> @@ -4976,6 +4976,7 @@ main (int argc, char **argv)
>>       POS_HERE (do_scalar_typedef ("double_int", &pos));
>>       POS_HERE (do_scalar_typedef ("uint64_t", &pos));
>>       POS_HERE (do_scalar_typedef ("uint8", &pos));
>> +      POS_HERE (do_scalar_typedef ("uintptr_t", &pos));
>>       POS_HERE (do_scalar_typedef ("jword", &pos));
>>       POS_HERE (do_scalar_typedef ("JCF_u2", &pos));
>>       POS_HERE (do_scalar_typedef ("void", &pos));

On 04/04/2012 04:07 PM, Ian Lance Taylor wrote:

> Tristan Gingold <gingold@adacore.com> writes:
> 
>> > Would something like that be acceptable ?
>> > I have just checked that I can still build gcc with that patch.  If you like this approach I will properly submit a patch.
> Thanks.
> 
> You should also test that gdb continues to build with this patch.


GDB pulls stdint.h from gnulib (though not inttypes.h), so it should
be fine in principle.

> I guess the question here is portability.  Do we still care about
> portability to systems that have neither inttypes.h nor stdint.h?  I'm
> willing to try this and see if anybody complains.