public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/96181] New: Missing return statement now leads to crashes
@ 2020-07-13 10:40 arturo.laurenzi at gmail dot com
2020-07-13 10:50 ` [Bug c++/96181] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: arturo.laurenzi at gmail dot com @ 2020-07-13 10:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/96181] Missing return statement now leads to crashes
2020-07-13 10:40 [Bug c++/96181] New: Missing return statement now leads to crashes arturo.laurenzi at gmail dot com
@ 2020-07-13 10:50 ` pinskia at gcc dot gnu.org
2020-07-13 10:51 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-07-13 10:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/96181] Missing return statement now leads to crashes
2020-07-13 10:40 [Bug c++/96181] New: Missing return statement now leads to crashes arturo.laurenzi at gmail dot com
2020-07-13 10:50 ` [Bug c++/96181] " pinskia at gcc dot gnu.org
@ 2020-07-13 10:51 ` pinskia at gcc dot gnu.org
2020-07-13 11:26 ` redi at gcc dot gnu.org
2023-06-27 17:51 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-07-13 10:51 UTC (permalink / raw)
To: gcc-bugs
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 .
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/96181] Missing return statement now leads to crashes
2020-07-13 10:40 [Bug c++/96181] New: Missing return statement now leads to crashes arturo.laurenzi at gmail dot com
2020-07-13 10:50 ` [Bug c++/96181] " pinskia at gcc dot gnu.org
2020-07-13 10:51 ` pinskia at gcc dot gnu.org
@ 2020-07-13 11:26 ` redi at gcc dot gnu.org
2023-06-27 17:51 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2020-07-13 11:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/96181] Missing return statement now leads to crashes
2020-07-13 10:40 [Bug c++/96181] New: Missing return statement now leads to crashes arturo.laurenzi at gmail dot com
` (2 preceding siblings ...)
2020-07-13 11:26 ` redi at gcc dot gnu.org
@ 2023-06-27 17:51 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-27 17:51 UTC (permalink / raw)
To: gcc-bugs
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 ***
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-27 17:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-13 10:40 [Bug c++/96181] New: Missing return statement now leads to crashes arturo.laurenzi at gmail dot com
2020-07-13 10:50 ` [Bug c++/96181] " pinskia at gcc dot gnu.org
2020-07-13 10:51 ` pinskia at gcc dot gnu.org
2020-07-13 11:26 ` redi at gcc dot gnu.org
2023-06-27 17:51 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).