[LLVMdev] struct with signed bitfield (PR17827)

[Kay Tiong Khoo]

Invalidating this bug with a language technicality would be a great way
out. :)

But I don't see anything in the standard to suggest that a plain 'int'
bitfield is any different than a 'signed int' bitfield, and even if that
was true, I don't see any difference in codegen whether I specify 'signed'
explicitly or not. So at the least, clang or llvm still has a bug for the
explicit 'signed' case from what I can tell.


On Fri, Nov 15, 2013 at 8:41 PM, Mark Lacey <mark.lacey at apple.com> wrote:

>
> On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote:
>
> I've been diagnosing this bug:
> http://llvm.org/bugs/show_bug.cgi?id=17827
>
> Summary: I think the following program miscompiles at -O1 because the fact
> that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. How
> do we fix this?
>
>
> 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.
>
>
> $ cat bitfield.c
> /* %struct.S = type { i8, [3 x i8] } ??? */
> struct S {
>   int f0:3;
> } a;
>
> int foo (int p) {
>   struct S c = a;
>   c.f0 = p & 6;
>   return c.f0 < 1;
> }
>
> int main () {
>   return foo (4);
> }
>
>
> _______________________________________________
> 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/77a0515e/attachment.html>