[cfe-dev] Testcase for LLVM PR9350

[via cfe-dev]

Hi clang devs,
I was looking at PR9350 and saw that Eli added a test to check LLVM doesn't overflow on [signed] char increment:
--- cfe/trunk/test/CodeGen/integer-overflow.c 2011/03/02 01:43:30 126815
+++ cfe/trunk/test/CodeGen/integer-overflow.c 2011/03/02 01:49:12 126816
@@ -50,11 +50,17 @@
   // TRAPV_HANDLER: foo(
   --a;
   
-  
   // -fwrapv should turn off inbounds for GEP's, PR9256
   extern int* P;
   ++P;
   // DEFAULT: getelementptr inbounds i32*
   // WRAPV: getelementptr i32*
   // TRAPV: getelementptr inbounds i32*
+
+  // PR9350: char increment never overflows.
+  extern volatile signed char PR9350;
+  // DEFAULT: add i8 {{.*}}, 1
+  // WRAPV: add i8 {{.*}}, 1
+  // TRAPV: add i8 {{.*}}, 1
+  ++PR9350;
 }
http://llvm.org/viewvc/llvm-project?view=revision&revision=126816
Presumably the logic about promotion to int applies the same as in the argument John gave in PR9350 since 6.5.3.1 §3 says "the prefix -- operator is analogous to the prefix ++ operator, except that the value of the operand is decremented".
Would it therefore make sense to add the equivalent test to integer-overflow.c that decrement of a [signed] char didn't ever cause underflow:
  // DEFAULT: sub i8 {{.*}}, 1
  // WRAPV: sub i8 {{.*}}, 1
  // TRAPV: sub i8 {{.*}}, 1
  --PR9350;

In terms of John's original example, you're wanting to ensure that the equivalent function:
int bar(char x) {
   char y = x;
   return --x < y;
}
generates:
bar(char):                                # @bar(char)
        xor     eax, eax
        cmp     dil, -128
        setne   al
        ret
https://godbolt.org/g/x0C1V8
I am asking this:
   1. To improve the test coverage for this issue   2. Because I spotted MSVC was making this mistake and wanted to make sure clang wasn't!
Thanks, Andrew R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170103/b169a8b9/attachment.html>