This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)
On Fri, 15 Jun 2012, Mike Stump wrote:
> On Jun 15, 2012, at 2:46 PM, Joseph S. Myers wrote:
> > HOST_WIDE_INT is an abstraction about the *target*; the target determines
> > the required properties. The salient properties include:
> >
> > * At least as wide as target address space.
>
> The first person to do a 128 bit address support isn't going to
> appreciate all the work they are going to have to do. With some luck,
> before then, we will have switched to C++ and engineered in some
> prettier interfaces that will just work with no changes. Today, it
> would be a major pain.
Well, you'll want 128-bit HOST_WIDE_INT to manipulate object sizes etc.
for a 128-bit target.
Say the compiler used for the host is GCC. If the host is 64-bit, you
have __int128 and unsigned __int128 available (with older GCC, __int128_t
and __uint128_t). There are just a couple of problems with those types,
one a technical standards issue and one more serious as a practical issue:
* They are sui generic types that act quite like integer types but aren't
actually integer types, because of the host ABI defining intmax_t as
64-bit.
* They lack any printf support (at least with glibc), and such support is
needed by GCC for HOST_WIDE_INT.
Given control over the host C library, both issues could be addressed by
changing intmax_t on the host to 128 bits - printf %j formats would then
be appropriate for 128-bit types. (You'd need a host GCC change as well
to define an integer constant suffix for 128-bit constants.) That
certainly ought to be practical in glibc with symbol versioning if desired
- no worse than the way various architectures moved to 128-bit long
double.
You'd probably also find places in GCC that assume that HOST_WIDE_INT is
either 32-bit or 64-bit, but I expect it would be straightforward to
adjust those to support 128-bit as well.
True, C++ may make it possible to use something other than a built-in
integer-like type of the host compiler, but I don't think that's needed
for this.
(I'm not particularly concerned about 32-bit host support for this
hypothetical 128-bit target; anyway, it should be practical to support
__int128 for 32-bit systems, with some work on the libgcc side of things.)
> > * Constants for the target can be represented in at most two
> > HOST_WIDE_INT.
>
> This is nice in theory but no longer true for some of us. :-(
This could also reasonably be cleaned up separately from other uses of
HOST_WIDE_INT. Maybe what's really wanted is some abstraction for wide
target constants - which usually would be much like double-int.[ch], but
for targets that need it would be larger.
Certainly the const_int / const_double division - where const_double
represents *either* wide integers *or* floating-point constants - is an
ugly interface, and it would be better for integers of whatever size to be
const_int and const_double only to be floating point.
--
Joseph S. Myers
joseph@codesourcery.com