[llvm-bugs] [Bug 32604] New: x86_64 codegen checks branch conditions in the wrong order

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32604

            Bug ID: 32604
           Summary: x86_64 codegen checks branch conditions in the wrong
                    order
           Product: clang
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dan at su-root.co.uk
                CC: llvm-bugs at lists.llvm.org

Created attachment 18262
  --> https://bugs.llvm.org/attachment.cgi?id=18262&action=edit
Example program that clang++ miscompiles on x86_64

Clang 3.9.0 and 4.0 incorrectly compiles the attached program.

The problem is this branch

```
  bool not_initialized;
  int a = 5;
  int b = 5;
  int c = 5;
  if (xxx(&c, &a, &b, not_initialized) && not_initialized) {
    printf("true\n");
  } else {
    printf("false\n");
  }
```

The function `xxx()` is not guaranteed to initialize the `bool` variable
`not_initialized`. In this program `a`, `b`, and `c` are set up so that
`not_initialized` never gets initialized. However this should not be a problem
because the function `xxx` returns false in this case so the value of
`not_initialized` should never be read.

However the code generated by clang at -O1 does the wrong thing. It branches on
the value of `not_initialized` first before trying to branch on the return
value of `xxx()`. This is wrong because the order of the `&&` operator in the
if condition is not being respected.

Here is the output of `objdump -d --no-show-raw-insn`

```
0000000000400530 <_Z3foov>:
  400530:       sub    $0x18,%rsp
  400534:       movl   $0x5,0x14(%rsp)
  40053c:       movl   $0x5,0x10(%rsp)
  400544:       movl   $0x5,0xc(%rsp)
  40054c:       lea    0xc(%rsp),%rdi
  400551:       lea    0x14(%rsp),%rsi
  400556:       lea    0x10(%rsp),%rdx
  40055b:       lea    0xb(%rsp),%rcx
  400560:       callq  400510 <_Z3xxxPiS_S_Rb>
  400565:       cmpb   $0x0,0xb(%rsp)
  40056a:       je     400577 <_Z3foov+0x47>
  40056c:       xor    $0x1,%al
  40056e:       jne    400577 <_Z3foov+0x47>
  400570:       mov    $0x400637,%edi
  400575:       jmp    40057c <_Z3foov+0x4c>
  400577:       mov    $0x400631,%edi
  40057c:       callq  400400 <puts at plt>
  400581:       add    $0x18,%rsp
  400585:       retq
  400586:       nopw   %cs:0x0(%rax,%rax,1)
```

You can see that after `callq  400510 <_Z3xxxPiS_S_Rb>` the next instruction
`cmpb   $0x0,0xb(%rsp)` which is doing a comparison on a stack location which
is the `not_initialized` bool and then a few instructions later a comparison is
done on the return value of the call (`xor    $0x1,%al`). This is the wrong
order.

You can tell that `0xb(%rsp)` is the `not_initialized` variable because we can
see it being passed as the forth parameter ( `lea    0xb(%rsp),%rcx` ) to the
function call.

For convenience here's a link to the problematic program on godbolt
https://godbolt.org/g/piH3yO

-- 
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/20170410/a0677da2/attachment.html>