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 sanitizer/112709] [13 Regression] address sanitize and returns_twice causes an ICE
Date: Fri, 15 Mar 2024 23:29:48 +0000	[thread overview]
Message-ID: <bug-112709-4-VaW3QvC1WG@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-112709-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:3d231faed146352543794bf9e9afbee2e6c76889

commit r13-8453-g3d231faed146352543794bf9e9afbee2e6c76889
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 13 09:16:45 2024 +0100

    gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice
calls [PR112709]

    ubsan, asan (both PR112709) and _BitInt lowering (PR113466) want to
    insert some instrumentation or adjustment statements before some statement.
    This unfortunately creates invalid IL if inserting before a returns_twice
    call, because we require that such calls are the first statement in a basic
    block and that we have an edge from the .ABNORMAL_DISPATCHER block to
    the block containing the returns_twice call (in addition to other edge(s)).

    The following patch adds helper functions for such insertions and uses it
    for now in ubsan (I'll post a follow up which uses it in asan and will
    work later on the _BitInt lowering PR).

    In particular, if the bb with returns_twice call at the start has just
    2 edges, one EDGE_ABNORMAL from .ABNORMAL_DISPATCHER and another
    (non-EDGE_ABNORMAL/EDGE_EH) from some other bb, it just inserts the
    statement or sequence on that other edge.
    If the bb has more predecessor edges or the one not from
    .ABNORMAL_DISPATCHER is e.g. an EH edge (this latter case likely shouldn't
    happen, one would need labels or something like that), the patch splits the
    block with returns_twice call such that there is just one edge next to
    .ABNORMAL_DISPATCHER edge and adjusts PHIs as needed to make it happen.
    The functions also replace uses of PHIs from the returns_twice bb with
    the corresponding PHI arguments, because otherwise it would be invalid IL.

    E.g. in ubsan/pr112709-2.c (qux) we have before the ubsan pass
      <bb 10> :
      # .MEM_5(ab) = PHI <.MEM_4(9), .MEM_25(ab)(11)>
      # _7(ab) = PHI <_20(9), _8(ab)(11)>
      # .MEM_21(ab) = VDEF <.MEM_5(ab)>
      _22 = bar (*_7(ab));
    where bar is returns_twice call and bb 11 has .ABNORMAL_DISPATCHER call,
    this patch instruments it like:
      <bb 9> :
      # .MEM_4 = PHI <.MEM_17(ab)(4), .MEM_10(D)(5), .MEM_14(ab)(8)>
      # DEBUG BEGIN_STMT
      # VUSE <.MEM_4>
      _20 = p;
      # .MEM_27 = VDEF <.MEM_4>
      .UBSAN_NULL (_20, 0B, 0);
      # VUSE <.MEM_27>
      _2 = __builtin_dynamic_object_size (_20, 0);
      # .MEM_28 = VDEF <.MEM_27>
      .UBSAN_OBJECT_SIZE (_20, 1024, _2, 0);

      <bb 10> :
      # .MEM_5(ab) = PHI <.MEM_28(9), .MEM_25(ab)(11)>
      # _7(ab) = PHI <_20(9), _8(ab)(11)>
      # .MEM_21(ab) = VDEF <.MEM_5(ab)>
      _22 = bar (*_7(ab));
    The edge from .ABNORMAL_DISPATCHER is there just to represent the
    returning for 2nd and later times, the instrumentation can't be
    done at that point as there is no code executed during that point.
    The ubsan/pr112709-1.c testcase includes non-virtual PHIs to cover
    the handling of those as well.

    2024-03-13  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/112709
            * gimple-iterator.h (gsi_safe_insert_before,
            gsi_safe_insert_seq_before): Declare.
            * gimple-iterator.cc: Include gimplify.h.
            (edge_before_returns_twice_call, adjust_before_returns_twice_call,
            gsi_safe_insert_before, gsi_safe_insert_seq_before): New functions.
            * ubsan.cc (instrument_mem_ref, instrument_pointer_overflow,
            instrument_nonnull_arg, instrument_nonnull_return): Use
            gsi_safe_insert_before instead of gsi_insert_before.
            (maybe_instrument_pointer_overflow): Use force_gimple_operand,
            gimple_seq_add_seq_without_update and gsi_safe_insert_seq_before
            instead of force_gimple_operand_gsi.
            (instrument_object_size): Likewise.  Use gsi_safe_insert_before
            instead of gsi_insert_before.

            * gcc.dg/ubsan/pr112709-1.c: New test.
            * gcc.dg/ubsan/pr112709-2.c: New test.

    (cherry picked from commit 364c684c474841e3c9c04e025a5c1bca49705c86)

  parent reply	other threads:[~2024-03-15 23:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-25  5:43 [Bug tree-optimization/112709] New: ICE verify_flow_info failed during GIMPLE pass: asan0 iamanonymous.cs at gmail dot com
2023-11-25 19:53 ` [Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE pinskia at gcc dot gnu.org
2023-11-27 12:46 ` jakub at gcc dot gnu.org
2023-11-27 13:00 ` jakub at gcc dot gnu.org
2024-03-07 21:01 ` law at gcc dot gnu.org
2024-03-08 17:02 ` jakub at gcc dot gnu.org
2024-03-08 17:19 ` jakub at gcc dot gnu.org
2024-03-08 17:20 ` jakub at gcc dot gnu.org
2024-03-12 10:35 ` cvs-commit at gcc dot gnu.org
2024-03-12 13:22 ` jakub at gcc dot gnu.org
2024-03-13  8:18 ` cvs-commit at gcc dot gnu.org
2024-03-13  8:20 ` cvs-commit at gcc dot gnu.org
2024-03-15 14:15 ` [Bug sanitizer/112709] [13 " jakub at gcc dot gnu.org
2024-03-15 23:29 ` cvs-commit at gcc dot gnu.org [this message]
2024-03-15 23:29 ` cvs-commit at gcc dot gnu.org
2024-03-18 14:42 ` 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-112709-4-VaW3QvC1WG@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).