Re: --std vs __intN

[DJ Delorie <dj at redhat dot com>]

> 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.

size_t is different because it's defined in terms of another type,
it's not a type that's exported from gcc directly.  So there are no
templates<size_t>, only templates<__int20> for example.  But it's not
just the "size_t" itself, but the implied type of the result of
pointers and pointer math, which *is* the __int20 type exported by
gcc.  I.e. the errors you get if the templates aren't specialized for
size_t have __int20 in them, not size_t or some other type.

To parameterize the libstdc++ stuff, I have gcc export these test
macros (and related ones as needed, which give the actual types and
sizes):

__GLIBCXX_USE_INT_N_0
__GLIBCXX_USE_INT_N_1
__GLIBCXX_USE_INT_N_2
__GLIBCXX_USE_INT_N_3
. . .

where each N_* is one of the __int<N> types, but with no guarantee
which is which (i.e. INT_N_0 might be __int20 with INT_N_1 being
__int128, etc)

So the question becomes... what additional conditions should be
required to set those macros?

For backwards compatibility, I suspect disabling the one for N=128
when __STRICT_ANSI__ would have been set should do it.  That leaves
the target-specific ones enabled to cover size_t.

An alternate option is to disable all but the one needed for size_t
which would be more strict, but as there are no targets with more than
one custom __intN I don't know what future problems this might cause.
For example, a port might have multiple pointer sizes, each with their
own __intN, which might not be obvious to the common section of gcc.