[Bug c++/96181] New: Missing return statement now leads to crashes

[Bug c++/96181] New: Missing return statement now leads to crashes

[arturo.laurenzi at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96181

            Bug ID: 96181
           Summary: Missing return statement now leads to crashes
           Product: gcc
           Version: 8.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arturo.laurenzi at gmail dot com
  Target Milestone: ---

Consider the simple code snippet where a function returning an int is missing a
return statement, BUT client code is actually not using the return value at all

---
#include <cstdio>

int glob = 1;

bool func(int i)
{
    printf("setting glob to %d.. \n", i);
    glob = i;
}  // missing return statement


int main()
{
    func(10);  // return value is not used!
    printf("cleanly exiting..\n");
    fflush(stdout);
}
---

G++ up to 7.5 would compile such code in a way that makes it run just fine
(remember, return value is actually ignored), even with optimizations turned
on. G++ 8.1 (and above) will instead omit the ret instruction inside the
assembly for func, causing the execution to crash systematically:

---
.LC0:
        .string "setting glob to %d.. \n"
func(int):
        push    rbx
        mov     esi, edi
        mov     ebx, edi
        xor     eax, eax
        mov     edi, OFFSET FLAT:.LC0
        call    printf
        mov     DWORD PTR glob[rip], ebx
main:
        sub     rsp, 8
        mov     edi, 10
        call    func(int)
---

Now, I understand the code snipped is probably broken. However, this change
breaks old code that would work just fine by ignoring the undefined return
value. Was this intentional? Why was it done, if so?

Thanks,
Arturo

[Bug c++/96181] Missing return statement now leads to crashes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96181

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C++ says it is undefined at the point of fall through point.  THIS is different
from C where it is undefined if the value was used.

AND yes this was done on purpose.  If you want to catch it at runtime you could
use -fsanitize=undefined.

[Bug c++/96181] Missing return statement now leads to crashes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96181

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is also mentioned on https://gcc.gnu.org/gcc-8/porting_to.html .

[Bug c++/96181] Missing return statement now leads to crashes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96181

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Arturo Laurenzi from comment #0)
> Now, I understand the code snipped is probably broken. However, this change
> breaks old code that would work just fine by ignoring the undefined return
> value.

It didn't work fine, it had undefined behaviour. It just appeared to work fine.

GCC clearly warns you about it:

96181.C: In function ‘bool func(int)’:
96181.C:9:1: warning: no return statement in function returning non-void
[-Wreturn-type]
    9 | }  // missing return statement
      | ^

If you're ignoring such warnings routinely maybe you should use
-Werror=return-type to force yourself to fix them.

[Bug c++/96181] Missing return statement now leads to crashes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96181

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

*** This bug has been marked as a duplicate of bug 86761 ***