search for: pr17827

I need to read up on how nsw would make this different, but I see your point about the shift: %bf.result.shl = shl i8 %bf.value, 5 %bf.result.ashr = ashr i8 %bf.result.shl, 5 This should have splatted the sign bit across the upper 5 bits of the char, so the subsequent compare: %cmp = icmp slt i32 %bf.cast, 1 Can't be transformed to a check for 'equal to 0'. Thanks! On Fri,

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++

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]

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

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

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? $ 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;