Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[Ian Lance Taylor <iant at google dot com>]

FX Coudert <fxcoudert@gmail.com> writes:

> The Fortran 2003 standard requires that Fortran compilers be able to
> know, at compile-time, what size the various int_fastN_t types have
> on the target (for N = 8, 16, 32 and 64). I've discussed that issue
> before on this list, and was told it's a known issue, tracked as PR
> 448. For 4.3, we ignored the issue; for 4.4, I'd like to move forward
> and propose some way to go. Here's the idea I've been following: it's
> not excellent, but I don't think there are many alternatives
> available!
>
> I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on
> for 16, 32 and 64): they would be defined to -1 in defaults.h
> (meaning that int_fastN_t types are not available), and independent
> targets can redefine them. Front-ends and the middle-end can then use
> it if they feel like it. Attached is a patch implementing this idea,
> including target definitions for linux, darwin, mingw, AIX, IRIX,
> OpenBSD, Solaris 2.10.
>
> Comments on that first draft are welcome. I know it's a hard issue
> and most possible fixes are more hacks than fixes, but the starting
> point is that we really need it to work, and a system that covers 99%
> of cases is better than nothing.

I don't disagree with that, but I would also like to see something
that will not require changing every target for basic default
behaviour.

I'd like to suggest that in the absence of other information from the
tm.h file, for N in {8,16,32,64}, where N <= UNITS_PER_WORD *
BITS_PER_UNIT, we map int_fastN_t to int_fastM_t, where M ==
UNITS_PER_WORD * BITS_PER_UNIT.

Note that UNITS_PER_WORD need not be a constant, so this is slightly
harder to implement than your proposal.

Ian