This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] change specific int128 -> generic intN
- From: DJ Delorie <dj at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 24 Jun 2014 01:40:22 -0400
- Subject: Re: [patch] change specific int128 -> generic intN
- Authentication-results: sourceware.org; auth=none
- References: <201404142303 dot s3EN3ONP009938 at greed dot delorie dot com> <201406211624 dot s5LGOFC8031566 at greed dot delorie dot com> <alpine dot DEB dot 2 dot 10 dot 1406211857280 dot 2124 at laptop-mg dot saclay dot inria dot fr>
> Since the test on __STRICT_ANSI__ is removed for all other uses, it would
> seem consistent to me to remove this one as well. Besides, you are already
> testing __GLIBCXX_USE_INT_N_0, which as far as I understand is protected
> by !flag_iso (with the exception of size_t).
Yup, I'll clean that up.
> > -#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_INT128)
> > + // Conditionalizing on __STRICT_ANSI__ here will break any port that
> > + // uses one of these types for size_t.
> > +#if defined(__GLIBCXX_USE_INT_N_0)
> > template<>
> > - struct __is_integral_helper<__int128>
> > + struct __is_integral_helper<__GLIBCXX_TYPE_INT_N_0>
>
> Since the check for __STRICT_ANSI__ is removed, do we need to add
> __extension__ in front of __GLIBCXX_TYPE_INT_N_0 to avoid warning with
> -Wsystem-headers?
I copied the code from the __int128 case, and it explicitly bypassed
-Wsystem-headers... so we don't have that problem. Not sure if we
*should* have that problem, but we didn't before... I can only assume
that either (1) someone found it too difficult to get __extension__ to
work right in all those cases, or (2) it's a bug. Or (3) for some
reason they decided to do it that way anyway. I don't know.
> That seems complicated. You just need to call emit_support_tinfo_1 on
> each of the types (see how fundamentals is used at the end of the
> function), no need to put everything in the array.
Sure, *now* you tell me that :-)
I can do it either way, but it's the same overhead to iterate through
the types. Shoving it into the array is a bit more future-proof, but
keeping the index in sync is a bit of work if the table ever changes.
Your choice ;-)