GCC 4.5 -Wall warns if your function has a non-void return type but returns. It can also detect an infinite loop which means that "falling off the end" doesn't actually imply a return, and therefore suppress the warning in that case. However, if the function is static, this infinite loop detection does not work: richard@deodand:~$ cat t.c void *a(void) { for(;;); } static void *b(void) { for(;;) { } } void foo(void) { b(); } richard@deodand:~$ /usr/local/gcc-4.5.0/bin/gcc -c -Wall t.c t.c: In function ‘b’: t.c:2:1: warning: no return statement in function returning non-void This real case where I spotted it was a thread function which is forced to have a return type of 'void *' by the signature of pthread_create(), but never returns because (by design) the thread never terminates. (I assume that the infinite loop detection isn't perfect, but obviously it shouldn't depend on the linkage of the containing function.) richard@deodand:~$ /usr/local/gcc-4.5.0/bin/gcc --version gcc (GCC) 4.5.0 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured with: richard@deodand:~$ ../configure -C --prefix=/usr/local/gcc-4.5.0 --enable-languages=c,c++ richard@deodand:~$ uname -a Linux deodand 2.6.32-5-686-bigmem #1 SMP Tue Jun 1 05:38:08 UTC 2010 i686 GNU/Linux richard@deodand:~$ dpkg -l libc6 ii libc6 2.11.1-3 Embedded GNU C Library: Shared libraries
It's because /* Complain if there's just no return statement. */ if (warn_return_type ... /* Normally, with -Wreturn-type, flow will complain, but we might optimize out static functions. */ && !TREE_PUBLIC (fndecl)) so this is very simple detection inside the frontend which is only done for functions with static linkage (to preserve warnings on unused static functions). Elsewhere you'd see "control reaches end of non-void function" instead. So the warning you see is really warning about no return statement, not about control reaching the end of a non-void function. And it does so by design just for functions with static linkage. So I'd say the warning is not false, it is just not useful for the case where the function does not return at all. Leaving the bug as enhancement request instead of closing as wontfix/invalid.
(In reply to comment #1) > > instead. So the warning you see is really warning about no return statement, > not about control reaching the end of a non-void function. And it does so > by design just for functions with static linkage. > > So I'd say the warning is not false, it is just not useful for the case > where the function does not return at all. > > Leaving the bug as enhancement request instead of closing as wontfix/invalid. > I don't see how one can detect that the function does not return from the FE, so I don't think this is possible to implement without moving the warning to the middle-end. Perhaps we should not care about unused static functions and remove this warning altogether. What happens if the static function actually returns and is used? Do you get 2 warnings?
(In reply to comment #2) > (In reply to comment #1) > > > > instead. So the warning you see is really warning about no return statement, > > not about control reaching the end of a non-void function. And it does so > > by design just for functions with static linkage. > > > > So I'd say the warning is not false, it is just not useful for the case > > where the function does not return at all. > > > > Leaving the bug as enhancement request instead of closing as wontfix/invalid. > > > > I don't see how one can detect that the function does not return from the FE, > so I don't think this is possible to implement without moving the warning to > the middle-end. Perhaps we should not care about unused static functions and > remove this warning altogether. > > What happens if the static function actually returns and is used? Do you get 2 > warnings? No, the Frontend sets TREE_NO_WARNING after it issued the warning.
We recently ran into this bug in Gnulib, and this affects downstream GNU test programs with threads that never return, because POSIX thread functions return 'void *'. For example, with GNU grep 3.6, './configure --enable-gcc-warnings; make' fails to build; see: https://bugs.gnu.org/44535 I worked around the problem by adding '#pragma GCC diagnostic ignored "-Wreturn-type"' to the Gnulib test module in question. It would be nice if such a workaround weren't needed.
PR97793 has some more info on this.
(In reply to eggert from comment #4) > We recently ran into this bug in Gnulib, and this affects downstream GNU > test programs with threads that never return, because POSIX thread functions > return 'void *'. For example, with GNU grep 3.6, './configure > --enable-gcc-warnings; make' fails to build; see: > > https://bugs.gnu.org/44535 > > I worked around the problem by adding '#pragma GCC diagnostic ignored > "-Wreturn-type"' to the Gnulib test module in question. It would be nice if > such a workaround weren't needed. Taking this as confirmation.