https://bugs.llvm.org/show_bug.cgi?id=51163
Bug ID: 51163
Summary: IR code with bool as return type generates binary may
return 255 as true value, which causes UB in C++
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Hello,
I've been playing with the IR code and JIT recently, and noticed something
weird and can be reproduced by llc as well
For the following IR, which simple compares a array of data to 41 and 42, and
returns the result in boolean(i1)
@0 = internal constant <{ i32, i32 }> <{ i32 41, i32 42 }>, align 1
define i1 @"/.t19709"() {
entry:
%0 = load i32, i32* getelementptr inbounds (<{ i32, i32 }>, <{ i32, i32 }>*
@0, i32 0, i32 0), align 4
%1 = load i32, i32* getelementptr inbounds (<{ i32, i32 }>, <{ i32, i32 }>*
@0, i32 0, i32 1), align 4
%t = icmp eq i32 %0, 41
%t1 = icmp eq i32 %1, 42
%2 = select i1 %t, i1 %t1, i1 false
%. = select i1 %2, i1 true, i1 false
ret i1 %.
}
However, the code generated by > LLVM8 and <=LLVM8 are different,
https://godbolt.org/z/hrze61e8e
>From LLMV9 to trunk, if comparison succeed, the extra `neg` which make %al to
have value 255
0x00007ffff79b2000: endbr64
0x00007ffff79b2004: movabs $0x7ffff79b3000,%rax
0x00007ffff79b200e: mov (%rax),%ecx # ecx = 41
0x00007ffff79b2010: mov 0x4(%rax),%eax # eax = 42
0x00007ffff79b2013: xor $41,%ecx # ecx = 0
0x00007ffff79b2016: xor $42,%eax # eax = 0
0x00007ffff79b2019: or %ecx,%eax # eax = 0
0x00007ffff79b201b: sete %al # al = 1
0x00007ffff79b201e: neg %al # al = (0-1) = 255
0x00007ffff79b2020: retq
and 255 is not a valid boolean value for gcc and clang, this kind of return
value causes all sorts of strange behaviors in my C++ code
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
