Bug 33378 - [4.3 regression] Recent gcc 4.3 snapshots think comparison operators are ambiguous
Summary: [4.3 regression] Recent gcc 4.3 snapshots think comparison operators are ambi...
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-10 14:11 UTC by bero
Modified: 2007-09-17 17:22 UTC (History)
3 users (show)

See Also:
Host: i586-pc-linux-gnu
Target: i586-pc-linux-gnu
Build: i586-pc-linux-gnu
Known to work: 3.4.0 4.0.0 4.2.0 4.2.1
Known to fail: 4.3.0
Last reconfirmed:


Attachments
test case (259 bytes, text/x-c++src)
2007-09-10 14:11 UTC, bero
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bero 2007-09-10 14:11:09 UTC
The attached test case has 2 code branches (#ifdef BREAKME and #ifndef BREAKME) that are treated as identical in all prior gcc versions.

4.3 snapshots barf with:

gcc-4.3-testcase.cpp: In function 'int main()':
gcc-4.3-testcase.cpp:28: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
gcc-4.3-testcase.cpp:14: note: candidate 1: bool operator==(const junk&, const char*)
gcc-4.3-testcase.cpp:7: note: candidate 2: bool junk::operator==(const foo&) const


since even in the BREAKME version, no implicit casting is involved, I tend to think older gcc versions are right.
Comment 1 bero 2007-09-10 14:11:45 UTC
Created attachment 14184 [details]
test case

Add test case
Comment 2 Paolo Carlini 2007-09-17 17:22:20 UTC
I can't reproduce the problem with current (128551) mainline. Likely a transient issue, otherwise, please reopen.