This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][BZ #17943] Use long for int_fast8_t
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 9 Feb 2015 16:37:03 +0000
- Subject: Re: [RFC][BZ #17943] Use long for int_fast8_t
- Authentication-results: sourceware.org; auth=none
- References: <20150208110426 dot GA28729 at domone>
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
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
Joseph S. Myers