<div dir="ltr">Hi,<div><br></div><div>I'm definitely in the other camp to Marshall and Mats on this one. I don't believe that such aggressive optimization of undefined behavior should be done unless there is a tangible benefit. I think we can all agree that some UB, like the treatment of signed/unsigned wrap, can eventually end up with optimizations on a correct program that wouldn't otherwise be possible.</div><div><br></div><div>But what optimization can this treatment of UB enable? I can't see how a well formed program would benefit from this. And if no well formed program can benefit, what is the use in deliberately destroying non-well-formed programs? We all know that legacy code exists; I don't believe it's right that we break them just because we can. Or because someone took a conforming C program and ran it through a C++ compiler!</div><div><br></div><div>I'm fully prepared for backlash here though (or someone showing the actual benefit of this treatment of UB on well-formed programs).</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 29 Jul 2015 at 10:23 mats petersson <<a href="mailto:mats@planetcatfish.com">mats@planetcatfish.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 July 2015 at 23:40, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer <span dir="ltr"><<a href="mailto:sjoerd.meijer@arm.com" target="_blank">sjoerd.meijer@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-GB"><div><p class="MsoNormal">Hi,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">In C++, the undefined behaviour of a missing return statements for a non-void function results in not generating the function epilogue (unreachable statement is inserted and the return statement is optimised away). Consequently, the runtime behaviour is that control is never properly returned from this function and thus it starts executing “garbage instructions”. As this is undefined behaviour, this is perfectly fine and according to the spec, and a compile warning for this missing return statement is issued. However, in C, the behaviour is that a function epilogue is generated, i.e. basically by returning uninitialised local variable. Codes that rely on this are not beautiful pieces of code, i.e are buggy, but it might just be okay if you for example have a function that just initialises stuff (and the return value is not checked, directly or indirectly); some one might argue that not returning from that function might be a bit harsh. </p></div></div></blockquote><div><br></div></span><div>I would not be one of those people.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Nor me. <br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-GB"><div><p class="MsoNormal">So this email is to probe if there would be strong resistance to follow the C behaviour? I am not yet sure how, but would perhaps a compromise be possible/acceptable to make the undefined behaviour explicit and also generate the function epilogue?</p></div></div></blockquote><div><br></div></span><div>"undefined behavior" is exactly that.</div><div><br></div><div>You have no idea what is going to happen; there are no restrictions on what the code being executed can do. </div><div><br></div><div>"it just might be ok" means on a particular version of a particular compiler, on a particular architecture and OS, at a particular optimization level. Change any of those things, and you can change the behavior.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In fact, the "it works kind of as you expected" is the worst kind of UB in my mind. UB that causes a crash, stops or other "directly obvious that this is wrong" are MUCH easier to debug.<br><br></div><div>So make this particular kind of UB explicit by crashing or stopping would be a good thing. Making it explicit by "returning kind of nicely, but not correct return value" is about the worst possible result.<br><br>--<br></div><div>Mats<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>-- Marshall</div><div><br></div></font></span></div></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>