<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2017, at 9:32 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net" type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=""><div class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jun 29, 2017, at 4:39 AM, Hal Finkel <<a moz-do-not-send="true" href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="moz-cite-prefix">On 06/28/2017 05:33 PM, Peter Lawrence wrote:<br class=""></div><blockquote cite="mid:37027DE0-B3CC-47C2-907C-C5A7A5A97BD1@sbcglobal.net" type="cite" class="">Chandler,<div class=""> where we disagree is in whether the current project is moving the issue</div><div class="">forward. It is not. It is making the compiler more complex for no additional value.</div><div class=""><br class=""></div><div class="">The current project is not based in evidence, I have asked for any SPEC benchmark</div><div class="">that shows performance gain by the compiler taking advantage of “undefined behavior”</div><div class="">and no one can show that.</div></blockquote><br class="">I can't comment on SPEC, but this does remind me of code I was working on recently. To abstract the relevant parts, it looked something like this:<br class=""><br class="">template <typename T><br class="">int do_something(T mask, bool cond) {<br class=""> <span class="Apple-converted-space"> </span>if (mask & 2)<br class=""> <span class="Apple-converted-space"> </span>return 1;<br class=""><br class=""> <span class="Apple-converted-space"> </span>if (cond) {<br class=""> <span class="Apple-converted-space"> </span>T high_mask = mask >> 48;<br class=""> <span class="Apple-converted-space"> </span>if (high_mask > 5)<br class=""> <span class="Apple-converted-space"> </span>do_something_1(high_mask);<br class=""> <span class="Apple-converted-space"> </span>else if (high_mask > 3)<br class=""> <span class="Apple-converted-space"> </span>do_something_2();<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class=""> <span class="Apple-converted-space"> </span>return 0;<br class="">}<br class=""><br class=""></div></div></blockquote></div></blockquote></div></blockquote></div><br class=""><div class="">Hal,</div><div class=""> yes, there are times when it is expedient to suppress or ignore warnings,</div><div class="">but I don’t believe this is one of them, a suggestion could have been made</div><div class="">to change the source code along the lines of</div><div class=""><br class=""></div><div class=""> If (48 < 8*sizeof(mask) && Cond)</div><div class=""><br class=""></div><div class="">Sizeof is always a compile-time constant, this would always be used to dead-code</div><div class="">eliminate the offending block, no "undefined behavior”, no warning, and no</div><div class="">performance issue.</div><div class=""><br class=""></div><div class="">So I respectfully remain skeptical until I see a real world source code example </div><div class="">where "optimizing away undefined behavior” is of benefit.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Peter Lawrence.</div><div class=""><br class=""></div></body></html>