public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
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 [thread overview] Message-ID: <bug-114872-4-BWr5z9mGmx@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114872-4@http.gcc.gnu.org/bugzilla/> 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?
next prev parent reply other threads:[~2024-05-06 13:53 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-27 18:57 [Bug c/114872] New: Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7 arojas at archlinux dot org 2024-04-27 18:59 ` [Bug c/114872] " arojas at archlinux dot org 2024-04-27 19:03 ` pinskia at gcc dot gnu.org 2024-04-27 19:05 ` pinskia at gcc dot gnu.org 2024-04-27 19:06 ` arojas at archlinux dot org 2024-04-27 20:00 ` [Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037 pinskia at gcc dot gnu.org 2024-04-29 15:53 ` sjames at gcc dot gnu.org 2024-04-29 16:00 ` jakub at gcc dot gnu.org 2024-04-29 20:05 ` arojas at archlinux dot org 2024-05-01 1:00 ` sjames at gcc dot gnu.org 2024-05-01 1:01 ` sjames at gcc dot gnu.org 2024-05-01 1:01 ` sjames at gcc dot gnu.org 2024-05-01 1:03 ` sjames at gcc dot gnu.org 2024-05-03 11:07 ` dima.pasechnik at cs dot ox.ac.uk 2024-05-03 11:26 ` dima.pasechnik at cs dot ox.ac.uk 2024-05-06 13:53 ` slyfox at gcc dot gnu.org [this message] 2024-05-06 17:29 ` jakub at gcc dot gnu.org 2024-05-06 17:59 ` jakub at gcc dot gnu.org 2024-05-06 21:41 ` slyfox at gcc dot gnu.org 2024-05-06 22:08 ` slyfox at gcc dot gnu.org 2024-05-06 22:45 ` dima.pasechnik at cs dot ox.ac.uk 2024-05-07 10:45 ` jakub at gcc dot gnu.org 2024-05-07 11:05 ` slyfox at gcc dot gnu.org 2024-05-07 22:13 ` slyfox at gcc dot gnu.org 2024-05-08 8:18 ` slyfox at gcc dot gnu.org 2024-05-08 8:27 ` rguenth at gcc dot gnu.org 2024-05-08 18:10 ` slyfox at gcc dot gnu.org 2024-05-08 19:17 ` dima.pasechnik at cs dot ox.ac.uk 2024-05-08 19:35 ` pinskia at gcc dot gnu.org 2024-05-08 19:58 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114872-4-BWr5z9mGmx@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).