Re: 64-bit obstack support

[Alan Modra <amodra at gmail dot com>]

On Wed, Jul 16, 2014 at 08:04:03AM -0700, Richard Henderson wrote:
> On 07/16/2014 01:04 AM, Alan Modra wrote:
> > - on 64-bit targets supported by glibc, a size_t parameter (at least
> >   for the first or second parameter) or return from a function, is
> >   passed in the same register as an int.  I checked aarch64, alpha,
> >   mips64, powerpc64, s390x, sh64, sparc64, tilegx, x64_64.
> 
> It really depends on how the 64-bit target passes 32-bit values.
> 
> For alpha and mips64, 32-bit values are always sign-extended.  For ppc64 and
> s390x, 32-bit values are extended according to the sign of the type.  These
> targets are thus in the same boat as 32-bit targets, where we're safe unless
> the values are large.
> 
> But some 64-bit targets allow garbage in the high bits when passing a 32-bit
> parameter.  I believe this applies to aarch64, sparc64, ia64 and x86_64.  (It
> won't be visible often for aarch64 and x86_64, because of how 32-bit operations
> zero the high bits, but it can happen.)
> 
> For this later set of targets, it's not safe nor abi compatible to widen an int
> parameter to size_t.

Huh, you're correct.  I was focusing more on the case where a binary
compiled using a new obstack.h was dynamically linking an old libc,
but the other case of an old binary dynamically linked to a new libc
is a problem if the high bits can be garbage.  They weren't with the
simple testcase I used (constant value and compiled with mainline
gcc), but that doesn't prove anything..

Thanks!  And thanks to Joseph for pointing me at gnulib.

-- 
Alan Modra
Australia Development Lab, IBM