This is the mail archive of the
mailing list for the GCC project.
Re: __intN patch 3/5: main __int128 -> __intN conversion.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 21 Aug 2014 22:24:51 +0000
- Subject: Re: __intN patch 3/5: main __int128 -> __intN conversion.
- Authentication-results: sourceware.org; auth=none
- References: <201408132211 dot s7DMBGBu016387 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1408212030310 dot 16900 at digraph dot polyomino dot org dot uk> <201408212123 dot s7LLNPIQ018746 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1408212131060 dot 16900 at digraph dot polyomino dot org dot uk> <201408212216 dot s7LMGAbC020403 at greed dot delorie dot com>
On Thu, 21 Aug 2014, DJ Delorie wrote:
> > Maybe you need to refactor __glibcxx_digits so there is a version
> > taking the bitsize as an argument rather than using sizeof(T) *
> > __CHAR_BIT__, but that should be the only change needed to handle
> > such types with the existing macros.
> Since the other macros use this macro, we'd need a complete second set
> of macros just for the __intN types anyway, each of which takes a
Well, the existing macros would be defined in terms of the new ones.
> bitsize and passes it down. Since gcc already knows all the right
> answers for the __intN types and needs to emit other macros for them
> anyway, where's the benefit?
The more predefined macros there are, the more impact on startup time
(though I don't have any specific figures).
Joseph S. Myers