<p dir="ltr">On Jul 29, 2015 7:43 AM, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
><br>
> ----- Original Message -----<br>
> > From: "David Blaikie" <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
> > To: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>><br>
> > Cc: "Marshall Clow" <<a href="mailto:mclow.lists@gmail.com">mclow.lists@gmail.com</a>>, "cfe-dev Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu">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">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">>  -Hal<br>
><br>
> ><br>
> > ><br>
> > > James<br>
> > ><br>
> > > On Wed, 29 Jul 2015 at 15:05 David Blaikie < <a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a> ><br>
> > > wrote:<br>
> > >><br>
> > >><br>
> > >> On Jul 29, 2015 2:10 AM, "mats petersson" < <a href="mailto:mats@planetcatfish.com">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">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">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">cfe-dev@cs.uiuc.edu</a><br>
> > >> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">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">cfe-dev@cs.uiuc.edu</a><br>
> > >> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">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">cfe-dev@cs.uiuc.edu</a><br>
> > >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">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">cfe-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">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">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>