[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-commits
Subject: RE: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in C++
From: Sjoerd Meijer via cfe-commits <cfe-commits () lists ! llvm ! org>
Date: 2015-08-13 8:52:01
Message-ID: 1C23526A7C42DB45BBF55B662C7C530E4E651643F4 () BUNGLE ! Emea ! Arm ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
Hi Richard,
Thanks for reviewing. Agree, that was a bit confusing. More specifically,
the warning message was confusing (i.e. wrong). This patch is for compiling .c
input in C++ mode. The new flag should be ignored for C++ *input*, and indeed
not when it is in C++ *mode* as the warning message said earlier. So I have
changed the warning message accordingly and hope that solves it, see attached
patch.
Cheers.
From: metafoo@gmail.com [mailto:metafoo@gmail.com] On Behalf Of Richard Smith
Sent: 12 August 2015 23:06
To: Sjoerd Meijer
Cc: Hal Finkel; Marshall Clow; cfe-commits
Subject: Re: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in \
C++
This patch seems a bit confused. You warn that the flag is ignored in C++, but it \
only has an effect in C++. You have a testcase with a .c extension that is built with \
-x c++.
On Wed, Aug 12, 2015 at 5:23 AM, Sjoerd Meijer \
<sjoerd.meijer@arm.com<mailto:sjoerd.meijer@arm.com>> wrote: [ + \
cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org> ]
Hi,
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. Cheers,
Sjoerd.
From: Sjoerd Meijer [mailto:sjoerd.meijer@arm.com]
Sent: 03 August 2015 11:40
To: 'Richard Smith'
Cc: Hal Finkel; Marshall Clow; cfe-dev@cs.uiuc.edu<mailto:cfe-dev@cs.uiuc.edu> \
Developers; cfe commits
Subject: RE: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in \
C++
Hi Richard,
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.
Cheers.
From: metafoo@gmail.com<mailto:metafoo@gmail.com> [mailto:metafoo@gmail.com] On \
Behalf Of Richard Smith
Sent: 31 July 2015 19:46
To: Sjoerd Meijer
Cc: Hal Finkel; Marshall Clow; cfe-dev@cs.uiuc.edu<mailto:cfe-dev@cs.uiuc.edu> \
Developers; cfe commits
Subject: Re: [PATCH] RE: [cfe-dev] missing return statement for non-void functions in \
C++
On Fri, Jul 31, 2015 at 7:35 AM, Sjoerd Meijer \
<sjoerd.meijer@arm.com<mailto:sjoerd.meijer@arm.com>> wrote: 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?
I don't think this is an improvement:
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).
I think there are three options that are defensible here:
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 2) The secure approach: this is UB but we \
always trap 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
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.
Cheers,
Sjoerd.
From: cfe-dev-bounces@cs.uiuc.edu<mailto:cfe-dev-bounces@cs.uiuc.edu> \
[mailto: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<mailto: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<mailto:hfinkel@anl.gov>> \
wrote:
>
> ----- Original Message -----
> > From: "David Blaikie" <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
> > To: "James Molloy" <james@jamesmolloy.co.uk<mailto:james@jamesmolloy.co.uk>>
> > Cc: "Marshall Clow" <mclow.lists@gmail.com<mailto:mclow.lists@gmail.com>>, \
> > "cfe-dev Developers" \
> > <cfe-dev@cs.uiuc.edu<mailto: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<mailto: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<mailto:dblaikie@gmail.com> > wrote:
> > > >
> > > >
> > > > On Jul 29, 2015 2:10 AM, "mats petersson" < \
> > > > mats@planetcatfish.com<mailto:mats@planetcatfish.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 28 July 2015 at 23:40, Marshall Clow < \
> > > > > mclow.lists@gmail.com<mailto:mclow.lists@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 28, 2015 at 6:14 AM, Sjoerd Meijer <
> > > > > > sjoerd.meijer@arm.com<mailto: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<mailto:cfe-dev@cs.uiuc.edu>
> > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > cfe-dev mailing list
> > > > > cfe-dev@cs.uiuc.edu<mailto:cfe-dev@cs.uiuc.edu>
> > > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > > >
> > > >
> > > > _______________________________________________
> > > > cfe-dev mailing list
> > > > cfe-dev@cs.uiuc.edu<mailto:cfe-dev@cs.uiuc.edu>
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@cs.uiuc.edu<mailto: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<mailto:cfe-dev@cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential \
and may also be privileged. If you are not the intended recipient, please notify the \
sender immediately and do not disclose the contents to any other person, use it for \
any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in \
England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn \
Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
[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";}
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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
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;}
.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 \
Richard,<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks \
for reviewing. Agree, that was a bit confusing. More \
specifically,<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">the \
warning message was confusing (i.e. wrong). This patch is for compiling .c \
<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">input \
in C++ mode. The new flag should be ignored for C++ *<b>input</b>*, \
and indeed <o:p></o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">not \
when it is in C++ *mode* as the warning message said earlier. So I have \
<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">changed \
the warning message accordingly and hope that solves it, see \
attached<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">patch.<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""> \
metafoo@gmail.com [mailto:metafoo@gmail.com] <b>On Behalf Of </b>Richard Smith<br>
<b>Sent:</b> 12 August 2015 23:06<br>
<b>To:</b> Sjoerd Meijer<br>
<b>Cc:</b> Hal Finkel; Marshall Clow; 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>
<p class="MsoNormal">This patch seems a bit confused. You warn that the flag is \
ignored in C++, but it only has an effect in C++. You have a testcase \
with a .c extension that is built with -x c++.<o:p></o:p></p> <div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Aug 12, 2015 at 5:23 AM, Sjoerd Meijer <<a \
href="mailto:sjoerd.meijer@arm.com" target="_blank">sjoerd.meijer@arm.com</a>> \
wrote:<o:p></o:p></p> <div>
<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">[ \
+ <a href="mailto:cfe-commits@lists.llvm.org" \
target="_blank">cfe-commits@lists.llvm.org</a> ]</span><o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <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">Hi,</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">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.</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">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>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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""> \
Sjoerd Meijer [<a href="mailto:sjoerd.meijer@arm.com" \
target="_blank">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" \
target="_blank"> 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++</span><o:p></o:p></p> </div>
</div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <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">Hi \
Richard,</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"><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.</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"><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"> </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:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a> [<a \
href="mailto:metafoo@gmail.com" target="_blank">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" \
target="_blank"> 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++</span><o:p></o:p></p> <div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
<div> <div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I \
don't think this is an improvement:<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I \
think there are three options that are defensible here:<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">2) \
The secure approach: this is UB but we always trap<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> </div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<br>
<font face="Arial" color="Black" size="2">-- IMPORTANT NOTICE: The contents of this \
email and any attachments are confidential and may also be privileged. If you are not \
the intended recipient, please notify the sender immediately and do not disclose the \
contents to any other person, use it for any purpose, or store or copy the \
information in any medium. Thank you.<br> <br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in \
England & Wales, Company No: 2557590<br> ARM Holdings plc, Registered office 110 \
Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: \
2548782<br> </font>
</body>
</html>
["missingreturn2.diff" (application/octet-stream)]
diff --git a/include/clang/Basic/DiagnosticDriverKinds.td \
b/include/clang/Basic/DiagnosticDriverKinds.td index f7f09da..7fee768 100644
--- a/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/include/clang/Basic/DiagnosticDriverKinds.td
@@ -116,6 +116,7 @@ def err_drv_optimization_remark_pattern : Error<
"%0 in '%1'">;
def err_drv_no_neon_modifier : Error<"[no]neon is not accepted as modifier, please \
use [no]simd instead">;
+def warn_drv_nonret_function_ignored_for_cxx_input : Warning<"ignoring \
-fallow-nonreturning-functions for C++ input">; def warn_O4_is_O3 : Warning<"-O4 is \
equivalent to -O3">, InGroup<Deprecated>; def warn_drv_optimization_value : \
Warning<"optimization level '%0' is not supported; using '%1%2' instead">, \
InGroup<InvalidCommandLineArgument>;
diff --git a/include/clang/Driver/Options.td b/include/clang/Driver/Options.td
index bae61c5..540c119 100644
--- a/include/clang/Driver/Options.td
+++ b/include/clang/Driver/Options.td
@@ -479,6 +479,7 @@ def fcomment_block_commands : CommaJoined<["-"], \
"fcomment-block-commands=">, Gr HelpText<"Treat each comma separated argument in \
<arg> as a documentation comment block command">, MetaVarName<"<arg>">;
def fparse_all_comments : Flag<["-"], "fparse-all-comments">, Group<f_clang_Group>, \
Flags<[CC1Option]>; +def fallow_nonreturning_functions : Flag<["-"], \
"fallow-nonreturning-functions">, Group<f_Group>, Flags<[CC1Option]>; def fcommon : \
Flag<["-"], "fcommon">, Group<f_Group>; def fcompile_resource_EQ : Joined<["-"], \
"fcompile-resource=">, Group<f_Group>; def fconstant_cfstrings : Flag<["-"], \
"fconstant-cfstrings">, Group<f_Group>; @@ -789,6 +790,8 @@ def fno_color_diagnostics \
: Flag<["-"], "fno-color-diagnostics">, Group<f_Group> Flags<[CoreOption, \
CC1Option]>; def fno_diagnostics_color : Flag<["-"], "fno-diagnostics-color">, \
Group<f_Group>, Flags<[CoreOption, DriverOption]>;
+def fno_allow_nonreturning_functions : Flag<["-"], \
"fno-allow-nonreturning-functions">, Group<f_Group>, Flags<[CC1Option]>, + \
HelpText<"Generations function epilogue for non-void functions with a missing return \
statement">; def fno_common : Flag<["-"], "fno-common">, Group<f_Group>, \
Flags<[CC1Option]>, HelpText<"Compile common globals like normal definitions">;
def fno_constant_cfstrings : Flag<["-"], "fno-constant-cfstrings">, Group<f_Group>,
diff --git a/include/clang/Frontend/CodeGenOptions.def \
b/include/clang/Frontend/CodeGenOptions.def index b5964ee..7e5c10f 100644
--- a/include/clang/Frontend/CodeGenOptions.def
+++ b/include/clang/Frontend/CodeGenOptions.def
@@ -78,6 +78,7 @@ CODEGENOPT(MergeAllConstants , 1, 1) ///< Merge identical \
constants. CODEGENOPT(MergeFunctions , 1, 0) ///< Set when -fmerge-functions is \
enabled. CODEGENOPT(MSVolatile , 1, 0) ///< Set when /volatile:ms is enabled.
CODEGENOPT(NoCommon , 1, 0) ///< Set when -fno-common or C++ is enabled.
+CODEGENOPT(AllowNonReturningFunctions, 1, 0) ///< Set when \
-fallow-nonreturning-functions is enabled CODEGENOPT(NoDwarfDirectoryAsm , 1, 0) \
///< Set when -fno-dwarf-directory-asm is ///< enabled.
CODEGENOPT(NoExecStack , 1, 0) ///< Set when -Wa,--noexecstack is enabled.
diff --git a/lib/CodeGen/CodeGenFunction.cpp b/lib/CodeGen/CodeGenFunction.cpp
index 9bf4161..894d57a 100644
--- a/lib/CodeGen/CodeGenFunction.cpp
+++ b/lib/CodeGen/CodeGenFunction.cpp
@@ -929,8 +929,11 @@ void CodeGenFunction::GenerateCode(GlobalDecl GD, llvm::Function \
*Fn, } else if (CGM.getCodeGenOpts().OptimizationLevel == 0) {
EmitTrapCall(llvm::Intrinsic::trap);
}
- Builder.CreateUnreachable();
- Builder.ClearInsertionPoint();
+
+ if (!CGM.getCodeGenOpts().AllowNonReturningFunctions) {
+ Builder.CreateUnreachable();
+ Builder.ClearInsertionPoint();
+ }
}
// Emit the standard function epilogue.
diff --git a/lib/Driver/Tools.cpp b/lib/Driver/Tools.cpp
index a04be9c..4af828e 100644
--- a/lib/Driver/Tools.cpp
+++ b/lib/Driver/Tools.cpp
@@ -2938,6 +2938,24 @@ static void addPGOAndCoverageFlags(Compilation &C, const \
Driver &D, }
}
+static bool IsTreatingInputAsCXX(const ToolChain &TC, const InputInfo &Input)
+{
+ if (!Input.isFilename())
+ return false;
+
+ const char *Fn = Input.getFilename();
+ const char *Ext = strrchr(Fn, '.');
+ if (!Ext)
+ return false;
+
+ const types::ID Ty = TC.LookupTypeForExtension(Ext + 1);
+ const bool CCCIsCXX = TC.getDriver().CCCIsCXX();
+ if (Ty == types::TY_C && CCCIsCXX)
+ return true;
+
+ return false;
+}
+
void Clang::ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output, const InputInfoList &Inputs,
const ArgList &Args, const char *LinkingOutput) const {
@@ -4689,6 +4707,15 @@ void Clang::ConstructJob(Compilation &C, const JobAction &JA,
!NoCommonDefault))
CmdArgs.push_back("-fno-common");
+ if (Args.hasFlag(options::OPT_fallow_nonreturning_functions,
+ options::OPT_fno_allow_nonreturning_functions, false))
+ {
+ if (!IsTreatingInputAsCXX(getToolChain(), Input))
+ D.Diag(diag::warn_drv_nonret_function_ignored_for_cxx_input);
+ else
+ CmdArgs.push_back("-fallow-nonreturning-functions");
+ }
+
// -fsigned-bitfields is default, and clang doesn't yet support
// -funsigned-bitfields.
if (!Args.hasFlag(options::OPT_fsigned_bitfields,
diff --git a/lib/Frontend/CompilerInvocation.cpp \
b/lib/Frontend/CompilerInvocation.cpp index 8934c80..183545e 100644
--- a/lib/Frontend/CompilerInvocation.cpp
+++ b/lib/Frontend/CompilerInvocation.cpp
@@ -439,6 +439,7 @@ static bool ParseCodeGenArgs(CodeGenOptions &Opts, ArgList &Args, \
InputKind IK, Opts.StructPathTBAA = !Args.hasArg(OPT_no_struct_path_tbaa);
Opts.DwarfDebugFlags = Args.getLastArgValue(OPT_dwarf_debug_flags);
Opts.MergeAllConstants = !Args.hasArg(OPT_fno_merge_all_constants);
+ Opts.AllowNonReturningFunctions = Args.hasArg(OPT_fallow_nonreturning_functions);
Opts.NoCommon = Args.hasArg(OPT_fno_common);
Opts.NoImplicitFloat = Args.hasArg(OPT_no_implicit_float);
Opts.OptimizeSize = getOptimizationLevelSize(Args);
diff --git a/test/CodeGen/nonreturning-function.c \
b/test/CodeGen/nonreturning-function.c new file mode 100644
index 0000000..8e61d1d
--- /dev/null
+++ b/test/CodeGen/nonreturning-function.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i386-unknown-unknown -x c++ %s -O3 -emit-llvm -o - | \
FileCheck -check-prefix=CHECK-CXX-BEFORE %s +// RUN: %clang_cc1 -triple \
i386-unknown-unknown -x c++ %s -O3 -fallow-nonreturning-functions -emit-llvm -o - | \
FileCheck -check-prefix=CHECK-CXX-AFTER %s +// CHECK-CXX-BEFORE: unreachable
+// CHECK-CXX-AFTER: ret i32 undef
+
+int nonreturning_func (void) {
+}
+
+int main() {
+ return nonreturning_func();
+}
[Attachment #7 (text/plain)]
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/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