Displaying 4 results from an estimated 4 matches for "n3485".
Did you mean:
3485
2013 Nov 16
2
[LLVMdev] struct with signed bitfield (PR17827)
...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
2013 Nov 16
0
[LLVMdev] struct with signed bitfield (PR17827)
...g/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
>
-------------...
2013 Nov 16
0
[LLVMdev] struct with signed bitfield (PR17827)
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
2013 Nov 15
4
[LLVMdev] struct with signed bitfield (PR17827)
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;