https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
On further thought, this is really an invalid transform, because the value
becomes "clobbered" only if it was changed between setjmp and longjmp:
(C11 7.13.2.1 "The longjmp function")
> 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.
In the testcase, the assignment 'vb = 1' did not happen in the abstract
machine.
Moving back to UNCONFIRMED, both because the transform is invalid, and because
lifting assignments to pseudos across calls in sched1 seems useless if not
harmful to performance and code size.
(that said, the -Wclobbered diagnostic still points to a potential issue, so it
shouldn't be ignored)
