<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 21, 2017 at 6:00 AM, Phil King <span dir="ltr"><<a href="mailto:phil_king@rocketmail.com" target="_blank">phil_king@rocketmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The important thing here is the implementation defined behaviour.<br>
<br>
It is quite reasonable for GCC and Clang to have different behaviours. They should both document what behaviour has been implemented as an implementation is required to document how implementation defined behaviour has been implemented.<br></blockquote><div>It is compliant, and perhaps reasonable on a case-by-case basis; however, Clang "tries" to be GCC-compatible. At the level of implementation-defined (as opposed to unspecified or undefined) behaviour, I would expect that Clang would follow what GCC does.<br><br></div><div>In any case, the choice of whether to perform promotion on the bit-field types with "base type" and width such that the wording indicates that promotion does not occur is not implementation-defined behaviour.<br><br></div><div>What is implementation-defined is whether the use of, e.g., "unsigned long long" as the "base type" of a bit-field is a constraint violation.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Basically, don't expect code that relies on implementation defined behaviour tonne portable.<br>
<br>
This is one of the reasons why coding standards such as MISRA highlight such things.<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
> On 21 Apr 2017, at 08:59, Shiva Chen via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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></div></div></blockquote><div>It is unclear as to the intent of the committee; however, the wording has:<br></div><div>"All other types are unchanged by the integer promotions."<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> So the question become should the implementation-defined bit-field<br>
> type do the promotion.<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> 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>
><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>
<br>
</div></div></blockquote></div><br></div></div>