Duncan P. N. Exon Smith
2013-Nov-16 21:55 UTC
[LLVMdev] struct with signed bitfield (PR17827)
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
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131116/22e15466/attachment.html>
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>