--std vs __intN

[Marc Glisse]

On Thu, 5 Jun 2014, DJ Delorie wrote:

> Currently, __int128 is disabled if __STRICT_ANSI__ via --std.
>
> I'm working on making __int<N> generic within gcc, to support targets
> that have non-standard type sizes (msp430's pointer is 20 bits).  This
> means, for example, that size_t and sizeof(void*) may be one of these
> __int<N> types.
>
> This means if __int<N> is disabled via --std, most of the standard
> library breaks because the pointer type isn't listed in any of the
> headers' templates.
>
> If I *don't* disable __int<N> when --std says to, some of the
> testsuite tests - which test for that case - fail.
>
> What to do?

There have been discussions in the past about when to enable __int128 
support in the library. In my (non-maintainer) opinion, we should test 
__SIZEOF_INT128__ (or whatever similar macro you are going to introduce) 
so it is entirely up to the compiler to decide if __int128 will be 
available and the library just follows that decision. If the compiler 
allows using __int128, removing the std::abs overload doesn't help much. 
_GLIBCXX_USE_INT128 is not that relevant, at best it may indicate if rtti 
information is available for __int128 in libstdc++.{a,so}. Note that the 
standard allows extended integer types (even if we don't call __int128 
that for various reasons), it isn't that much of an extension. => fix the 
testsuite (and if necessary use __extension__ to avoid warnings).

Otherwise, you are going to need yet another macro to tell the library if 
it should bypass the strict ansi test... Unless size_t is the only type 
for which this is likely to happen? Then we could use some template stuff 
to check if size_t belongs to the list unsigned int/unsigned long/... and 
overload / specialize for it if not. In practice, that would likely be 
creating a __unique_size_t typedef which is size_t if unique and a dummy 
type if not, and always specializing for it. For overloading we have a bit 
more choice.

-- 
Marc Glisse