[llvm-bugs] [Bug 51163] New: IR code with bool as return type generates binary may return 255 as true value, which causes UB in C++

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: mo_xiao_ming at yahoo.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210722/690c0376/attachment-0001.html>