This is the mail archive of the
mailing list for the GCC project.
Re: __intN patch 3/5: main __int128 -> __intN conversion.
- From: DJ Delorie <dj at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 21 Aug 2014 18:16:10 -0400
- 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>
> I don't see any corresponding HOST_BITS_PER_WIDE_INT test for __int128
> being removed (and anyway HOST_BITS_PER_WIDE_INT is now always 64, so such
> a test for __int128 would be dead code).
It was there when I started the patch, honest! :-)
> > For each __int<N> we need to provide an __INT<N>_MIN__ and
> > __INT<N>_MAX__, just like for "char" we provide __CHAR_MIN__ and
> > __CHAR_MAX__.
> No, those are provided for use by <limits.h>, which only covers standard C
> types (and in particular does not cover __int128).
> 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
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?
Also, consider that the specialization for all the other types is
duplicated in full, I'm already using less source code for my 1..4
types than the library would have used for its 1..4 types ;-)