[LLVMbugs] [Bug 20527] New: Clang incorrect applies conversion when built-in operator is selected by overload resolution

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20527

            Bug ID: 20527
           Summary: Clang incorrect applies conversion when built-in
                    operator is selected by overload resolution
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rs2740 at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

N3936 13.3.1.2 [over.match.oper]/p7 specifies that 

If a built-in candidate is selected by overload resolution, the operands of
class type are converted to the types of the corresponding parameters of the
selected operation function, except that the second standard conversion
sequence of a user-defined conversion sequence (13.3.3.1.2) is not applied.
Then the operator is treated as the corresponding built-in operator and
interpreted according to Clause 5.

In particular, only operands of class type are converted before the operator is
treated as a built-in and interpreted according to Clause 5, and even then the
second standard conversion sequence (after the user-defined conversion) is not
applied.

The following example is given in the standard:

struct X {
operator double();
};
struct Y {
operator int*();
};
int *a = Y() + 100.0; // error: pointer arithmetic requires integral operand
int *b = Y() + X(); // error: pointer arithmetic requires integral operand

However, clang 3.4 accepts this code, producing no error on either line.
http://coliru.stacked-crooked.com/a/25bcc0549a19921f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140804/370c7514/attachment.html>