[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-commits
Subject: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++
From: "Sjoerd Meijer" <sjoerd.meijer () arm ! com>
Date: 2015-07-31 14:35:54
Message-ID: 000b01d0cb9e$351e3db0$9f5ab910$ () arm ! com
[Download RAW message or body]
This is a multipart message in MIME format.
[Attachment #2 (multipart/alternative)]
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?
Cheers,
Sjoerd.
From: cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] On \
Behalf Of Richard Smith
Sent: 29 July 2015 18:07
To: Hal Finkel
Cc: Marshall Clow; cfe-dev@cs.uiuc.edu Developers
Subject: Re: [cfe-dev] missing return statement for non-void functions in \
C++
On Jul 29, 2015 7:43 AM, "Hal Finkel" <hfinkel@anl.gov> wrote:
>
> ----- Original Message -----
> > From: "David Blaikie" <dblaikie@gmail.com>
> > To: "James Molloy" <james@jamesmolloy.co.uk>
> > Cc: "Marshall Clow" <mclow.lists@gmail.com>, "cfe-dev Developers" \
> > <cfe-dev@cs.uiuc.edu>
> > Sent: Wednesday, July 29, 2015 9:15:09 AM
> > Subject: Re: [cfe-dev] missing return statement for non-void functions \
> > in C++
> >
> > On Jul 29, 2015 7:06 AM, "James Molloy" < james@jamesmolloy.co.uk >
> > wrote:
> > >
> > > Hi,
> > >
> > > If we're going to emit a trap instruction (and thus create a broken
> > > binary), why don't we error instead?
> >
> > We warn, can't error, because it may be dynamically unreached, in
> > which case the program is valid and we can't reject it.
>
> I think this also explains why this is useful for optimization.
>
> 1. It is a code-size optimization
> 2. By eliminating unreachable control flow, we can remove branches and \
> tests that are not actual necessary
> int foo(int x) {
> if (x > 5) return 2*x;
> else if (x < 2) return 3 - x;
> }
>
> 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).
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.
> -Hal
>
> >
> > >
> > > James
> > >
> > > On Wed, 29 Jul 2015 at 15:05 David Blaikie < dblaikie@gmail.com >
> > > wrote:
> > > >
> > > >
> > > > On Jul 29, 2015 2:10 AM, "mats petersson" < mats@planetcatfish.com
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 28 July 2015 at 23:40, Marshall Clow < mclow.lists@gmail.com
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer <
> > > > > > sjoerd.meijer@arm.com > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > > >
> > > > > > I would not be one of those people.
> > > > >
> > > > >
> > > > > Nor me.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > 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?
> > > > > >
> > > > > >
> > > > > > "undefined behavior" is exactly that.
> > > > > >
> > > > > > You have no idea what is going to happen; there are no
> > > > > > restrictions on what the code being executed can do.
> > > > > >
> > > > > > "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.
> > > > >
> > > > >
> > > > > 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.
> > > > >
> > > > > 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.
> > > >
> > > > At -O0 clang emits a trap instruction, making it more explicit as
> > > > you suggest. At higher optimization levels it just falls
> > > > through/off.
> > > >
> > > > >
> > > > > --
> > > > > Mats
> > > > > >
> > > > > >
> > > > > > -- Marshall
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > cfe-dev mailing list
> > > > > > cfe-dev@cs.uiuc.edu
> > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > cfe-dev mailing list
> > > > > cfe-dev@cs.uiuc.edu
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > > >
> > > >
> > > > _______________________________________________
> > > > cfe-dev mailing list
> > > > cfe-dev@cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[Attachment #5 (text/html)]
<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";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@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'>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?<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'>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><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"'> \
cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] <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; \
cfe-dev@cs.uiuc.edu Developers<br><b>Subject:</b> 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><p>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).<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">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><o:p></o:p></p></div></body></html>
["missingreturn.diff" (application/octet-stream)]
diff --git a/lib/CodeGen/CodeGenFunction.cpp b/lib/CodeGen/CodeGenFunction.cpp
index ec3c75c..35a5f15 100644
--- a/lib/CodeGen/CodeGenFunction.cpp
+++ b/lib/CodeGen/CodeGenFunction.cpp
@@ -933,8 +933,6 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD, llvm::Function *Fn,
} else if (CGM.getCodeGenOpts().OptimizationLevel == 0) {
EmitTrapCall(llvm::Intrinsic::trap);
}
- Builder.CreateUnreachable();
- Builder.ClearInsertionPoint();
}
// Emit the standard function epilogue.
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic