Re: [RFC][BZ #17943] Use long for int_fast8_t

[Joseph Myers <joseph at codesourcery dot com>]

On Sun, 8 Feb 2015, Ondřej Bílka wrote:

> Hi, as in bugzilla entry what is rationale of using char as int_fast8_t?
> 
> It is definitely slower with division, following code is 25% slower on
> haswell with char than when you use long.

Well, there are trade-offs with space in that if you use more cache for a 
larger type then that could make things slower; it's not automatically 
the case that a type that's faster for individual operations makes 
programs faster if it's used.

In any case, we need to be very wary of changing the size or alignment or 
C++ name mangling of any exported type in a public header, even if it 
doesn't affect existing executables / shared libraries because the type 
isn't involved in the ABIs of existing glibc functions.

In the present case, GCC knows about these types for each target, both so 
as to ensure <stdint.h> is available for freestanding compilations, and to 
provide the Fortran C bindings.  So if you did use different types for new 
glibc configurations, the GCC ports for those targets would also need to 
know.

This patch doesn't change inttypes.h.  If it passed testing, I suppose 
that means we are missing a testcase that all the inttypes.h format macros 
do work with the corresponding types (such a test would mainly be that the 
testcase builds OK with -Wformat -Werror rather than for the runtime 
execution).

-- 
Joseph S. Myers
joseph@codesourcery.com