From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 45A543858D33; Mon,  6 May 2024 17:59:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45A543858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1715018390;
	bh=nTueDU4EWl0cCnxTFl6EVwiQKuo9kuNT9uphZ++eyIs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=VGM4ifMgMG5IACuvxOXOSi5HPG9HkYzE7gm0f59sBdG4JqGnjVAu5Vahio2ETZKNG
	 RXCu1CMeF4r1OLfzZ4EKgcIEoKNKReUSlrWJ/iEJDDlCUN1haSzfCAhG88nrMYdHvE
	 pYiCZuOTHLAnYBsL8njqDWxACNFraNUP5rqEso1o=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation
 with -O2 after commit r13-8037
Date: Mon, 06 May 2024 17:59:50 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.2.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114872-4-Rqt4wNqHRc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114872-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114872-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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.
>=20
> One of the unusual properties of
> __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__() is t=
hat
> it raises 2 signals while it gets executed:
>=20
> - 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.
>=20
> I see no `volatile` annotations anywhere in the
> __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__().
>=20
> My wild guess would be that:
> 1. `PyObject *__pyx_t_4 =3D ((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
>=20
> 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.
>=20
> To cite `man setjmp`:
>=20
> """
> CAVEATS
>        The  compiler  may  optimize  variables  into registers, and
> longjmp() may restore the values of other registers in addition to the st=
ack
> pointer and program counter.  Consequently, the values of automatic
>        variables are unspecified after a call to longjmp() if they meet a=
ll
> the following criteria:
>        =E2=80=A2  they are local to the function that made the correspond=
ing
> setjmp() call;
>        =E2=80=A2  their values are changed between the calls to setjmp() =
and
> longjmp(); and
>        =E2=80=A2  they are not declared as volatile.
>        Analogous remarks apply for siglongjmp().
> """
>=20
> 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 i=
t (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 k=
now
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 longj=
mp
(then volatile might not be required).=