(This is the root cause of PR 57465, but I have a workaround for the library.) template<typename T> constexpr bool is_pointer(const T*) { return true; } template<typename T> constexpr bool is_pointer(const T&) { return false; } using F = void(); constexpr F* f = nullptr; static_assert( is_pointer(f), "function pointer is a pointer" ); G++ fails the static assertion: t.cc:15:1: error: static assertion failed: function pointer is a pointer static_assert( is_pointer(f), "function pointer is a pointer" ); ^ The first function template should be instantiated as bool is_pointer(F*) but instead deduction fails because: types 'const T' and 'F {aka void()}' have incompatible cv-qualifiers Note deduction succeeds with an explicit template argument: template<typename T> constexpr bool is_pointer(const T*) { return true; } using F = void(); constexpr F* f = nullptr; constexpr bool pass = is_pointer<F>(f); constexpr bool fail = is_pointer(f);
I think this observation was the reason why I filed: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1584 Notice that albeit the current CWG issue status contains a P/R, there is indication for being some contradiction to the assertions made in www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#503 (I have posted this to the CWG committee recently)
Ah yes, thanks!
DR1584 is Ready.
Author: paolo Date: Wed Jul 9 21:23:06 2014 New Revision: 212410 URL: https://gcc.gnu.org/viewcvs?rev=212410&root=gcc&view=rev Log: /cp 2014-07-09 Paolo Carlini <paolo.carlini@oracle.com> DR 1584 PR c++/57466 * pt.c (check_cv_quals_for_unify): Implement resolution, disregard cv-qualifiers of function types. /testsuite 2014-07-09 Paolo Carlini <paolo.carlini@oracle.com> DR 1584 PR c++/57466 * g++.dg/template/pr57466.C: New. * g++.dg/cpp0x/pr57466.C: Likewise. * g++.dg/template/unify6.C: Update. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr57466.C trunk/gcc/testsuite/g++.dg/template/pr57466.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/unify6.C
Fixed for 4.10.
Author: paolo Date: Fri Aug 15 16:23:47 2014 New Revision: 214027 URL: https://gcc.gnu.org/viewcvs?rev=214027&root=gcc&view=rev Log: /cp 2014-08-15 Paolo Carlini <paolo.carlini@oracle.com> PR c++/62072 Revert: 2014-07-09 Paolo Carlini <paolo.carlini@oracle.com> DR 1584 PR c++/57466 * pt.c (check_cv_quals_for_unify): Implement resolution, disregard cv-qualifiers of function types. /testsuite 2014-08-15 Paolo Carlini <paolo.carlini@oracle.com> PR c++/62072 Revert: 2014-07-09 Paolo Carlini <paolo.carlini@oracle.com> DR 1584 PR c++/57466 * g++.dg/template/pr57466.C: New. * g++.dg/cpp0x/pr57466.C: Likewise. * g++.dg/template/unify6.C: Update. * g++.dg/cpp0x/sfinae52.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae52.C Removed: trunk/gcc/testsuite/g++.dg/cpp0x/pr57466.C trunk/gcc/testsuite/g++.dg/template/pr57466.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/unify6.C
Patch reverted, unfortunately.
Still working on this.
GCC 5.1 has been released.
GCC 5.2 is being released, adjusting target milestone to 5.3.
GCC 5.3 is being released, adjusting target milestone.
I'm having another look at this, and the last comments added to DR1584 and coming to the conclusion that gcc probably doesn't need further work, in particular the patch that I had to revert pointed to a real issue. Other comments?
GCC 5.4 is being released, adjusting target milestone.
I agree that G++ seems to be correct according to the revised direction.
Great. I'm going to double check with Jason before resolving the bug.
Shall we definitely close this, then?
Fine by me. EDG agrees with GCC, but Clang accepts the original example. I guess they'll change when 1584 gets resolved.
Thanks Jon. It occurs to me that bugs depending on DRs not yet resolved normally are suspended. Let's do that here too.
(In reply to Jonathan Wakely from comment #17) > Fine by me. > > EDG agrees with GCC, but Clang accepts the original example. I guess they'll > change when 1584 gets resolved. clang started to reject in clang 7.0.0. Is there anything else that needs to be done?
The core issue is still open, for some reason.