This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
egcs, RFC: patch for possible -Wmissing-noreturn warning
- To: egcs-patches at cygnus dot com, egcs at cygnus dot com
- Subject: egcs, RFC: patch for possible -Wmissing-noreturn warning
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sun, 11 Oct 1998 13:26:02 -0400 (EDT)
I wanted to be able to automate finding functions which
could/should have the __noreturn__ attribute set. So I thought about
where in the compiler it could go. This is what I came up with.
--- egcs-CVS19981009/gcc/c-decl.c~ Fri Oct 9 23:57:25 1998
+++ egcs-CVS19981009/gcc/c-decl.c Sat Oct 10 13:23:17 1998
@@ -7190,6 +7190,10 @@ finish_function (nested)
current_function_returns_null |= can_reach_end;
+ if (!TREE_THIS_VOLATILE (fndecl)
+ && !current_function_returns_null && !current_function_returns_value)
+ warning ("function does not return, and is not declared `noreturn' ");
+
if (TREE_THIS_VOLATILE (fndecl) && current_function_returns_null)
warning ("`noreturn' function does return");
else if (warn_return_type && can_reach_end
As you can see, I plagiarized the warning below it and simply
reversed the condition checks. :-) It seems to work pretty well. I did
a bootstrap with it and found ~60 new places.
The problem is that I'm getting a small number of false
positives when `static inline void' functions are used. I'm also
getting some hits when exit() is called from main(). Although
technically correct (its thus a function which doesn't `return',) I
think its one case which should not be flagged.
Let's skip the fact that this warning is not controlled by a
-W flag for now. I wanted to get comments on whether this is the
correct approach, and help fixing the false positives.
Some of the false positives I'm getting during bootstrap:
> ./frame.c: In function `start_fde_sort':
> ./frame.c:266: warning: function does not return, and is not
> declared `noreturn'
> ./frame.c: In function `fde_insert':
> ./frame.c:272: warning: function does not return, and is not
> declared `noreturn'
> ./frame.c: In function `fde_split':
> ./frame.c:303: warning: function does not return, and is not
> declared `noreturn'
> ./frame.c: In function `frame_heapsort':
> ./frame.c:368: warning: function does not return, and is not
> declared `noreturn'
Looking at these functions, they clearly fall off their ends. Eg:
> static inline void
> fde_insert (fde_accumulator *accu, fde *this_fde)
> {
> accu->linear.array[accu->linear.count++] = this_fde;
> }
So why is the test flagging them? Is there another bit I need to
check besides:
current_function_returns_null && current_function_returns_value ??
Also if I have:
> main()
> {
> return 0;
> }
all's well.
However, if I have:
> main()
> {
> exit(0);
> }
I get:
> foo.c: In function `main':
> foo.c:4: warning: function does not return, and is not declared `noreturn'
Again, this is technically correct. But should we offer a pass from
`main', or do we encourage people to use the `return', not `exit' style?
Comments?
Thanks,
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Icon CMT Corp.