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 2E2653858C31; Mon,  6 May 2024 13:53:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E2653858C31
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1715003613;
	bh=KPIRcKP8n1cV9EK6+GNYVOE18tZztmyHk9NTip5RIPA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=PEeo+9MF4tYGx4pU+1uYFMqjamSq7CDvkyK+VZSfeo8Pn3DbhO51vDNdsSuR2Apqq
	 YVRlxmSR4cAYm0EHvt4tV4ACAyfN3u3Pt1BK8Rqzq2z9tR6wGByXsxF9I/5wWQapWF
	 5CoNzZ2doJyVEMJG+csZklYoKcoKxx+TVY2zDens=
From: "slyfox 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 13:53:32 +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: slyfox 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: cc
Message-ID: <bug-114872-4-BWr5z9mGmx@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

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 tha=
t 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 =3D ((void *)0);` gets saved in setjmp() with one v=
alue
(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:
       =E2=80=A2  they are local to the function that made the correspondin=
g setjmp()
call;
       =E2=80=A2  their values are changed between the calls to setjmp() an=
d longjmp();
and
       =E2=80=A2  they are not declared as volatile.
       Analogous remarks apply for siglongjmp().
"""

Sounds plausible?=