From: Richard Biener <richard.guenther@gmail.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: "jakub@redhat.com" <jakub@redhat.com>,
gcc Patches <gcc-patches@gcc.gnu.org>
Subject: Re: HELP: Questions on unshare_expr
Date: Wed, 17 Jan 2024 07:43:42 +0100 [thread overview]
Message-ID: <CAFiYyc33T8mjucGV_JVD5vHOsjMZbPPjTJ=0BmPnuckq-ANYfQ@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc1yB2WxeiMBcx4ewdb+GaJJu2a8nQPe0_5JqSmX48H2pw@mail.gmail.com>
On Wed, Jan 17, 2024 at 7:42 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao <qing.zhao@oracle.com> wrote:
> >
> >
> >
> > > On Jan 15, 2024, at 4:31 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> > >
> > >> All my questions for unshare_expr relate to a LTO bug that I currently stuck with
> > >> when using .ACCESS_WITH_SIZE in bound sanitizer (only with -flto, without -flto, no issue):
> > >>
> > >> [opc@qinzhao-aarch64-ol8 gcc]$ sh t
> > >> during IPA pass: modref
> > >> t.c:20:1: internal compiler error: tree code ‘ssa_name’ is not supported in LTO streams
> > >> 0x14c3993 lto_write_tree
> > >> ../../latest-gcc-write/gcc/lto-streamer-out.cc:561
> > >> 0x14c3aeb lto_output_tree_1
> > >>
> > >> And the value of the tree node that triggered the ICE is:
> > >> (gdb) call debug_tree(expr)
> > >> <ssa_name 0xfffff5761e60 type <error_mark 0xfffff56c0e58>
> > >> nothrow
> > >> def_stmt
> > >> version:13 in-free-list>
> > >>
> > >> Is there any good way to debug LTO bug?
> > >
> > > This happens usually when you have a VLA type and its type fields are not
> > > properly gimplified which usually happens because the frontend fails to
> > > insert a gimplification point for it (a DECL_EXPR).
> >
> > I found an old gcc bug
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
> > ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
> >
> > Which is very similar to the bug I am having right now.
> >
> > After further study, I suspect that the issue I am having right now with the LTO streaming also
> > relate to “unshare_expr”, “save_expr”, and the combination of these two, I suspect that
> > the current gcc cannot handle the combination of these two correctly for my case.
> >
> > My testing case is:
> >
> > #include <stdlib.h>
> > void __attribute__((__noinline__)) setup_and_test_vla (int n1, int n2, int m)
> > {
> > struct foo {
> > int n;
> > int p[][n2][n1] __attribute__((counted_by(n)));
> > } *f;
> >
> > f = (struct foo *) malloc (sizeof(struct foo) + m*sizeof(int[n2][n1]));
> > f->n = m;
> > f->p[m][n2][n1]=1;
> > return;
> > }
> >
> > int main(int argc, char *argv[])
> > {
> > setup_and_test_vla (10, 11, 20);
> > return 0;
> > }
> >
> > Failed with
> > my_gcc -Os -fsanitize=bounds -flto
> >
> > If changing either n1 or n2 to a constant, the testing passed.
> > If deleting -flto, the testing passed too.
> >
> > I double checked my code per the suggestions provided by you and Jakub in this
> > email thread, and I think the code should be fine.
> >
> > The code is following:
> >
> > =====
> > 504 /* Instrument array bounds for INDIRECT_REFs whose pointers are
> > 505 POINTER_PLUS_EXPRs of calls to .ACCESS_WITH_SIZE. We create special
> > 506 builtins that gets expanded in the sanopt pass, and make an array
> > 507 dimension of it. ARRAY is the pointer to the base of the array,
> > 508 which is a call to .ACCESS_WITH_SIZE, *OFFSET is the offset to the
> > 509 beginning of array.
> > 510 Return NULL_TREE if no instrumentation is emitted. */
> > 511
> > 512 tree
> > 513 ubsan_instrument_bounds_indirect_ref (location_t loc, tree array, tree *offset)
> > 514 {
> > 515 if (!is_access_with_size_p (array))
> > 516 return NULL_TREE;
> > 517 tree bound = get_bound_from_access_with_size (array);
> > 518 /* The type of the call to .ACCESS_WITH_SIZE is a pointer type to
> > 519 the element of the array. */
> > 520 tree element_size = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array)));
> > 521 gcc_assert (bound);
> > 522
> > 523 /* Given the offset, and the size of each element, the index can be
> > 524 computed as: offset/element_size. */
> > 525 *offset = save_expr (*offset);
> > 526 tree index = fold_build2 (EXACT_DIV_EXPR,
> > 527 sizetype, *offset,
> > 528 unshare_expr (element_size));
> > 529 /* Create a "(T *) 0" tree node to describe the original array type.
> > 530 We get the original array type from the first argument of the call to
> > 531 .ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, num_bytes, -1).
> > 532
> > 533 Originally, REF is a COMPONENT_REF with the original array type,
> > 534 it was converted to a pointer to an ADDR_EXPR, and the ADDR_EXPR's
> > 535 first operand is the original COMPONENT_REF. */
> > 536 tree ref = CALL_EXPR_ARG (array, 0);
> > 537 tree array_type
> > 538 = unshare_expr (TREE_TYPE (TREE_OPERAND (TREE_OPERAND(ref, 0), 0)));
> > 539 tree zero_with_type = build_int_cst (build_pointer_type (array_type), 0);
> > 540 return build_call_expr_internal_loc (loc, IFN_UBSAN_BOUNDS,
> > 541 void_type_node, 3, zero_with_type,
> > 542 index, bound);
> > 543 }
> >
> > =====
> >
> > Inside gdb, the guilty IR failed in LTO streaming is from the above line 520:
> > TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array))),
> >
> > When I use this tree node as an operand of the expression at line 526, I added
> > unshare_expr.
> >
> > However, I still see the guilty IR as in gdb:
> >
> > unit-size <mult_expr 0xfffff5aabf90 type <integer_type 0xfffff57c0000 sizetype>
> > side-effects
> > arg:0 <mult_expr 0xfffff5aabf68 type <integer_type 0xfffff57c0000 sizetype>
> >
> > arg:0 <ssa_name 0xfffff5761e18 type <error_mark 0xfffff56c0e58>
> > nothrow
> > def_stmt
> > version:12 in-free-list>
> > arg:1 <ssa_name 0xfffff5761e60 type <error_mark 0xfffff56c0e58>
> > nothrow
> > def_stmt
> > version:13 in-free-list>>
> > arg:1 <integer_cst 0xfffff56c10c8 constant 4>>
> >
> >
> > I have been stuck with this bug for quite some time.
> > Any help is helpful.
>
> The above hasn't been gimplified correctly, you'd instead see
> a D.1234 in there, not an expression with SSA names. That happens
> when the frontend fails to emit a DECL_EXPR for a decl with this
> type.
.. which then also results in missing unsharing of this expression
(so the SSA names leak in)
>
> >
> > Qing
> >
> > >
> > >> Thanks a lot for the help.
> > >>
> > >> Qing
> > >>
> >
next prev parent reply other threads:[~2024-01-17 6:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-12 15:54 Qing Zhao
2024-01-12 16:28 ` Richard Biener
2024-01-12 17:30 ` Qing Zhao
2024-01-15 8:13 ` Eric Botcazou
2024-01-15 16:42 ` Qing Zhao
2024-01-15 9:31 ` Richard Biener
2024-01-15 14:54 ` Qing Zhao
2024-01-15 15:06 ` Jakub Jelinek
2024-01-15 16:41 ` Qing Zhao
2024-01-16 20:25 ` Qing Zhao
2024-01-17 6:42 ` Richard Biener
2024-01-17 6:43 ` Richard Biener [this message]
2024-01-18 14:45 ` Qing Zhao
2024-01-19 9:30 ` Richard Biener
2024-01-19 16:25 ` Qing Zhao
2024-01-22 7:40 ` Richard Biener
2024-01-22 14:52 ` Qing Zhao
2024-01-22 16:54 ` Qing Zhao
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='CAFiYyc33T8mjucGV_JVD5vHOsjMZbPPjTJ=0BmPnuckq-ANYfQ@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=qing.zhao@oracle.com \
/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).