Bug 40856 - numeric_limits not specialized for __int128_t or __uint128_t
Summary: numeric_limits not specialized for __int128_t or __uint128_t
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.4.1
: P3 enhancement
Target Milestone: 4.7.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-25 15:02 UTC by John Salmon
Modified: 2022-03-03 16:01 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-05-25 21:03:55


Attachments
Draft patch (1.28 KB, patch)
2010-02-18 14:10 UTC, Paolo Carlini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Salmon 2009-07-25 15:02:30 UTC
salmonj@drdblogin6.en.desres$ cat numeric128.cpp
#include <limits>
#include <iostream>

int main(int argc, char **argv){
    std::cout << "__int128_t is_specialized: " << std::numeric_limits<__int128_t>::is_specialized << "\n";
    std::cout << "__uint128_t is_specialized: " << std::numeric_limits<__uint128_t>::is_specialized << "\n";
    std::cout << "int is_specialized: " << std::numeric_limits<int>::is_specialized << "\n";
    return 0;
}
salmonj@drdblogin6.en.desres$ desres-cleanenv -m gcc/4.4.1-13/bin g++ --std=gnu++0x numeric128.cpp
salmonj@drdblogin6.en.desres$ a.out
__int128_t is_specialized: 0
__uint128_t is_specialized: 0
int is_specialized: 1
salmonj@drdblogin6.en.desres$
Comment 1 Paolo Carlini 2009-07-26 09:26:46 UTC
Certainly not a bug, at most an enhancement: in the current and future C++ Standards there is no mention of such types, of course.
Comment 2 Paolo Carlini 2009-12-17 12:09:23 UTC
Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly with Doug, he pretended to convince people that with extended SFINAE you can implement trivially *any* introspection trait, then somebody (me too) pointed out the accessibility issue and he said "bah, I don't care, accessibility is "broken" n  C++ anyway" ;)
Comment 3 Paolo Carlini 2009-12-17 12:10:37 UTC
Sorry, the last comment is for 40497.
Comment 4 Paolo Carlini 2010-02-18 14:10:25 UTC
Created attachment 19907 [details]
Draft patch
Comment 5 Paolo Carlini 2010-02-18 14:11:30 UTC
Gaby, I just attached a draft patch which essentially does what submitter requested, adds the two specializations. Shall we do this?
Comment 6 Paolo Carlini 2010-05-25 20:57:05 UTC
See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01912.html we are going to have __int128 and unsigned __int128.
Comment 7 Paolo Carlini 2011-09-19 11:05:10 UTC
But see: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01048.html. Thus, for the time being, I'm going to use __int128_t and __uint128_t in the implementation details: using the latter to define specializations instead of __int128 and unsigned __int128 should be undetectable from the user point of view.
Comment 8 paolo@gcc.gnu.org 2011-09-19 11:52:54 UTC
Author: paolo
Date: Mon Sep 19 11:52:49 2011
New Revision: 178969

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178969
Log:
2011-09-19  Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/40856
	* include/std/limits (numeric_limits<__int128_t>,
	numeric_limits<__uint128_t>): Add.
	* src/limits.cc:Define.
	* config/abi/pre/gnu.ver: Export.
	* include/ext/typelist.h (_GLIBCXX_TYPELIST_CHAIN16, 20): Add.
	* testsuite/util/testsuite_common_types.h (integral_types_gnu): Add
	(limits_tl): Use it.
	* testsuite/18_support/numeric_limits/requirements/
	constexpr_functions.cc: Likewise.
	* testsuite/18_support/numeric_limits/40856.cc: New.
	* testsuite/18_support/numeric_limits/dr559.cc: Extend.
	* testsuite/18_support/numeric_limits/lowest.cc: Likewise.
	* testsuite/18_support/numeric_limits/max_digits10.cc: Likewise.
	* testsuite/29_atomics/atomic/cons/assign_neg.cc: Adjust dg-error
	line numbers.
	* testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise.
	* testsuite/29_atomics/atomic_integral/cons/assign_neg.cc: Likewise.
	* testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise.
	* testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc:
	Likewise.
	* testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc:
	Likewise.
	* testsuite/29_atomics/atomic_integral/operators/increment_neg.cc:
	Likewise.

Added:
    trunk/libstdc++-v3/testsuite/18_support/numeric_limits/40856.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/abi/pre/gnu.ver
    trunk/libstdc++-v3/include/ext/typelist.h
    trunk/libstdc++-v3/include/std/limits
    trunk/libstdc++-v3/src/limits.cc
    trunk/libstdc++-v3/testsuite/18_support/numeric_limits/dr559.cc
    trunk/libstdc++-v3/testsuite/18_support/numeric_limits/lowest.cc
    trunk/libstdc++-v3/testsuite/18_support/numeric_limits/max_digits10.cc
    trunk/libstdc++-v3/testsuite/18_support/numeric_limits/requirements/constexpr_functions.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc
    trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/increment_neg.cc
    trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h
Comment 9 Paolo Carlini 2011-09-19 11:54:59 UTC
Done.
Comment 10 zerotype 2012-10-22 12:21:22 UTC
Are there any plans to backport this fix to any versions earlier than 4.7? Ubuntu 12.04 LTS, which only has version 4.6, is likely to be around for quite a long time due to its support lifespan.
Comment 11 Jakub Jelinek 2012-10-22 12:41:32 UTC
That is not possible, it requires new exports from a shared library, which isn't possible without backporting also all other symbols added to libstdc++.so for GCC 4.7.
Comment 12 John Salmon 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$
Comment 13 Marc Glisse 2012-10-25 20:23:43 UTC
(In reply to comment #12)
> 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.

*If* that's what's wanted, defined(__SIZEOF_INT128__) is the right test (_GLIBCXX_USE_INT128 could use it in its definition).
Comment 14 Paolo Carlini 2012-10-25 20:28:30 UTC
I can't spend further time on this issue in the near future. If somebody wants to tweak the condition which enables the specializations, please just post a patch to the mailing list and ask for a review from one of the maintainers. I have no strong opinion either way.
Comment 15 Paolo Carlini 2012-10-25 21:35:57 UTC
Ah, a final punctualization in terms of general philosophy: I *suspect* that some people don't fully realize that the *default* mode is -std=gnu++98 *not* -std=c++98, thus there is always the implicit assumption that people moving to the new standard normally use -std=gnu++11, not -std=c++11, otherwise, even without considering the special integer types at issue here, they will soon miss quite a few gnu extension bits in many other areas. That's way, today, restricting these still quite special interest specializations to the strict mode still makes a lot of conservative sense to me. But, I repeat, I will not object to patches tweaking the condition and positively reviewed by fellow maintainers.
Comment 16 Paolo Carlini 2012-10-25 21:39:48 UTC
Of course I meant "restricting to the non-strict mode", you got the point.
Comment 17 Richard Biener 2012-12-07 09:19:52 UTC
Still not fixed, removing target milestone.
Comment 18 Paolo Carlini 2012-12-07 10:20:26 UTC
Was fixed for 4.7.0.