https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
Sergei Trofimovich <slyfox at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |slyfox at gcc dot gnu.org
--- Comment #14 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
I reproduced the `SIGSEGV` on Gentoo ~amd64 and ::sage-on-gentoo overlay
against sci-mathematics/sagemath-standard package.
One of the unusual properties of
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() is that it
raises 2 signals while it gets executed:
- SIGABRT handler uses longjmp() to return to the ~beginning of a function
- and then SIGSEGV happens at cleanup when an attempt to dereference the
pointer happens.
I see no `volatile` annotations anywhere in the
__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__().
My wild guess would be that:
1. `PyObject *__pyx_t_4 = ((void *)0);` gets saved in setjmp() with one value
(probably NULL)
2. updated at some point later in the same function to non-NULL that `gcc` can
infer and throw away all later `NULL` checks
3. then SIGABRT returns with longjmp() by accidentally resetting
I would expect `__pyx_t_4` to require volatile annotation for such an
`element.i` definition. Or `longjmp()` should be called from a `((noipa))`
function to force register spill/reload on stack.
To cite `man setjmp`:
"""
CAVEATS
The compiler may optimize variables into registers, and longjmp()
may restore the values of other registers in addition to the stack pointer and
program counter. Consequently, the values of automatic
variables are unspecified after a call to longjmp() if they meet all the
following criteria:
• they are local to the function that made the corresponding setjmp()
call;
• their values are changed between the calls to setjmp() and longjmp();
and
• they are not declared as volatile.
Analogous remarks apply for siglongjmp().
"""
Sounds plausible?
