<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"><head><!--[if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:PixelsPerInch>96</o:PixelsPerInch></o:OfficeDocumentSettings></xml><![endif]--></head><body><div style="color:#000; background-color:#fff; font-family:lucida console, sans-serif;font-size:13px">Hi clang devs,<div id="yui_3_16_0_ym19_1_1483447542855_7226"><br id="yui_3_16_0_ym19_1_1483447542855_7227"></div><div id="yui_3_16_0_ym19_1_1483447542855_7228">I was looking at PR9350 and saw that Eli added a test to check LLVM doesn't overflow on [signed] char increment:</div><div id="yui_3_16_0_ym19_1_1483447542855_7229"><br id="yui_3_16_0_ym19_1_1483447542855_7230"></div><div id="yui_3_16_0_ym19_1_1483447542855_7231" dir="ltr">--- cfe/trunk/test/CodeGen/integer-overflow.c 2011/03/02 01:43:30 126815<br id="yui_3_16_0_ym19_1_1483447542855_7232">+++ cfe/trunk/test/CodeGen/integer-overflow.c 2011/03/02 01:49:12 126816<br id="yui_3_16_0_ym19_1_1483447542855_7233">@@ -50,11 +50,17 @@<br id="yui_3_16_0_ym19_1_1483447542855_7234"> // TRAPV_HANDLER: foo(<br id="yui_3_16_0_ym19_1_1483447542855_7235"> --a;<br id="yui_3_16_0_ym19_1_1483447542855_7236"> <br id="yui_3_16_0_ym19_1_1483447542855_7237">- <br id="yui_3_16_0_ym19_1_1483447542855_7238"> // -fwrapv should turn off inbounds for GEP's, PR9256<br id="yui_3_16_0_ym19_1_1483447542855_7239"> extern int* P;<br id="yui_3_16_0_ym19_1_1483447542855_7240"> ++P;<br id="yui_3_16_0_ym19_1_1483447542855_7241"> // DEFAULT: getelementptr inbounds i32*<br id="yui_3_16_0_ym19_1_1483447542855_7242"> // WRAPV: getelementptr i32*<br id="yui_3_16_0_ym19_1_1483447542855_7243"> // TRAPV: getelementptr inbounds i32*<br id="yui_3_16_0_ym19_1_1483447542855_7244">+<br id="yui_3_16_0_ym19_1_1483447542855_7245">+ // PR9350: char increment never overflows.<br id="yui_3_16_0_ym19_1_1483447542855_7246">+ extern volatile signed char PR9350;<br id="yui_3_16_0_ym19_1_1483447542855_7247">+ // DEFAULT: add i8 {{.*}}, 1<br id="yui_3_16_0_ym19_1_1483447542855_7248">+ // WRAPV: add i8 {{.*}}, 1<br id="yui_3_16_0_ym19_1_1483447542855_7249">+ // TRAPV: add i8 {{.*}}, 1<br id="yui_3_16_0_ym19_1_1483447542855_7250">+ ++PR9350;<br id="yui_3_16_0_ym19_1_1483447542855_7251"> }</div><div id="yui_3_16_0_ym19_1_1483447542855_7252" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1483447542855_7798" dir="ltr"><a id="yui_3_16_0_ym19_1_1483447542855_7797" href="http://llvm.org/viewvc/llvm-project?view=revision&revision=126816">http://llvm.org/viewvc/llvm-project?view=revision&revision=126816</a></div><div id="yui_3_16_0_ym19_1_1483447542855_8228" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7253"></div><div id="yui_3_16_0_ym19_1_1483447542855_7254" dir="ltr">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".</div><div id="yui_3_16_0_ym19_1_1483447542855_7255" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7256"></div><div id="yui_3_16_0_ym19_1_1483447542855_7257" dir="ltr">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:</div><div id="yui_3_16_0_ym19_1_1483447542855_7258" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7259"></div><div id="yui_3_16_0_ym19_1_1483447542855_7260" dir="ltr"> // DEFAULT: sub i8 {{.*}}, 1<br id="yui_3_16_0_ym19_1_1483447542855_7261"> // WRAPV: sub i8 {{.*}}, 1<br id="yui_3_16_0_ym19_1_1483447542855_7262"> // TRAPV: sub i8 {{.*}}, 1<br id="yui_3_16_0_ym19_1_1483447542855_7263"> --PR9350;<br id="yui_3_16_0_ym19_1_1483447542855_7264"></div><div id="yui_3_16_0_ym19_1_1483447542855_7265" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7266"></div><div id="yui_3_16_0_ym19_1_1483447542855_7267" dir="ltr">In terms of John's original example, you're wanting to ensure that the equivalent function:</div><div id="yui_3_16_0_ym19_1_1483447542855_7268" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7269"></div><div id="yui_3_16_0_ym19_1_1483447542855_7270" dir="ltr">int bar(char x) {<br id="yui_3_16_0_ym19_1_1483447542855_7271"> char y = x;<br id="yui_3_16_0_ym19_1_1483447542855_7272"> return --x < y;<br id="yui_3_16_0_ym19_1_1483447542855_7273">}</div><div id="yui_3_16_0_ym19_1_1483447542855_7274" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7275"></div><div id="yui_3_16_0_ym19_1_1483447542855_7276" dir="ltr">generates:</div><div id="yui_3_16_0_ym19_1_1483447542855_7277" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7278"></div><div id="yui_3_16_0_ym19_1_1483447542855_7279" dir="ltr">bar(char): # @bar(char)<br id="yui_3_16_0_ym19_1_1483447542855_7280"> xor eax, eax<br id="yui_3_16_0_ym19_1_1483447542855_7281"> cmp dil, -128<br id="yui_3_16_0_ym19_1_1483447542855_7282"> setne al<br id="yui_3_16_0_ym19_1_1483447542855_7283"> ret</div><div id="yui_3_16_0_ym19_1_1483447542855_7284" dir="ltr"><br id="yui_3_16_0_ym19_1_1483447542855_7285"></div><div id="yui_3_16_0_ym19_1_1483447542855_7286" dir="ltr"><font id="yui_3_16_0_ym19_1_1483447542855_7288" color="#000080"><a href="https://godbolt.org/g/x0C1V8">https://godbolt.org/g/x0C1V8</a></font></div><font id="yui_3_16_0_ym19_1_1483447542855_7315" color="#000080"><div id="yui_3_16_0_ym19_1_1483447542855_8276"><br id="yui_3_16_0_ym19_1_1483447542855_7316"></div></font><div id="yiv7516647633yui_3_16_0_ym19_1_1483350091324_8744" dir="ltr">I am asking this:</div><div id="yui_3_16_0_ym19_1_1483447542855_8324" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1483447542855_8303" dir="ltr"> 1. To improve the test coverage for this issue</div><div id="yui_3_16_0_ym19_1_1483447542855_8320" dir="ltr"> 2. Because I spotted MSVC was making this mistake and wanted to make sure clang wasn't!</div><div id="yui_3_16_0_ym19_1_1483447542855_9004" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1483447542855_8332" dir="ltr">Thanks, Andrew R</div></div></body></html>