This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: PATCH: libffi vs. SPARC (again)
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Jeff Sturm'" <jsturm at one-point dot com>, Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: tromey at redhat dot com, java-patches at gcc dot gnu dot org, green at redhat dot com
- Date: Fri, 16 Nov 2001 10:30:30 -0800
- Subject: RE: PATCH: libffi vs. SPARC (again)
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> That's ugly, for a library that's intended to be portable. I think we
> could declare the return value "long" instead and it should
> work almost
> anywhere.
...except MIPS N32 and win64 and possibly some others.
Is ptrdiff_t a better choice? Hopefully that's defined to be "long long" on
win64. That leaves MIPS N32. (I would guess the HP/UX 32 bit ABI on
Itanium behaves like MIPS N32 in this regard. The same may or may not be
true for the 32 bit ABI on recent PA-RISC machines. I'm not sure. None of
these are currently supported by libffi.)
> It'd be better I guess if libffi supplied a
> typedef for this.
Yes.
>
> > Types that are equal/larger than int will be
> > stored in the native way. As long as all 64-bit CPUs are
> little endian
> > then there is no problem! Or am I missing something?
>
> Hans pointed out that sparc64 is big-endian. (There may be
> others... does
> anyone run ia64 in big-endian mode?)
HP/UX on Itanium is big-endian. It's currently not supported by libffi,
though it would be nice if that changed eventually.
Hans