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 [EMAIL PROTECTED] (650) 331-3385 x713