<div dir="ltr">I think what's happening is -1 has type int, then gets converted to unsigned, then assigned to the bit field.  As an unsigned value, the minimum number of bits required is the full bit width, resulting in the warning.  I am look further into this.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 9:08 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Richard - perhaps you could take a look at this diagnostic quality issues/possible inconsistency?<div><div class="h5"><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" target="_blank">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></div></div>
</blockquote></div><br></div>