<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 6, 2016 at 10:55 PM, George Burgess IV <span dir="ltr"><<a href="mailto:george.burgess.iv@gmail.com" target="_blank">george.burgess.iv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">george.burgess.iv added a comment.<br>
<span class="gmail-"><br>
> Although I think that users will expect atomic_add(unsigned int *, 5) to work.without error<br>
<br>
<br>
</span>Totally agree; I was just making sure that I understood the problem. :)<br>
<br>
I think, with a small tweak in semantics, we can make everything work without needing to patch existing code. Let me play around a little.</blockquote><div><br></div><div>It seems to me that we could handle this by ranking viable-but-ill-formed conversion sequences before non-viable ones in clang::isBetterOverloadCandidate. This problem is actually more general than __attribute__((overloadable)) in C -- there is one form of ill-formed implicit conversion sequence that we accept in C++ that leads to the same problem:</div><div><br></div><div>  void f(char*, int);</div><div>  void f(const char*, unsigned);</div><div>  void g() { f("foo", 0); }<br></div><div><br></div><div>Clang reports an ambiguity on line 3, but in C++11 onwards this code is valid because there is no implicit conversion sequence from a string literal to char*. (We provide one as an extension, and it's ranked worse than any other conversion.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D24113" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D24113</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>