<div dir="ltr">Richard - perhaps you could take a look at this diagnostic quality issues/possible inconsistency?<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 17, 2016 at 11:12 AM Iurii via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everybody,<br>
<br>
I'm suffering from an annoying warning. Here's an example to quickly reproduce it:<br>
<br>
    #include <stdio.h><br>
    #include <stdint.h><br>
    #include <inttypes.h><br>
<br>
    typedef union _bf<br>
    {<br>
        struct<br>
        {<br>
            uint32_t field1:2;<br>
            uint32_t field2:30;<br>
        } fields;<br>
        uint32_t raw;<br>
    } bf;<br>
<br>
    int main(int argc, char *argv[])<br>
    {<br>
        printf("0x%" PRIx32 "\n"<br>
               "0x%" PRIx32 "\n",<br>
                ((bf){ .fields.field1 = -1 }).raw, //Warning<br>
                ((bf){ .raw = -1 }).raw );         //No warning<br>
        return 0;<br>
    }<br>
<br>
Compilation: clang -std=c99 -m32 -O2 -o test test.c<br>
<br>
Result: test.c:19:37: warning: implicit truncation from 'int' to bit-field changes value from -1 to 3<br>
<br>
Could someone, please, explain me, why the warning is produced? The C99 standard is very clear about the behaviour<br>
with respect to the value of field1 (the value of raw after assigning to field1 is implementation-defined, but that's<br>
a different story), and it is unambiguous:<br>
<br>
6.3.1.3 paragraph 2<br>
"if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum<br>
value that can be represented in the new type until the value is in the range of the new type"<br>
<br>
6.7.2.1 paragraph 9:<br>
"A bit-field is interpreted as a signed or unsigned integer type consisting of the specified number of bits"<br>
<br>
So field1 is an unsigned integer consisting of 2 bits. The maximum value that it can store is 2^2-1 . In order to<br>
assign -1 to field1 2^2-1+1 must be added to -1. The result is therefore well-defined to be 3. So as long as assigning<br>
-1 to any standard unsigned integer does not produce any warning, I see no reason behind producing it for unsigned<br>
bit-fields. Especially because this is the most convenient way to set all bits in a bit-field. A single-bit bit-field<br>
would be a somewhat special case for assigning -1, but I'd prefer to not have the warning in this case as well.<br>
<br>
Kind regards<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>