<div dir="ltr">Thank you for your detailed explanation!<br>It would seem perfectly reasonable to define the behavior in this case, at least (and I suppose not only) to me.<br>Attila</div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-20 14:50 GMT+01:00 Aaron Ballman <span dir="ltr"><<a href="mailto:aaron.ballman@gmail.com" target="_blank">aaron.ballman@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 20, 2016 at 7:58 AM, Attila Török <<a href="mailto:torokati44@gmail.com">torokati44@gmail.com</a>> wrote:<br>
> I did not see that it was reapplied later, sorry.<br>
><br>
> With clang version 3.9.0 (tags/RELEASE_390/final) I get the warning in both<br>
> c11 and c++11 mode.<br>
> With clang version 4.0.0 (trunk 290146) (llvm/trunk 290118) it's gone in c11<br>
> mode, but still there in c++11.<br>
> The piece of code I tested it on:<br>
> <a href="https://gist.github.com/torokati44/37e6aca2d516cb7c3cb31b7ccf8a519e" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>torokati44/<wbr>37e6aca2d516cb7c3cb31b7ccf8a51<wbr>9e</a><br>
><br>
> In the part of the code affected by the patch, ED->getPromotionType() is<br>
> BuiltinType 'int', and Type is EnumType 'enum E'.<br>
> For these two types, Context.typesAreCompatible returns true in c11 mode,<br>
> but false in c++11 mode (regardless of which underlying type - or if any -<br>
> is specified).<br>
> I presume this is the intended behavior. And if so, how could the example<br>
> code be modified to make it warning-free in c++, while keeping the parameter<br>
> an enum, and not making it a simple int?<br>
<br>
</span>Yes, that behavior is intended. The answer to how to modify the code<br>
involves the C++ standards committee, though. [cstdarg.syn]p1 says, in<br>
part,<br>
<br>
The parameter parmN is the identifier of the rightmost parameter in<br>
the variable parameter list of the function definition (the one just<br>
before the ...). If the parameter parmN is of a reference type, or of<br>
a type that is not compatible with the type that results when passing<br>
an argument for which there is no parameter, the behavior is<br>
undefined.<br>
<br>
When typesAreCompatible() returns false, that means you are triggering<br>
UB with your code.<br>
<br>
The reason the C++ behavior differs from the C behavior when calling<br>
typesAreCompaible() is because type compatibility (as a language<br>
construct) is a C notion; in C++ this maps to "are the types the<br>
same", which is not true for an enum type and an int type (even with<br>
an explicit underlying type).<br>
<br>
However, there are questions as to whether this should be UB or not<br>
that I've raised with WG21 (I don't have a Core defect report for it<br>
yet though). For right now, the safest answer is: change the parameter<br>
to be an int, because that is definitely not UB. There may be a more<br>
satisfactory answer in the future.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Thank you,<br>
> Attila<br>
><br>
> 2016-12-19 18:36 GMT+01:00 Aaron Ballman <<a href="mailto:aaron.ballman@gmail.com">aaron.ballman@gmail.com</a>>:<br>
>><br>
>> On Fri, Dec 16, 2016 at 7:00 AM, Attila Török via Phabricator<br>
>> <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br>
>> > torokati44 added a comment.<br>
>> ><br>
>> > I see this has been reverted in r281612, but I can no longer access the<br>
>> > build log serving as a reason linked in the message:<br>
>> > <a href="https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg35386.html" rel="noreferrer" target="_blank">https://www.mail-archive.com/<wbr>cfe-commits@lists.llvm.org/<wbr>msg35386.html</a><br>
>> > We have a few false-positive warnings that (I think) would be silenced<br>
>> > by this change. I'm just wondering if something like this, if not this,<br>
>> > could be included anyway? Not critical of course, it just would be nice.<br>
>><br>
>> This patch was reapplied in r281632:<br>
>><br>
>><br>
>> <a href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160912/170772.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/cfe-commits/Week-of-<wbr>Mon-20160912/170772.html</a><br>
>><br>
>> Do you still have false positives even with that applied?<br>
>><br>
>> Thanks!<br>
>><br>
>> ~Aaron<br>
><br>
><br>
</div></div></blockquote></div><br></div>