public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug fortran/111783] New: 'exit' intrinsic should be marked as @ 2023-10-12 11:59 burnus at gcc dot gnu.org 2023-10-12 16:00 ` [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn pinskia at gcc dot gnu.org ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: burnus at gcc dot gnu.org @ 2023-10-12 11:59 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111783 Bug ID: 111783 Summary: 'exit' intrinsic should be marked as Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Compiling testsuite/gfortran.dg/team_number_1.f90 with -O3 produces the following optimized dump: _gfortran_exit_i4 (0); _gfortran_exit_i4 (0); _gfortran_stop_numeric (2, 0); } The last three statements could be removed as the 'EXIT' intrinsic subroutine is known not to return. Thus, we should set ATTR_NORETURN_NOTHROW_LIST (cf. fortran/f95-lang.cc). There are probably more, at least the ABORT intrinsic subroutine and the functions associated with STOP / ERROR STOP like _gfortran_stop_numeric. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn 2023-10-12 11:59 [Bug fortran/111783] New: 'exit' intrinsic should be marked as burnus at gcc dot gnu.org @ 2023-10-12 16:00 ` pinskia at gcc dot gnu.org 2023-10-12 19:19 ` anlauf at gcc dot gnu.org 2023-10-12 19:28 ` anlauf at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: pinskia at gcc dot gnu.org @ 2023-10-12 16:00 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111783 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|'exit' intrinsic should be |'exit' intrinsic should be |marked as |marked as noreturn Last reconfirmed| |2023-10-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Confirmed. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn 2023-10-12 11:59 [Bug fortran/111783] New: 'exit' intrinsic should be marked as burnus at gcc dot gnu.org 2023-10-12 16:00 ` [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn pinskia at gcc dot gnu.org @ 2023-10-12 19:19 ` anlauf at gcc dot gnu.org 2023-10-12 19:28 ` anlauf at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: anlauf at gcc dot gnu.org @ 2023-10-12 19:19 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111783 anlauf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) > There are probably more, at least the ABORT intrinsic subroutine and > the functions associated with STOP / ERROR STOP like _gfortran_stop_numeric. trans-decl.cc has: /* STOP doesn't return. */ TREE_THIS_VOLATILE (gfor_fndecl_stop_numeric) = 1; TREE_THIS_VOLATILE (gfor_fndecl_stop_string) = 1; TREE_THIS_VOLATILE (gfor_fndecl_error_stop_numeric) = 1; TREE_THIS_VOLATILE (gfor_fndecl_error_stop_string) = 1; plus a few more, so these are already accounted for. Try: stop 1 error stop 2 stop "3" end The dump-tree-optimized only contains the first even at -O0, as it should be, shouldn't it? This leaves ABORT and EXIT to deal with. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn 2023-10-12 11:59 [Bug fortran/111783] New: 'exit' intrinsic should be marked as burnus at gcc dot gnu.org 2023-10-12 16:00 ` [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn pinskia at gcc dot gnu.org 2023-10-12 19:19 ` anlauf at gcc dot gnu.org @ 2023-10-12 19:28 ` anlauf at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: anlauf at gcc dot gnu.org @ 2023-10-12 19:28 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111783 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > This leaves ABORT and EXIT to deal with. Speaking to myself: subroutine s1() call exit(1) stop 98 end subroutine s2() call abort stop 99 end Here the STOP statements do not show up in .optimized. So I am wondering where the _gfortran_exit_i4 in comment#0 come from? ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-10-12 19:28 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-10-12 11:59 [Bug fortran/111783] New: 'exit' intrinsic should be marked as burnus at gcc dot gnu.org 2023-10-12 16:00 ` [Bug fortran/111783] 'exit' intrinsic should be marked as noreturn pinskia at gcc dot gnu.org 2023-10-12 19:19 ` anlauf at gcc dot gnu.org 2023-10-12 19:28 ` anlauf 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).