<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-GB;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[ + <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a> ]<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The functionality is now available under a flag, see attached patch. Note that the flag is ignored in C++ mode, so it will help the use case of compiling (legacy) C code with a C++ compiler.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sjoerd.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Sjoerd Meijer [<a href="mailto:sjoerd.meijer@arm.com">mailto:sjoerd.meijer@arm.com</a>] <br><b>Sent:</b> 03 August 2015 11:40<br><b>To:</b> 'Richard Smith'<br><b>Cc:</b> Hal Finkel; Marshall Clow; <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers; cfe commits<br><b>Subject:</b> RE: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Richard,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I agree with your conclusions and will start preparing a patch for option 3) under a flag that is off by default; this enables folks to build/run C code in C++. I actually think option 2) would be a good one too, but as it is already available under a flag I also don’t see how useful it is combining options 2) and 3) with another (or one more) flag that is off by default.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:metafoo@gmail.com">metafoo@gmail.com</a> [<a href="mailto:metafoo@gmail.com">mailto:metafoo@gmail.com</a>] <b>On Behalf Of </b>Richard Smith<br><b>Sent:</b> 31 July 2015 19:46<br><b>To:</b> Sjoerd Meijer<br><b>Cc:</b> Hal Finkel; Marshall Clow; <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers; cfe commits<br><b>Subject:</b> Re: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Fri, Jul 31, 2015 at 7:35 AM, Sjoerd Meijer <<a href="mailto:sjoerd.meijer@arm.com" target="_blank">sjoerd.meijer@arm.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi, I am not sure if we came to a conclusion. Please find attached a patch. It simply removes the two lines that insert an unreachable statement (which cause removal of the return statement). Please note that at -O0 the trap instruction is still generated. Is this something we could live with?</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I don't think this is an improvement:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This doesn't satisfy the folks who want an 'unreachable' for better code size and optimization, and it doesn't satisfy the folks who want a guaranteed trap for security, and it doesn't satisfy the folks who want their broken code to limp along (because it'll still trap at -O0), and it is at best a minor improvement for the folks who want missing returns to be more easily debuggable (with -On, the code goes wrong in the caller, or appears to work, rather than falling into an unrelated function, and debugging this with -O0 was already easy).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think there are three options that are defensible here:<o:p></o:p></p></div><div><p class=MsoNormal>1) The status quo: this is UB and we treat it as such and optimize on that basis, but provide a trap as a convenience at -O0<o:p></o:p></p></div><div><p class=MsoNormal>2) The secure approach: this is UB but we always trap<o:p></o:p></p></div><div><p class=MsoNormal>3) Define the behavior to return 'undef' for C types: this allows questionable C code that has UB in C++ to keep working when built with a C++ compiler<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Note that (3) can be combined with either (1) or (2). (2) is already available via the 'return' sanitizer. So this really reduces to: in those cases where C says it's OK so long as the caller doesn't look at the returned value (and where the return type doesn't have a non-trivial copy constructor or destructor, isn't a reference, and so on), should we attempt to preserve the C behaviour? I would be OK with putting that behind a `-f` flag (perhaps `-fstrict-return` or similar) to support those folks who want to build C code in C++, but I would suggest having that flag be off by default, since that is not the usual use case for a C++ compiler.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sjoerd.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a>] <b>On Behalf Of </b>Richard Smith<br><b>Sent:</b> 29 July 2015 18:07<br><b>To:</b> Hal Finkel<br><b>Cc:</b> Marshall Clow; <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> Developers</span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Subject:</b> Re: [cfe-dev] missing return statement for non-void functions in C++<o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p>On Jul 29, 2015 7:43 AM, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>><br>> ----- Original Message -----<br>> > From: "David Blaikie" <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>> > To: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>><br>> > Cc: "Marshall Clow" <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>>, "cfe-dev Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br>> > Sent: Wednesday, July 29, 2015 9:15:09 AM<br>> > Subject: Re: [cfe-dev] missing return statement for non-void functions in C++<br>> ><br>> ><br>> > On Jul 29, 2015 7:06 AM, "James Molloy" < <a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a> ><br>> > wrote:<br>> > ><br>> > > Hi,<br>> > ><br>> > > If we're going to emit a trap instruction (and thus create a broken<br>> > > binary), why don't we error instead?<br>> ><br>> > We warn, can't error, because it may be dynamically unreached, in<br>> > which case the program is valid and we can't reject it.<br>><br>> I think this also explains why this is useful for optimization.<br>><br>> 1. It is a code-size optimization<br>> 2. By eliminating unreachable control flow, we can remove branches and tests that are not actual necessary<br>><br>> int foo(int x) {<br>> if (x > 5) return 2*x;<br>> else if (x < 2) return 3 - x;<br>> }<br>><br>> That having been said, there are other ways to express these things, and the situation often represents an error. I'd be fine with requiring a special flag (-fallow-nonreturning-functions or whatever) in order to put the compiler is a truly confirming mode (similar to the situation with sized delete).<o:p></o:p></p><p>Note that we already have a flag to trap on this: -fsanitize-trap=return. (You may also need -fsanitize=return, I don't remember.) That seems consistent with how we treat most other forms of UB.<o:p></o:p></p><p>> -Hal<br>><br>> ><br>> > ><br>> > > James<br>> > ><br>> > > On Wed, 29 Jul 2015 at 15:05 David Blaikie < <a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a> ><br>> > > wrote:<br>> > >><br>> > >><br>> > >> On Jul 29, 2015 2:10 AM, "mats petersson" < <a href="mailto:mats@planetcatfish.com" target="_blank">mats@planetcatfish.com</a><br>> > >> > wrote:<br>> > >> ><br>> > >> ><br>> > >> ><br>> > >> > On 28 July 2015 at 23:40, Marshall Clow < <a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a><br>> > >> > > wrote:<br>> > >> >><br>> > >> >><br>> > >> >><br>> > >> >> On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer <<br>> > >> >> <a href="mailto:sjoerd.meijer@arm.com" target="_blank">sjoerd.meijer@arm.com</a> > wrote:<br>> > >> >>><br>> > >> >>> Hi,<br>> > >> >>><br>> > >> >>><br>> > >> >>><br>> > >> >>> In C++, the undefined behaviour of a missing return statements<br>> > >> >>> for a non-void function results in not generating the<br>> > >> >>> function epilogue (unreachable statement is inserted and the<br>> > >> >>> return statement is optimised away). Consequently, the<br>> > >> >>> runtime behaviour is that control is never properly returned<br>> > >> >>> from this function and thus it starts executing “garbage<br>> > >> >>> instructions”. As this is undefined behaviour, this is<br>> > >> >>> perfectly fine and according to the spec, and a compile<br>> > >> >>> warning for this missing return statement is issued. However,<br>> > >> >>> in C, the behaviour is that a function epilogue is generated,<br>> > >> >>> i.e. basically by returning uninitialised local variable.<br>> > >> >>> Codes that rely on this are not beautiful pieces of code, i.e<br>> > >> >>> are buggy, but it might just be okay if you for example have<br>> > >> >>> a function that just initialises stuff (and the return value<br>> > >> >>> is not checked, directly or indirectly); some one might argue<br>> > >> >>> that not returning from that function might be a bit harsh.<br>> > >> >><br>> > >> >><br>> > >> >> I would not be one of those people.<br>> > >> ><br>> > >> ><br>> > >> > Nor me.<br>> > >> >><br>> > >> >><br>> > >> >>><br>> > >> >>> So this email is to probe if there would be strong resistance<br>> > >> >>> to follow the C behaviour? I am not yet sure how, but would<br>> > >> >>> perhaps a compromise be possible/acceptable to make the<br>> > >> >>> undefined behaviour explicit and also generate the function<br>> > >> >>> epilogue?<br>> > >> >><br>> > >> >><br>> > >> >> "undefined behavior" is exactly that.<br>> > >> >><br>> > >> >> You have no idea what is going to happen; there are no<br>> > >> >> restrictions on what the code being executed can do.<br>> > >> >><br>> > >> >> "it just might be ok" means on a particular version of a<br>> > >> >> particular compiler, on a particular architecture and OS, at a<br>> > >> >> particular optimization level. Change any of those things, and<br>> > >> >> you can change the behavior.<br>> > >> ><br>> > >> ><br>> > >> > In fact, the "it works kind of as you expected" is the worst<br>> > >> > kind of UB in my mind. UB that causes a crash, stops or other<br>> > >> > "directly obvious that this is wrong" are MUCH easier to debug.<br>> > >> ><br>> > >> > So make this particular kind of UB explicit by crashing or<br>> > >> > stopping would be a good thing. Making it explicit by<br>> > >> > "returning kind of nicely, but not correct return value" is<br>> > >> > about the worst possible result.<br>> > >><br>> > >> At -O0 clang emits a trap instruction, making it more explicit as<br>> > >> you suggest. At higher optimization levels it just falls<br>> > >> through/off.<br>> > >><br>> > >> ><br>> > >> > --<br>> > >> > Mats<br>> > >> >><br>> > >> >><br>> > >> >> -- Marshall<br>> > >> >><br>> > >> >><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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>> > >> >><br>> > >> ><br>> > >> ><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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>> > >> ><br>> > >><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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>> ><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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>> ><br>><br>> --<br>> Hal Finkel<br>> Assistant Computational Scientist<br>> Leadership Computing Facility<br>> Argonne National Laboratory<br>><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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><o:p></o:p></p></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>