[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t

john.salmon at deshaw dot com gcc-bugzilla@gcc.gnu.org
Thu Oct 25 20:12:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856

John Salmon <john.salmon at deshaw dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #12 from John Salmon <john.salmon at deshaw dot com> 2012-10-25 20:12:14 UTC ---
Somewhere along the way, the specializations for this bug and for some
related type_traits (make_signed, make_unsigned, is_integral) were
conditionalized with:

#if !defined(__STRICT_ANSI__) && defined(_GLIBCXX_USE_INT128)

I think the STRICT_ANSI condition is a mistake.  It has always been
the case that the availability of the __[u]int128_t types has been
independent of the value of __STRICT_ANSI__.  Similarly, the
specializations of numeric_limits and type_traits should be present
regardless of whether __STRICT_ANSI__ is in effect.  

The check for defined(_GLIBXX_USE_INT128) should be both necessary and
sufficient.

If I can declare a variable of a non-standard extension-type with some
compiler flags in effect, e.g., -std=c++11, then I should also be able
to get a sensible answer from std::numeric_limits and <type_traits>
with the same compiler flags.

This code should produce the same results with -std=g++11 and -std=c++11:

drdlogin0039$ cat strict128.cpp
#include <type_traits>
#include <limits>
#include <iostream>

int main(int , char **){
    __int128_t i;
    std::cout << "is_specialized: " <<
std::numeric_limits<__int128_t>::is_specialized << "\n";
    std::cout << "is_integral: " << std::is_integral<__int128_t>::value <<
"\n";
    return 0;
}
drdlogin0039$ g++ -std=gnu++11 strict128.cpp && ./a.out
is_specialized: 1
is_integral: 1
drdlogin0039$ g++ -std=c++11 strict128.cpp && ./a.out
is_specialized: 0
is_integral: 0
drdlogin0039$



More information about the Gcc-bugs mailing list