[Bug c++/41958] [c++0x] bogus variadic partial ordering code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 stinkingmadgod at gmail dot com changed: What|Removed |Added CC||stinkingmadgod at gmail dot com --- Comment #11 from stinkingmadgod at gmail dot com --- DR1395 made it in C++17. template int f(T*...); // #1 template int f(const T&); // #2 f((int*)0); // Should select #1 past C++17, should be ambiguous prior C++17. // Selects #2 instead. This is still the behaviour for trunk https://godbolt.org/z/ucAUHw
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #10 from frankhb1989 at gmail dot com --- The example from IS [temp.func.order]/5 (introduced by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3281.pdf) still fails. As per https://godbolt.org/z/6wq5Hx (from https://www.zhihu.com/question/55055208/answer/142424499), 4.6.4 is OK, but 4.7.1 is nonconforming. Not sure which change cause the behavior divergence; please confirm. (BTW, the original issue asked in the post is about PR 33807. It seems innocent. MSVC 15.8.2 does not have the operator== for allocator; not sure it is correct, but MSVC does reject the example in this issue correctly. Nevertheless, I wonder the status of LWG 2472 and whether the resolution of LWG 280 have some related effects.)
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2012-11-19 13:42:06 UTC --- (In reply to comment #8) The note describing the resolution of 1395 says preferring an omitted parameter over a parameter pack. omitted parameter here means no parameter. The second overload has a parameter, 'd'.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||zeratul976 at hotmail dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-18 13:41:32 UTC --- *** Bug 55373 has been marked as a duplicate of this bug. ***
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #4 from Nathan Ridge zeratul976 at hotmail dot com 2012-11-18 22:28:59 UTC --- I filed the same bug for clang, and I was pointed to DR1395 [1]. GCC and clang's behaviour are both in line with the resolution of this DR. I guess this can be closed as invalid then? [1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1395
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 00:21:29 UTC --- Oh yes, nice. I'm only a bit nervous because the status is still drafting but it looks like there is very solid agreement about the issue. Tomorrow I mean to add the testcase to the testsuite and close the PR.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-11-19 01:57:16 UTC --- No. The resolution of 1395 will not make the testcase in #1 valid, only the case where you have a degenerate overload, like templatetypename T, typename... Args int f(const T, Args...); templatetypename T int f(const T); The testcase in #1 should still be rejected as ambiguous.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-19 02:11:53 UTC --- I see...
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958
--- Comment #8 from Nathan Ridge zeratul976 at hotmail dot com 2012-11-19
03:49:39 UTC ---
(In reply to comment #6)
No. The resolution of 1395 will not make the testcase in #1 valid, only the
case where you have a degenerate overload, like
templatetypename T, typename... Args
int f(const T, Args...);
templatetypename T
int f(const T);
The testcase in #1 should still be rejected as ambiguous.
The note describing the resolution of 1395 says preferring an omitted
parameter over a parameter pack.
The way I read that, in the testcase in comment 1, the second overload has an
omitted parameter ('d'), and the first overload has a parameter pack, so
the secodn overload would be preferred.
Am I misreading it?
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2009-11-05 22:41:18 |2012-07-05 CC||redi at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 10:10:40 UTC --- That causes G++ to get the wrong results for the last two examples in 14.5.6.2 [temp.func.order] FWIW clang++ has exactly the same behaviour as G++
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
--- Comment #1 from jason at gcc dot gnu dot org 2009-11-05 22:41 ---
That is, I think this should be ambiguous since the WP says that unused default
args aren't considered in partial ordering (14.6.6.2):
templatetypename T, typename... Args
int f(const T, Args...);
templatetypename T
float f(const T, double d = 2);
float g() {
return f(17);
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-05 22:41:18
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958
