Re: Update to splay-tree.h for 64-bit Windows host

Re: Update to splay-tree.h for 64-bit Windows host

[Hans-Peter Nilsson]

On Thu, 12 Jul 2007, Kai Tietz wrote:
> This patch solves this problem with gengtype. It is tested for
> i686-pc-linux-gnu and x86_64-pc-mingw32.

I suggest you commit it post haste as obvious.

(I was testing the exact same change and testing has progressed
past building cc1 for x86_64.)

>
> ChangeLog: /include
>
> 2007-07-12  Kai Tietz   <kai.tietz@onevision.com>
>
>         * splay-tree.h (libi_uhostptr_t, libi_shostptr_t): Adjust types
>         work-a-round whitespace problem in gcc gengtype.

brgds, H-P

Re: Update to splay-tree.h for 64-bit Windows host

[Diego Novillo]

On 7/12/07 8:22 AM, Kai Tietz wrote:

>         * splay-tree.h (libi_uhostptr_t, libi_shostptr_t): Adjust types
>         work-a-round whitespace problem in gcc gengtype.

OK.

Re: Update to splay-tree.h for 64-bit Windows host

[Hans-Peter Nilsson]

On Thu, 12 Jul 2007, Kai Tietz wrote:
> 2007-07-12  Kai Tietz   <kai.tietz@onevision.com>
>
>         * splay-tree.h (libi_uhostptr_t, libi_shostptr_t): Adjust types
>         work-a-round whitespace problem in gcc gengtype.

I committed this for you following Diego's approval; I didn't
spot you in MAINTAINERS and the tree was broken.  I'll commit it
to sourceware too.

Normally the added ChangeLog entry wouldn't be needed (being in
same purpose and time as the previous one) but this time I think
it serves a particular purpose; there's no comment in the code
about this GTY peculiarness.

brgds, H-P
PS. and gengtype-lex.l should be fixed too, IMHO.

Update to splay-tree.h for 64-bit Windows host

[Nick Clifton]

Hi Guys,

  I have checked in the patch below as part of a wider patch to allow
  the binutils to be built on a 64-bit windows host.  It provides a
  64-bit windows alternative for the type of the splay_tree_key and
  splay_tree_value types.

Cheers
  Nick

include/ChangeLog
2007-07-12  Kai Tietz   <kai.tietz@onevision.com>

	* splay-tree.h (libi_uhostptr_t, libi_shostptr_t): New types,
	needed for WIN64 when a long is not wide enough for a pointer.
        (splay_tree_key, splay_tree_value): Use the new types.

Index: include/splay-tree.h
===================================================================
RCS file: /cvs/src/src/include/splay-tree.h,v
retrieving revision 1.13
diff -b -u -r1.13 splay-tree.h
--- include/splay-tree.h	10 May 2005 10:21:08 -0000	1.13
+++ include/splay-tree.h	18 Apr 2007 09:15:43 -0000
@@ -36,6 +36,14 @@
 
 #include "ansidecl.h"
 
+#ifndef _WIN64
+  typedef unsigned long int libi_uhostptr_t;
+  typedef long int libi_shostptr_t;
+#else
+  typedef unsigned long long libi_uhostptr_t;
+  typedef long long libi_shostptr_t;
+#endif
+
 #ifndef GTY
 #define GTY(X)
 #endif
@@ -44,8 +52,8 @@
    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 unsigned long int splay_tree_key;
-typedef unsigned long int splay_tree_value;
+typedef libi_uhostptr_t splay_tree_key;
+typedef libi_uhostptr_t splay_tree_value;
 
 /* Forward declaration for a node in the tree.  */
 typedef struct splay_tree_node_s *splay_tree_node;

Re: Update to splay-tree.h for 64-bit Windows host

[Richard Guenther]

On 7/12/07, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
>   I have checked in the patch below as part of a wider patch to allow
>   the binutils to be built on a 64-bit windows host.  It provides a
>   64-bit windows alternative for the type of the splay_tree_key and
>   splay_tree_value types.

Please revert this patch ASAP as it breaks bootstrap everywhere and I
don't see this
was tested or approved.

