This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix gcjh handling of most negative int/longs
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 23 May 2006 08:35:32 -0400
- Subject: Re: [PATCH] Fix gcjh handling of most negative int/longs
- References: <20060523113044.GM30682@devserv.devel.redhat.com> <17523.69.514495.907722@dell.pink>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, May 23, 2006 at 01:29:57PM +0100, Andrew Haley wrote:
> > On 64-bit hosts jint type is apparently 64-bit
>
> No.
>
> > (javaop.h has
> > #ifndef int32
> > #define int32 long
> > #endif
> > ...
> > typedef int32 jint;
>
> That's right. jint is 32 bit, always.
>
> > ), but the following hunk in print_field_info relies on it being
> > 64-bit. Either we could change jint to be always exactly 32-bit
> > type on all hosts, or we need something like the patch below,
> > otherwise headers generated by 64-bit gcjh generate warnings in 32-bit
> > compilation.
>
> jint is defined as
>
> typedef __java_int jint;
Only in libjava/gcj/javaprims.h, i.e. it has the right type in libjava.
But not in gcc/java, where it is typedefed to long.
Jakub