[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #14)
> 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?

So, if you can reproduce it, can you:
1) attach your *.s file and state which exact compiler you used (revision)
2) ideally show a gdb session with the important events, which setjmp was it (I
see
_setjmp and __sigsetjmp calls in the function), which exact function called
from the function ended up aborting/doing longjmp in the signal handler and
where is the crash
3) is it __pyx_t_6, __pyx_t_4 or some other pointer that triggers it (from the
line numbers in #c0 my guess was __pyx_t_6, but you talk about __pyx_t_4)

Yes, there are no volatile keywords on any of the vars, but without knowing
which setjmp call it is and from where longjmp jumps to it, it is hard to know
if the variables have been modified in between (then volatile would be
required) or if they
are only modified before the setjmp call or after the call that calls longjmp
(then volatile might not be required).