This is the mail archive of the gcc-patches@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: Killing "no return statement in function returning non-void"


On Sun, 19 Jun 2005, Jan Hubicka wrote:
> We've had some discussion with Roger offline.  There is still a
> difference for inlinable functions that gets elliminated completely (so
> they never get lowered), but same problem is with other warnings of this
> kind, so unless Roger or someone else speaks up, I will prepare real
> patch for this (probably on the way to summit tought)

I completely agree that this hack needs to be removed from the
C front-end.  For the benefit of the list (and future generations)
I thought I'd clarrify some of the thoughts discussed on IRC.


The fundamental problem is that several of the diagnostics issued
by GCC are generated after the front-ends, in the middle-end and
RTL optimizers and occasionally even the back-ends.  These warnings
only occur late, as for example with the noreturn warning, as they
rely on CFG or data flow analysis to correctly/accurately diagnose.

Unfortunately, these diagnostics are not reported by -fsyntax-only,
and in the case of inline and/or unused functions may never be
emitted unless they are called and the compiler decides to perform
"rest of compilation" on them.


This means that incorrect inline __asms or builtin intrinsics in
system headers, or even GCC code that is only used on some platforms may
have serious bugs that go unnoticed until the first time an attempt
is made to use them.  In the case of "no return", previous versions of
GCC failed to diagnose/report a problem, and the uninitialized return
value eventually led to a plethora of ICEs and wrong-code bugs.  The
short term hack was to bolt an ugly check into the C front-end.

The discussion on IRC covered better longer term solutions that would
catch not just noreturn, but other problems, such as asms not satisfying
their constraints, unrecognizable insns, reload failures etc...

As stevenb pointed out, it's prohibitive to fully process every function
due to the huge number of unused functions in system headers etc...
The solution I proposed was something like -fforce-used to enable extra
checking explicitly on the command line.  pinskia then made the excellent
suggestion that this is what -fkeep-inline-functions should be doing,
until we discovered that flag_keep_inline_functions isn't currently used
in the gcc/ directory!


I agree completely that the hack pointed out by Honza should go away,
but was wondering if there were alternate ways of fixing the more
general problem.

Any clever ideas?

Roger
--


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