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