Bug 44511 - Misdetects missing return with non-void return type, but only if the function is static
Summary: Misdetects missing return with non-void return type, but only if the function...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.5.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2010-06-13 08:54 UTC by Richard Kettlewell
Modified: 2024-01-12 00:51 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2021-08-10 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Kettlewell 2010-06-13 08:54:52 UTC
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
Comment 1 Richard Biener 2010-06-13 10:33:03 UTC
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.
Comment 2 Manuel López-Ibáñez 2010-06-13 13:49:15 UTC
(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?

Comment 3 Richard Biener 2010-06-13 14:18:27 UTC
(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.

Comment 4 Paul Eggert 2020-11-22 02:18:41 UTC
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.
Comment 5 Jakub Jelinek 2020-11-22 11:38:27 UTC
PR97793 has some more info on this.
Comment 6 Eric Gallager 2020-11-22 21:10:42 UTC
(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.