From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E64003937C2B; Wed, 8 May 2024 08:18:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E64003937C2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1715156331; bh=rPi/guGOgoS6gfqjBLlbonU+AMwLLmgA2N+rGh/aqCM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Bohi1Xgzv7b5f0CdncX1u47ZatFyXUQK6RQFUjM6oNUcze5GLTst6RepgQiCToEY9 Zwm1t18SV8JOaCLtBp3jH7F8mDRTszB0fHqxpbbJCWZjZLWQ2grh5JuATVw/Pms6LE bXg6fnjtSJRxqPL5FlrgOGjKF7hYprZ7wE+XZsTA= From: "slyfox at gcc dot 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: Wed, 08 May 2024 08:18:49 +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: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114872 --- Comment #23 from Sergei Trofimovich --- At SIGSEGV site the code is an unconditional NULL dereference due to dereference of `xor %esi,%esi` result from `gdb`. 797 if (op !=3D _Py_NULL) { 0x00007f940c871563 <+2563>: cmpq $0x0,-0xc8(%rbp) 0x00007f940c87156b <+2571>: je 0x7f940c871583 <__pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__+2595> 242 return _Py_CAST(PY_INT32_T, op->ob_refcnt) < 0; 0x00007f940c87156d <+2573>: xor %esi,%esi =3D> 0x00007f940c87156f <+2575>: mov (%rsi),%rax In `element-verbose.S` it is: # /usr/include/python3.12/object.h:797: if (op !=3D _Py_NULL) { .loc 5 797 8 is_stmt 0 view .LVU65876 cmpq $0, -200(%rbp)<>#, %sfp je<---->.L12727>#, .loc 5 798 9 is_stmt 1 view .LVU65877 .LVL15705: .LBB49946: .LBI49946: .loc 5 696 37 view .LVU65878 .LBB49947: .loc 5 700 5 view .LVU65879 .LBB49948: .LBI49948: .loc 5 239 36 view .LVU65880 .LBB49949: .loc 5 242 5 view .LVU65881 # /usr/include/python3.12/object.h:242: return _Py_CAST(PY_INT32_T, op->ob_refcnt) < 0; .loc 5 242 12 is_stmt 0 view .LVU65882 xorl %esi, %esi # r movq (%rsi), %rax # __pyx_t_6_208(ab)->D.11083.ob_refcnt, _991 Looking at other sites in `element-verbose.S` for comparison do try to use `-0xc8(%rbp)` contents: # /usr/include/python3.12/object.h:797: if (op !=3D _Py_NULL) { .loc 5 797 8 is_stmt 0 view .LVU66162 cmpq $0, -200(%rbp) #, %sfp je .L12782>#, .loc 5 798 9 is_stmt 1 view .LVU66163 .LVL15760: .LBB50093: .LBI50093: .loc 5 696 37 view .LVU66164 .LBB50094: .loc 5 700 5 view .LVU66165 .LBB50095: .LBI50095: .loc 5 239 36 view .LVU66166 .LBB50096: .loc 5 242 5 view .LVU66167 # /usr/include/python3.12/object.h:242: return _Py_CAST(PY_INT32_T, op->ob_refcnt) < 0; .loc 5 242 12 is_stmt 0 view .LVU66168 movq -200(%rbp), %rdx # %sfp, r movq (%rdx), %rax # __pyx_t_6_10(ab)->D.11083.ob_refcnt, _1070 Thus my guess is that something clobbered `-200(%rbp)` value across setjmp()/longjmp(). Trying to trace: $ gdb -p `pgrep sage-ipython` (gdb) break __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__cal= l__ (gdb) continue # trigger break with with ` libgap.AbelianGroup(0,0,0)` (gdb) disassemble Dump of assembler code for function __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__: =3D> 0x00007f4ed9981b60 <+0>: push %rbp 0x00007f4ed9981b61 <+1>: mov %rsp,%rbp # Populating `%rbp`: (gdb) nexti (gdb) nexti (gdb) disassemble Dump of assembler code for function __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__: 0x00007f4ed9981b60 <+0>: push %rbp 0x00007f4ed9981b61 <+1>: mov %rsp,%rbp =3D> 0x00007f4ed9981b64 <+4>: push %r15 (gdb) print $rbp-200 $2 =3D (void *) 0x7ffd2824c5e8 (gdb) watch *(int*)(void *) 0x7ffd2824c5e8 Hardware watchpoint 2: *(int*)(void *) 0x7ffd2824c5e8 (gdb) continue Continuing. Thread 1 "sage-ipython" hit Hardware watchpoint 2: *(int*)(void *) 0x7ffd2824c5e8 Old value =3D 673498624 New value =3D 0 0x00007f98e609d2a8 in __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__ ( __pyx_v_self=3D__pyx_v_self@entry=3D0x7f98dfe70dc0, __pyx_v_args=3D__pyx_v_args@entry=3D(, , )) at /usr/src/debug/sci-mathematics/sagemath-standard-10.3/sagemath-standard-10.= 3-python3_12/build/cythonized/sage/libs/gap/element.c:26192 26192 __pyx_t_6 =3D NULL; NULL store. (gdb) continue Continuing. Thread 1 "sage-ipython" hit Hardware watchpoint 2: *(int*)(void *) 0x7ffd2824c5e8 Old value =3D 0 New value =3D -538669696 __Pyx_GetItemInt_List_Fast (wraparound=3D0, boundscheck=3D1, i=3D2, o=3D[, , ]) at /usr/src/debug/sci-mathematics/sagemath-standard-10.3/sagemath-standard-10.= 3-python3_12/build/cythonized/sage/libs/gap/element.c:38070 38070 Py_INCREF(r); Create an object? (gdb) continue Continuing. Thread 1 "sage-ipython" received signal SIGABRT, Aborted. 0x00007f99428617a7 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120 120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) Abort. (gdb) continue Continuing. Thread 1 "sage-ipython" received signal SIGSEGV, Segmentation fault. 0x00007f98e609c56f in _Py_IsImmortal (op=3D0x0) at /usr/include/python3.12/object.h:242 242 return _Py_CAST(PY_INT32_T, op->ob_refcnt) < 0; SIGSEGV. Note that all two memory references happen before longjmp() (the ABORT). Why did `gcc` generate unconditional NULL dereference here? I suspect it somehow inferred that `__pyx_t_6 =3D NULL;` in that branch, but not before comparison.=