<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Then I think the <span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">bugzilla [1] you mentioned before should be updated? After all, it's not a bug,</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:arial,sans-serif">it's undefined behavior. If so, would you mind to update the link?</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[1] <a href="https://bugs.llvm.org/show_bug.cgi?id=17299" style="white-space:pre-wrap;font-family:arial,sans-serif">https://bugs.llvm.org/show_bug.cgi?id=17299</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">chenwj</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-21 15:59 GMT+08:00 Shiva Chen via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Hubert and Liu Hao,<br>
<br>
Thanks for your guidance and make the question more clear.<br>
When the value is not stored back into the bit-field member, it will<br>
involve integer promotion.<br>
The integer promotion rule for bit-filed defined in C99 <a href="http://6.3.1.1/2" rel="noreferrer" target="_blank">6.3.1.1/2</a>.<br>
However, the integer promotion rule for other implementation-defined<br>
bit-field type<br>
(width wider than int such as unsigned long long bit field type) was not clear.<br>
So the question become should the implementation-defined bit-field<br>
type do the promotion.<br>
GCC choose not to and Clang will.<br>
There is some discussion in<br>
<a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_315.htm" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg14/www/docs/dr_315.htm</a><br>
As Hubert said, the answer will determine until the C standard mention<br>
the rule for implementation-defined bit-field type.<br>
<div class="HOEnZb"><div class="h5"><br>
2017-04-21 2:47 GMT+08:00 Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com">hubert.reinterpretcast@gmail.<wbr>com</a>>:<br>
> On Thu, Apr 20, 2017 at 10:41 AM, Liu Hao <<a href="mailto:lh_mouse@126.com">lh_mouse@126.com</a>> wrote:<br>
>><br>
>> On 2017/4/20 19:20, Hubert Tong wrote:<br>
>>><br>
>>> It is hardly clear that the rvalue is of type unsigned long long (and<br>
>>> not some special bit-field type).<br>
>>> See <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1260.htm" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg14/www/docs/n1260.htm</a>.<br>
>>> I have been unable to find further discussion of the issue after<br>
>>> <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1270.pdf" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg14/www/docs/n1270.pdf</a>.<br>
>><br>
>><br>
>> You are right. Let's assume such an implementation exists, and despite<br>
>> that type, the result doesn't change: The (indeterminate) value is merely<br>
>> truncated earlier, yielding the same value after it is stored into the<br>
>> bit-field member.<br>
><br>
> Where the implementation divergence occurs is when the value is not stored<br>
> back into the bit-field member.<br>
><br>
>><br>
>><br>
>> I also doubt the existence of such an implementation: <a href="http://6.7.2.1/4" rel="noreferrer" target="_blank">6.7.2.1/4</a> doesn't<br>
>> say bit-field types need exist. Their occurrence also lead to problems:<br>
>> Would people benefit from it? What will happen if such an rvalue is passed<br>
>> to a function taking variable arguments? What will `sizeof(it+1)` where `it`<br>
>> has a bit-field type?<br>
><br>
> I agree that it leads to problems. This is the reason why I had the cast to<br>
> unsigned long long in my code example (which does demonstrate the existence<br>
> of such an implementation, namely GCC): because, without the cast, the<br>
> argument may not match with the conversion specification.<br>
><br>
> I think answering these questions is a job for WG 14 (the C committee).<br>
><br>
>><br>
>><br>
>><br>
>> --<br>
>> Best regards,<br>
>> LH_Mouse<br>
>><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Wei-Ren Chen (陳韋任)<br>Homepage: <a href="https://people.cs.nctu.edu.tw/~chenwj" target="_blank">https://people.cs.nctu.edu.tw/~chenwj</a></div></div></div>
</div>