With the following command line:
[c:\hack]==► gcc -v -save-temps --pedantic -c a.cpp
Reading specs from /mingw/lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
cc1plus -E -quiet -v -iprefix ../lib/gcc/mingw32/3.4.2/ a.cpp -pedantic -o
a.ii
ignoring nonexistent directory
"../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2"
ignoring nonexistent directory
"../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32"
ignoring nonexistent directory
"../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward"
ignoring nonexistent directory "../lib/gcc/mingw32/3.4.2/../../../../include"
ignoring nonexistent directory "../lib/gcc/mingw32/3.4.2/include"
ignoring nonexistent directory
"../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
/mingw/include/c++/3.4.2
/mingw/include/c++/3.4.2/mingw32
/mingw/include/c++/3.4.2/backward
/mingw/include
/mingw/include
/mingw/lib/gcc/mingw32/3.4.2/include
/mingw/include
End of search list.
cc1plus -fpreprocessed a.ii -quiet -dumpbase a.cpp -auxbase a -pedantic
-version -o a.s
GNU C++ version 3.4.2 (mingw-special) (mingw32)
compiled by GNU C version 3.4.2 (mingw-special).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130924 as -o
a.o a.s
where a.cpp contains the following:
class A
{
public:
A( double );
operator long();
};
A operator% ( const A&, const A& );
void x()
{
A g(0);
double d = 1.2;
d = d % g; //Should report on ambiguous call
}
I get no complaint from gcc. However, the call is ambiguous according to the
ISO C++ 2003 Standard. The rationale follows:
1. The candidate functions are a) operator%(const A &, const A &) and b)
built-in operator % (arguments: both integral/enumeration)
2. Both candidates has the same # of parameters.
3. Implicit conversion sequences for each argument:
double->const A via copy-initializing a temporary const A
A->const A, Exact Match via reference binding and Qualification
Adjustment
double->integral/enumeration via floating-integral conversion
A->long via the User-Defined Conversion Sequence of Identity
Conversion->A::operator long() invocation->Identity Conversion
4. ICS1(non built-in): User-Defined Conversion Sequence
ICS2(non built-in): Qualification Adjustment
ICS1(built-in): Floating-integral conversion
ICS2(built-in): User-Defined Conversion Sequence
5. By 13.3.3.2,
ICS2(non built-in) represents a "better conversion sequence" than
ICS2(built-in): Standard v. User-Defined
ICS1(non built-in) represents a "worse conversion sequence" than
ICS1(built-in): User-Defined v. Standard
Therefore, neither operator invocation constitutes a "best viable function" and
the program is ill-formed.
I ran this by the people at EDG and received a reply agreeing with my analysis.
--
Summary: Overload Resolution Succeeds When Actually Ambiguous.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martinezfive at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33409
