<div dir="ltr"><div>+      if ((LHSIsNull && !RHSIsNull) ||</div><div>+          (LCanPointeeTy->isIncompleteOrObjectType() &&</div><div>+           RCanPointeeTy->isVoidType()))</div><div><br></div><div>I don't think this is right: isIncompleteOrObjectType returns true for 'void', but the C standard says we do no conversions if both types are some flavour of void*. It also returns false for pointer-to-function types, which we support here as an extension. Also, you should handle the case where one operand is (void*)0 and the other operand is T* and non-null. Per the C standard, first we convert the null pointer to the other type, and *then* we convert towards the void* type (if it's still present), so in this case we convert to T* not to void*.</div><div><br></div><div>Also, I think you still need an implicit conversion here if the address space is different, even if nothing else is (but I don't know which direction we should convert in that case).</div><div><br></div><div>Please also provide some CodeGen tests showing that we do the right thing here, in particular if the address spaces differ.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 15, 2014 at 7:24 AM, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@bugseng.com" target="_blank">abramo.bagnara@bugseng.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ping.<br>
<br>
Il 07/09/2014 14:44, Abramo Bagnara ha scritto:<br>
<div class="HOEnZb"><div class="h5">> Il 07/09/2014 13:05, Abramo Bagnara ha scritto:<br>
>> Il 07/09/2014 05:25, Richard Smith ha scritto:<br>
>>> On Sat, Sep 6, 2014 at 3:27 AM, Abramo Bagnara<br>
>>> <<a href="mailto:abramo.bagnara@bugseng.com">abramo.bagnara@bugseng.com</a> <mailto:<a href="mailto:abramo.bagnara@bugseng.com">abramo.bagnara@bugseng.com</a>>> wrote:<br>
>>><br>
>>>     Ping<br>
>>><br>
>>>     Il 04/09/2014 15:13, Abramo Bagnara ha scritto:<br>
>>>     ><br>
>>>     > For the following source<br>
>>>     ><br>
>>>     > void f() {<br>
>>>     >   char *p;<br>
>>>     >   const char *cp;<br>
>>>     >   p == cp;<br>
>>>     >   p != cp;<br>
>>>     >   p < cp;<br>
>>>     >   p <= cp;<br>
>>>     >   p > cp;<br>
>>>     >   p >= cp;<br>
>>>     >   p - cp;<br>
>>>     > }<br>
>>>     ><br>
>>>     > clang (unexpectedly for me) emits an implicit cast from const char<br>
>>>     * to<br>
>>>     > char * (i.e. it remove a qualifier) for all the relational and<br>
>>>     equality<br>
>>>     > operator, but it (expectedly) does not emit one for the subtraction.<br>
>>>     ><br>
>>>     > AFAIK the C standard does not require any conversion for<br>
>>>     relational and<br>
>>>     > equality operator (just like for subtraction).<br>
>>>     ><br>
>>>     > Do we have a reason to add the implicit casts or it is a bug?<br>
>>><br>
>>><br>
>>> It seems like a minor convenience to have an AST invariant that both<br>
>>> operands are of the same type here, but I expect we could remove these<br>
>>> implicit casts without any significant repercussions; I'd be mildly in<br>
>>> favor of doing that since it improves AST fidelity.<br>
>><br>
>> I've attached a patch doing that.<br>
>><br>
>> Ok to commit?<br>
><br>
> I've attached a patch that follows better what standard requires and<br>
> that previously was not done. I've also weakened an assertion to avoid<br>
> to have an exceedingly complex condition.<br>
><br>
><br>
<br>
<br>
--<br>
Abramo Bagnara<br>
<br>
BUGSENG srl - <a href="http://bugseng.com" target="_blank">http://bugseng.com</a><br>
mailto:<a href="mailto:abramo.bagnara@bugseng.com">abramo.bagnara@bugseng.com</a><br>
</div></div></blockquote></div><br></div>