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]

egcs, RFC: patch for possible -Wmissing-noreturn warning


	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.


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