[LLVMdev] struct with signed bitfield (PR17827)

[Kay Tiong Khoo]

Thanks, Richard (and also Mark Lacey, who did remember correctly!). I've
noted this thread and linked to the standard in the bug report.

I'll try to pinpoint the problem in InstCombine - thanks, Henrique.

Does anyone know why clang always rounds bit fields up to byte widths
rather than say just using 'i3' to represent a 3-bit field? The
bit-shifting gymnastics created by the byte-size ops appear to lead to
other problems like:
http://llvm.org/bugs/show_bug.cgi?id=17956



On Sat, Nov 16, 2013 at 4:09 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> C says that plain bit-fields could be either signed or unsigned. C++
> removed this allowance in core issue 739:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739
>
>
> On Sat, Nov 16, 2013 at 1:55 PM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
>
>> On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote:
>>
>> > I don’t have the C/C++ standards in front of me but IIRC whether a
>> char/short/int/long/long long bitfield is signed or unsigned is
>> implementation defined. You need to explicitly specify signed or unsigned
>> in order to have any guarantee of the signedness, e.g. signed int.
>>
>> Section 3.9.1 of the C++11 standard [1] defines short/int/long/long long
>> as signed.  Bit-fields are discussed in 9.6 and have lots of
>> implementation-defined behavior, but I don’t see anything about signedness.
>>  The ABI (e.g., [2]) defines whether char is signed or unsigned.
>>
>> [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3485.pdf
>> [2]: http://www.cs.tufts.edu/comp/40/readings/amd64-abi.pdf
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131117/14d8eb4e/attachment.html>