https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-04-13
Resolution|INVALID |---
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed.
i isn't modified in between setjmp and longjmp.
The C99 wording is:
"All accessible objects have values, and all other components of the abstract
machine have state, as of the time the longjmp function was called, except that
the values of objects of automatic storage duration that are local to the
function containing the invocation of the corresponding setjmp macro that do
not have volatile-qualified type and have been changed between the setjmp
invocation and longjmp call are indeterminate."
and i++ is moved from its location ~ as in the source to in between setjmp_ and
longjump by sched1.
Bet it happens because we only represent the abnormal edges from calls that
could longjmp to setjmp only on GIMPLE and not in RTL, so there is nothing in
RTL that would tell sched1 not to do such an optimization.
