This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] missing return warnings


Jan Hubicka wrote:

> For C++ there are number of cases I need to go through dealing with
> attempts to not instantiate non-inline methods that won't be needed.

I'm not sure exactly what cases you're referring to, but please be
careful.  For example, changing if/when we instantiate template
functions, or if/when we generate bodies for implicitly defined
constructors, destructors, or assignment operators would be a semantic
change, and contrary to the standard.

> For C it seems to be single case for return warning:
> /* PR c++/4872 */
> /* { dg-do compile } */
> /* { dg-options "-Wreturn-type" } */
> 
> static inline int f() {}     /* { dg-warning "return" "missing return" } */
> 
> In this case we produce missing return warning from frontend. 
> This however is not truly consistent - if I make the function used, we
> actually get two warnings - one from frontend, one from middle end
> (that is CFG aware and does not merely check for presence of return
> statement in  function). 

As you know, I don't like the middle end issuing warnings at all.  So,
you'll not be surprised that I think we should warn about this function
independent of optimization.  People want these warnings to tell them
about possible bugs in their software, not just the ones that affect
them in their current configuration, depending on how much optimization
applies, etc.  If we want the middle end to warn about this kind of
case, we should make sure that it does so for all functions, used or not.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]