This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: --std vs __intN
- From: DJ Delorie <dj at redhat dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 6 Jun 2014 16:34:17 -0400
- Subject: Re: --std vs __intN
- Authentication-results: sourceware.org; auth=none
- References: <201406060116 dot s561GQwY005060 at greed dot delorie dot com> <alpine dot DEB dot 2 dot 10 dot 1406060738220 dot 2168 at laptop-mg dot saclay dot inria dot fr> <201406061825 dot s56IPERL028941 at greed dot delorie dot com> <alpine dot DEB dot 2 dot 10 dot 1406062146280 dot 5945 at laptop-mg dot saclay dot inria dot fr>
> The USE macro may not be needed, making them equivalent to
> defined(MACRO_GIVING_THE_TYPE) seems good enough to me.
I was following the USE_INT128 macro style from before.
The other macros provide type, bitsize, min, max, and umax.
So going from six to five macros really isn't much of a savings in the
code, but it doesn't matter to me which way it is.
> In my opinion, we don't need to preserve that __STRICT_ANSI__ behavior.
That implies testsuite changes though...
> If someone writes __int128 without __extension__, they get a
> pedantic warning. I assume the same will be true with __intN
It should.
> If you have a compiler option so that __int20 is not available (the
> name is not recognized by front-ends),
That's up to the backends to decide, whether they support the
underlying mode or not. Even __int128 isn't supported if the backend
doesn't support TImode.