[cfe-dev] different signedness for bitfield 'char' and plain 'char'

[Richard Smith]

On Tue, Jul 30, 2013 at 12:12 PM, Robert Lytton <robert at xmos.com> wrote:

>  Hi Richard,
>
>
> > What standard? C++ requires that bit-fields have the same signedness as
> their underlying type. If 'char' is unsigned, then bit-fields of type
> 'char' are also unsigned.
> Sorry, I was thinking of the C99 standard.
> But I actually was half quoting c++ 2011 standard.
> Either way, I was wrong - but still not clear.
>
> The XCore ABI (currently implemented by the XCore llvm-gcc frontend)
> expects:
>
>     'char' to be unsigned.
>     but the bit field 'char' to be signed.
>
> Does this infringe the C99 & C++11 standards?
>

This is fine in C99, but not permitted by C++11 (and arguably, because the
relevant DR applied to all versions of C++, is also not permitted in any
earlier version of C++ either).

Note that the x86_64 ABI also claims that plain (neither signed nor
unsigned) bit-fields are unsigned, but it is simply wrong. Maybe the XCore
ABI document is wrong too?

I'll keep reading but I'm no lawyer.
>
> robert
>
> C++
> 9.6:p3
> It is implementation-defined whether a plain (neither explicitly signed
> nor unsigned) char, short, int or long bit-field is signed or unsigned.
>
> C99
> 6.2.5:p15
> The three types char, signed char, and unsigned char are collectively
> called the character types. The implementation shall define char to have
> the same range, representation, and behavior as either signed char or
> unsigned char.
> 6.7.2:p5
> Each of the comma-separated sets designates the same type, except that for
> bit-fields, it is implementation-defined whether the specifier int
> designates the same type as signed int or the same type as unsigned int.
> 6.7.2.1:p9
> A bit-field is interpreted as a signed or unsigned integer type consisting
> of the specified number of bits. 105
> 105) As specified in 6.7.2 above, if the actual type specifier used is int
> or a typedef-name defined as int, then it is implementation-defined whether
> the bit-field is signed or unsigned.
>
>
>  ------------------------------
> *From:* metafoo at gmail.com [metafoo at gmail.com] on behalf of Richard Smith [
> richard at metafoo.co.uk]
> *Sent:* 30 July 2013 19:19
> *To:* Robert Lytton
> *Cc:* cfe-dev at cs.uiuc.edu; benny.kra at gmail.com
> *Subject:* Re: [cfe-dev] different signedness for bitfield 'char' and
> plain 'char'
>
>  On Tue, Jul 30, 2013 at 10:51 AM, Robert Lytton <robert at xmos.com> wrote:
>
>>  Hi,
>>
>> I have altered isSignedCharDefault()  to make 'char' unsigned for the
>> xcore target too.
>> (The signedness of 'char' is an ABI issue as far a the standard is
>> concerned.)
>>
>> My problem now is that char-bitfields are also being made unsigned.
>> According to the standard the members of a bitfield are always signed
>> unless explicitly marked unsigned.
>>
>
>  What standard? C++ requires that bit-fields have the same signedness as
> their underlying type. If 'char' is unsigned, then bit-fields of type
> 'char' are also unsigned.
>
>
>>  Hence I need:
>>     'char' to be unsigned.
>>     but the bit field 'char' to be signed.
>>
>> viz:
>>     // ABI requires plain 'char' to be unsigned
>>     char c = (char)-1;
>>     assert(c >= 0);
>>
>>     // members of a bitfield are always signed unless explicitly marked
>> unsigned
>>     struct char_sign { char x : 1; };
>>     char_sign.x = 1;
>>     assert(char_sign.x < 0);
>>
>>
>> Is this possible in clang?
>> If not, could anyone like to point me in the right direction to where the
>> fix would be necessary?
>>
>> Thank you
>>
>> Robert
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130730/16ceee8f/attachment.html>