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).