Richard.

Re: Update to splay-tree.h for 64-bit Windows host

[Kai Tietz]

> On 7/12/07, Nick Clifton wrote:
> > Hi Guys,
> >
> >   I have checked in the patch below as part of a wider patch to allow
> >   the binutils to be built on a 64-bit windows host.  It provides a
> >   64-bit windows alternative for the type of the splay_tree_key and
> >   splay_tree_value types.
> 
> Please revert this patch ASAP as it breaks bootstrap everywhere and I
> don't see this
> was tested or approved.
> 
> Richard.
> 

Hi,

It seems to be that gengtype is the reason why it fails, and it starts to 
magically work if the spaces before all "typedef"s  are removed. I don't 
know what it is, but I have a strong feeling, that the whitespace parsing 
in the lexer script of gengtype is the reason.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.

------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

Re: Update to splay-tree.h for 64-bit Windows host

[Andreas Schwab]

Kai Tietz <Kai.Tietz@onevision.com> writes:

> It seems to be that gengtype is the reason why it fails, and it starts to 
> magically work if the spaces before all "typedef"s  are removed. I don't 
> know what it is, but I have a strong feeling, that the whitespace parsing 
> in the lexer script of gengtype is the reason.

The lexer explicitly only matches declarations starting in column 1.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Update to splay-tree.h for 64-bit Windows host

[Jim Blandy]

Nick Clifton <nickc@redhat.com> writes:
>   I have checked in the patch below as part of a wider patch to allow
>   the binutils to be built on a 64-bit windows host.  It provides a
>   64-bit windows alternative for the type of the splay_tree_key and
>   splay_tree_value types.

Out of curiosity --- what would it cost to make splay tree keys always
64 bits long?  I needed a splay tree indexed by 64-bit addresses for
GDB; I made it go, but it was a pain.

Re: Update to splay-tree.h for 64-bit Windows host

[Ian Lance Taylor]

Nick Clifton <nickc@redhat.com> writes:

> +#ifndef _WIN64
> +  typedef unsigned long int libi_uhostptr_t;
> +  typedef long int libi_shostptr_t;
> +#else
> +  typedef unsigned long long libi_uhostptr_t;
> +  typedef long long libi_shostptr_t;
> +#endif

I think we should instead use a configure test to see whether
<stdint.h> exists and defines uintptr_t and intptr_t.  We should use
those when they exist.  If they don't, we should do something like

#ifdef __GNUC__
typedef unsigned int libi_uhostptr_t __attribute__ ((mode (pointer)));
typedef int libi_shostptr_t __attribute__ ((mode (pointer)));
#else
typedef unsigned long long libi_uhostptr_t;
typedef long long libi_shostptr_t;
#endif

Ideally we don't have to test _WIN64 at all.

Ian

Re: Update to splay-tree.h for 64-bit Windows host

[Ian Lance Taylor]

Ian Lance Taylor <iant@google.com> writes:

> Nick Clifton <nickc@redhat.com> writes:
> 
> > +#ifndef _WIN64
> > +  typedef unsigned long int libi_uhostptr_t;
> > +  typedef long int libi_shostptr_t;
> > +#else
> > +  typedef unsigned long long libi_uhostptr_t;
> > +  typedef long long libi_shostptr_t;
> > +#endif
> 
> I think we should instead use a configure test to see whether
> <stdint.h> exists and defines uintptr_t and intptr_t.  We should use
> those when they exist.  If they don't, we should do something like
> 
> #ifdef __GNUC__
> typedef unsigned int libi_uhostptr_t __attribute__ ((mode (pointer)));
> typedef int libi_shostptr_t __attribute__ ((mode (pointer)));
> #else
> typedef unsigned long long libi_uhostptr_t;
> typedef long long libi_shostptr_t;
> #endif
> 
> Ideally we don't have to test _WIN64 at all.

Oh, I see, these types need to be large enough to hold a pointer or
any scalar type, even HOST_WIDE_INT which can be "long long".  This is
kind of ugly.  I think this interface needs an overhaul.

Ian