[llvm-bugs] [Bug 47092] New: Wrong code: suspected bad NSW flag.

[via llvm-bugs]

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

            Bug ID: 47092
           Summary: Wrong code: suspected bad NSW flag.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23837
  --> https://bugs.llvm.org/attachment.cgi?id=23837&action=edit
reduced testcase: llc input after clang -O2

This csmith program:

long b = 8446744073709551615;
static int fn1(int p1, int p2) {
  return (((p1 ^ ((p1 ^ p2) & ~2147483647)) - p2) ^ p2) < 0 ? p1 : p1 - p2;
}
int main() {
  int a = fn1(b & 1303940520, -1628135358);
  printf("checksum = %X\n", a);
}

should print 44108DA8 (p1 in hex).

clang -target s390x-unknown-linux-gnu -march=z10 -O1 ./wrong1.i -o a.out -w ;
./a.out
checksum = 44108DA8
clang -target s390x-unknown-linux-gnu -march=z10 -O2 ./wrong1.i -o a.out -w ;
./a.out
checksum = A51BED66

I found out that there is one case where SystemZElimCompare removes a compare
w/0 after an AFI. The AFI (Add Fullword Immediate) has the nsw and nuw flags,
which makes this transformation safe at this point. However, removing that
compare is the difference between the two results, which indicates that the NSW
flag was present when there in fact will be an overflow.

llc -mtriple=s390x-linux-gnu -mcpu=z10 -O2 ./wrong1.ll -o wrong1.s

  renamable $r1l = nuw nsw AFI killed renamable $r1l(tied-def 0), 1628135358,
implicit-def dead $cc
  CHI renamable $r1l, 0, implicit-def $cc
  BRC 14, 4, %bb.2, implicit $cc

=>

  renamable $r1l = nuw nsw AFI killed renamable $r1l(tied-def 0), 1628135358,
implicit-def $cc
  BRC 15, 4, %bb.2, implicit $cc

  -> WRONG-CODE

I don't think that the constants in the source program will cause an overflow,
and -fsanitize=undefined does not indicate this either. 

I suspect that the multiple combinations of the logical/arithemtic operations
may have introduced an operation that causes an overflow, but I am not quite
sure...

-- 
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/20200810/935da866/attachment.html>