[LLVMdev] struct with signed bitfield (PR17827)

[Henrique Santos]

I actually think it is a problem with the optimizer like Kay first thought.
-instcombine seems turning "((x and 6) shl 5) slt 32" into "(x and 6) slt
1". If the comparison were unsigned or the shl had a nsw flag, I think this
would be okay. Since none of these is true, I don't think this
transformation is correct.

H.



On Sat, Nov 16, 2013 at 1:41 AM, 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
>
>
>
> _______________________________________________
> 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/173f9ab3/attachment.html>