public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/106190] [10/11/12 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all
Date: Tue, 18 Apr 2023 07:16:04 +0000	[thread overview]
Message-ID: <bug-106190-4-JGtzvOfFm2@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106190-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2d96422f4608c04d6a7c8444f14446c309416e24

commit r12-9424-g2d96422f4608c04d6a7c8444f14446c309416e24
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 28 10:56:44 2023 +0200

    sanopt: Return TODO_cleanup_cfg if any .{UB,HWA,A}SAN_* calls were lowered
[PR106190]

    The following testcase ICEs, because without optimization eh lowering
    decides not to duplicate finally block of try/finally and so we end up
    with variable guarded cleanup.  The sanopt pass creates a cfg that ought
    to be cleaned up (some IFN_UBSAN_* functions are lowered in this case with
    constant conditions in gcond and when not allowing recovery some bbs which
    end with noreturn calls actually have successor edges), but the cfg cleanup
    is actually (it is -O0) done only during the optimized pass.  We notice
    there that the d[1][a] = 0; statement which has an EH edge is unreachable
    (because ubsan would always abort on the out of bounds d[1] access), remove
    the EH landing pad and block, but because that block just sets a variable
    and jumps to another one which tests that variable and that one is
reachable
    from normal control flow, the __builtin_eh_pointer (1) later in there is
    kept in the IL and we ICE during expansion of that statement because the
    EH region has been removed.

    The following patch fixes it by doing the cfg cleanup already during
    sanopt pass if we create something that might need it, while the EH
    landing pad is then removed already during sanopt pass, there is ehcleanup
    later and we don't ICE anymore.

    2023-03-28  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/106190
            * sanopt.cc (pass_sanopt::execute): Return TODO_cleanup_cfg if any
            of the IFN_{UB,HWA,A}SAN_* internal fns are lowered.

            * gcc.dg/asan/pr106190.c: New test.

    (cherry picked from commit 39a43dc336561e0eba0de477b16c7355f19d84ee)

  parent reply	other threads:[~2023-04-18  7:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 19:40 [Bug c/106190] New: [12/13 Regression] ICE in expand_builtin_eh_common, at except.cc:2084 gscfq@t-online.de
2022-07-04 20:13 ` [Bug middle-end/106190] " pinskia at gcc dot gnu.org
2022-07-04 22:17 ` pinskia at gcc dot gnu.org
2022-07-04 22:25 ` pinskia at gcc dot gnu.org
2022-07-04 22:25 ` [Bug middle-end/106190] [12/13 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all pinskia at gcc dot gnu.org
2022-07-05  7:58 ` rguenth at gcc dot gnu.org
2022-07-07 12:44 ` marxin at gcc dot gnu.org
2022-07-07 12:44 ` [Bug middle-end/106190] [9/10/11/12/13 " marxin at gcc dot gnu.org
2022-07-14 12:47 ` marxin at gcc dot gnu.org
2022-07-25 15:16 ` rguenth at gcc dot gnu.org
2022-07-25 15:16 ` [Bug middle-end/106190] [10/11/12/13 " rguenth at gcc dot gnu.org
2023-03-27 14:15 ` jakub at gcc dot gnu.org
2023-03-27 14:58 ` jakub at gcc dot gnu.org
2023-03-28  8:58 ` cvs-commit at gcc dot gnu.org
2023-03-28  9:17 ` [Bug middle-end/106190] [10/11/12 " jakub at gcc dot gnu.org
2023-04-18  7:16 ` cvs-commit at gcc dot gnu.org [this message]
2023-04-18  7:21 ` [Bug middle-end/106190] [10/11 " jakub at gcc dot gnu.org
2023-05-02 20:16 ` cvs-commit at gcc dot gnu.org
2023-05-03  9:26 ` [Bug middle-end/106190] [10 " jakub at gcc dot gnu.org
2023-05-03 15:23 ` cvs-commit at gcc dot gnu.org
2023-05-04  7:18 ` jakub at gcc dot gnu.org
2024-03-11  1:03 ` chenxiaolong at loongson dot cn

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-106190-4-JGtzvOfFm2@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: link
Be 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).