https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Patrick Palka changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |14.0
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Patrick Palka changed:
What|Removed |Added
CC||armagvvg at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:c1e54c82a9e1855499ef7bb8827540e6a097532b
commit r14-6221-gc1e54c82a9e1855499ef7bb8827540e6a097532b
Author: Jason Merrill
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
--- Comment #4 from Andrew Pinski ---
hmm, for the test in comment #0, GCC, ICC and MSVC all have the same behavior
of picking #2 while clang's result is the different one here where it says
operator- is ambiguous.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
--- Comment #3 from Ed Catmur ---
I believe this also causes gcc to reject (as ambiguous) the example in
[temp.func.order]/3:
struct A { };
template struct B {
template int operator*(R&); // #1
};
template int operator*(T&, R&);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
Jonathan Wakely changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499
--- Comment #1 from Johannes Schaub
2012-05-27 14:00:20 UTC ---
Sorry, GCC picks the same function (non-member) disregarding of the C++
Standards mode. The comments were a left-over from a clang bug report.
