[llvm-bugs] [Bug 40104] New: Enabling -fsanitize=integer generates wrong assembly in certain cases for AArch64

[via llvm-bugs]

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

            Bug ID: 40104
           Summary: Enabling -fsanitize=integer generates wrong assembly
                    in certain cases for AArch64
           Product: new-bugs
           Version: 7.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: yschandra at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 21254
  --> https://bugs.llvm.org/attachment.cgi?id=21254&action=edit
source, preprocessed source, asm dump from objects

I have Android N based source code which I build using clang-6, most of the
parts have integer sanitizer "-fsanitize=integer" enabled and code is targeted
for AArch64 (A57). Clang-6 builds work good, however when I try to use
clang-7.0.0 or the trunk in certain cases where open() system call is involved
clang-7 and latest trunk generated wrong assembly code.

For following code:

    int fd = open(DEV_NAME, O_RDWR|O_CLOEXEC);
    if (fd == -1) {
        ERROR("Failed to open %s: %s\n", DEV_NAME, strerror(errno));
        return 1;
    }

Generated code is

; int fd = open(DEV_NAME, O_RDWR|O_CLOEXEC);
      64: 00 00 00 90   adrp  x0, #0
      68: 00 00 00 91   add x0, x0, #0
      6c: 41 00 80 52   mov w1, #2
      70: 01 01 a0 72   movk  w1, #8, lsl #16
      74: 00 00 00 94   bl  #0 <_Z14watchdogd_mainiPPc+0x74>
; if (fd == -1) {
      78: 1f 04 00 31   cmn w0, #1
      7c: e1 01 00 54   b.ne  #60 <_Z14watchdogd_mainiPPc+0xb8>
; ERROR("Failed to open %s: %s\n", DEV_NAME, strerror(errno));
      80: 00 00 00 94   bl  #0 <_Z14watchdogd_mainiPPc+0x80>
      84: 00 00 40 b9   ldr w0, [x0]
      88: 00 00 00 94   bl  #0 <_Z14watchdogd_mainiPPc+0x88>
      8c: e2 03 00 aa   mov x2, x0
      90: 00 00 00 90   adrp  x0, #0
      94: 00 00 00 91   add x0, x0, #0
      98: 01 00 00 90   adrp  x1, #0
      9c: 21 00 00 91   add x1, x1, #0
      a0: 00 00 00 94   bl  #0 <_Z14watchdogd_mainiPPc+0xa0>
; return 1;

The fd check for -1 at address 7c: b.ne goes to abort() and actually it should
have been b.eq instruction and there is no code generated for logic after if
statement (see attached watchdogd.cpp and watchdogd-prep7-clang7.asm)

      7c: e1 01 00 54   b.ne  #60 <_Z14watchdogd_mainiPPc+0xb8>

This is readily not reproducible but in my build I have 3 different places
where this happens, one of them is watchdogd implementation
(https://android.googlesource.com/platform/system/core/+/nougat-release/init/watchdogd.cpp)

I have here attached the watchdogd.cpp taken out from my build and a makefile
which has exact compiler flags I use to compile watchdogd.cpp in my build.
Since this code depends on bionic C, standalone compilation is difficult so, I
have generated pre-processor output so that it can be compiled standalone.

Also if I remove -fsanitizer=integer option code generated is good and issue is
not seen if I use clang-6.

Files Attached (in side watchdogd.tar.gz):
1) watchdogd.cpp - Actual Source code
2) watchdogd-prep6.cpp - Preprocessed code using clang-6
3) watchdogd-prep7.cpp - Preprocessed code using clang-7
4) watchdogd-prep6-clang6.asm - Object text Dump clang-6 preprocessed code
compiled with clang-6
5) watchdogd-prep6-clang7.asm - Object text Dump clang-6 preprocessed code
compiled with clang-7 
6) watchdogd-prep7-clang6.asm - Object text Dump clang-7 preprocessed code
compiled with clang-6
7) watchdogd-prep7-clang7.asm - Object text Dump clang-7 preprocessed code
compiled with clang-7
8) compile.mk - Makefile for compiling

To recompile pre-processed use (fix compiler paths in compile.mk)
   make -f compile.mk dump

If you would like compile watchdogd.cpp you will need bionic c
(https://android.googlesource.com/platform/bionic/+/nougat-release/libc/) and
fix paths in compile.mk

-- 
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/20181219/d07dcb73/attachment.html>