This is the mail archive of the
mailing list for the GCC project.
Re: How to use _Generic with bit-fields
- From: Wink Saville <wink at saville dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 24 Feb 2016 16:26:01 -0800
- Subject: Re: How to use _Generic with bit-fields
- Authentication-results: sourceware.org; auth=none
- References: <CAKk8iso7KLotY1WGwaO8FBvp27nFORAWdShqVGth=0Hrc+WVbQ at mail dot gmail dot com> <56C78A87 dot 4090601 at gmail dot com> <CAKk8isoF4gT_z9sscYmnetMZOCkaZUO0Gr9_sj7WQB86PEQxZg at mail dot gmail dot com> <56CBA6CC dot 8080709 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602230041500 dot 26576 at digraph dot polyomino dot org dot uk> <56CE03F4 dot 4040108 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602242103550 dot 23205 at digraph dot polyomino dot org dot uk> <CAKk8isri9vRzNGWUmWPqiFYnMpk_nPYMKoTJAa6BfKmYCFwggg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602242327000 dot 23205 at digraph dot polyomino dot org dot uk>
On Wed, Feb 24, 2016 at 3:38 PM, Joseph Myers <email@example.com> wrote:
> On Wed, 24 Feb 2016, Wink Saville wrote:
>> > (c) nothing defines semantics of conversion of out-of-range values to
>> > bit-fields other than treating the width as part of the type (or in the
>> > case of _Bool bit-fields, having the special wording to make it explicit
>> > that those have the semantics of _Bool not the semantics of an ordinary
>> > unsigned integer type with the specified number of bits).
>> I don't see where in the standard it says the width of a bit field is
>> part of the type.
>> I see In Section 126.96.36.199 paragraphs 9, 10, 11, 12 requires the compiler to know
>> the width, but I don't see where the width is part of the type.
>> Could you point me to the appropriate paragraph(s)?
> If you look at the London 2007 minutes
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1267.pdf> you'll see
> that at that time this was intended to be deliberately ambiguous, to
> support both C++ practice and the longstanding C intent as expressed in
> the responses to various C90 DRs (the difference, at that time, only
> mattering for implementation-defined bit-field types).
> The "interpreted as having a signed or unsigned integer type consisting of
> the specified number of bits" (paragraph 10), if applied for the purposes
> of interpreting other references to types in C11, has consequences
> including: (i) conversions to store a value in a bit-field follow the same
> rules as conversions to a normal integer type, (ii) a bit-field with width
> less than that of int also has integer conversion rank less than that of
> int, and so promotes to int under the integer promotions (even if the
> declared type is wider than int).
I found this very surprising, but the standard does seem to require this.
> (It also has the less intuitive
> consequences regarding bit-field types escaping from their bit-field
> context, as discussed in the present thread and elsewhere.)
> Without it being part of the type, making long:1 promote to int (as in
> C++) not long would require changes to the wording on promotions, and
> separate wording would be needed to make the results of assignments clear
> (and I'm not convinced that C++ has such wording in all cases where it is
Clang doesn't seem to need to have the width as part of the type. And by not
having it as part of the type _Generic works as expected on clang but doesn't
work on gcc.
Further more things like printing of "big" bit fields such as
unsigned long long int b:33 doesn't issue any warnings with -Wall on clang
but does on gcc. Also, the shifting weirdness doesn't occur on clang.
>From my perspective, as a user, I think these behaviors are gcc bugs.
If someone were to supply a patch that changed the behavior to match
what clang and apparently other compilers are doing, would you be likely
to accept it?
> Joseph S. Myers