From: Richard Biener <rguenther@suse.de>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] tree-sra: Fix union handling in build_reconstructed_reference (PR 105860)
Date: Mon, 4 Jul 2022 06:15:01 +0000 (UTC) [thread overview]
Message-ID: <nycvar.YFH.7.77.849.2207040610410.14950@jbgna.fhfr.qr> (raw)
In-Reply-To: <ri6h740a7ap.fsf@suse.cz>
On Fri, 1 Jul 2022, Martin Jambor wrote:
> Hi,
>
> As the testcase in PR 105860 shows, the code that tries to re-use the
> handled_component chains in SRA can be horribly confused by unions,
> where it thinks it has found a compatible structure under which it can
> chain the references, but in fact it found the type it was looking
> for elsewhere in a union and generated a write to a completely wrong
> part of an aggregate.
>
> I don't remember whether the plan was to support unions at all in
> build_reconstructed_reference but it can work, to an extent, if we
> make sure that we start the search only outside the outermost union,
> which is what the patch does (and the extra testcase verifies).
>
> Bootstrapped and tested on x86_64-linux. OK for trunk and then for
> release branches?
OK, but I'm wondering if the same problem can arise when the
handled_component_p includes VIEW_CONVERTs or BIT_FIELD_REFs
both of which may pun to a type already seen in a more inner
referece. Thus, is the actual problem that build_reconstructed_reference
searches for the outermost match of the type rather than the
innermost match? So should it search inner-to-outer instead
(or for the last match in the current way of searching?)
Thanks,
Richard.
> Thanks,
>
> Martin
>
>
> gcc/ChangeLog:
>
> 2022-07-01 Martin Jambor <mjambor@suse.cz>
>
> PR tree-optimization/105860
> * tree-sra.cc (build_reconstructed_reference): Start expr
> traversal only just below the outermost union.
>
> gcc/testsuite/ChangeLog:
>
> 2022-07-01 Martin Jambor <mjambor@suse.cz>
>
> PR tree-optimization/105860
> * gcc.dg/tree-ssa/alias-access-path-13.c: New test.
> * gcc.dg/tree-ssa/pr105860.c: Likewise.
> ---
> .../gcc.dg/tree-ssa/alias-access-path-13.c | 31 +++++++++
> gcc/testsuite/gcc.dg/tree-ssa/pr105860.c | 63 +++++++++++++++++++
> gcc/tree-sra.cc | 13 +++-
> 3 files changed, 106 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c
> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr105860.c
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c b/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c
> new file mode 100644
> index 00000000000..e502a97bc75
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-fre1" } */
> +
> +struct inn
> +{
> + int val;
> +};
> +
> +union foo
> +{
> + struct inn inn;
> + long int baz;
> +} *fooptr;
> +
> +struct bar
> +{
> + union foo foo;
> + int val2;
> +} *barptr;
> +
> +int
> +test ()
> +{
> + union foo foo;
> + foo.inn.val = 0;
> + barptr->val2 = 123;
> + *fooptr = foo;
> + return barptr->val2;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "return 123" 1 "fre1"} } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr105860.c b/gcc/testsuite/gcc.dg/tree-ssa/pr105860.c
> new file mode 100644
> index 00000000000..77bcb4a6739
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr105860.c
> @@ -0,0 +1,63 @@
> +/* { dg-do run } */
> +/* { dg-options "-O1" } */
> +
> +struct S1 {
> + unsigned int _0;
> + unsigned int _1;
> +} ;
> +struct S2 {
> + struct S1 _s1;
> + unsigned long _x2;
> +} ;
> +
> +struct ufld_type1 {
> + unsigned int _u1t;
> + struct S2 _s2;
> +} ;
> +
> +struct ufld_type2 {
> + unsigned int _u2t;
> + struct S1 _s1;
> +} ;
> +struct parm_type {
> + union {
> + struct ufld_type1 var_1;
> + struct ufld_type2 var_2;
> + } U;
> +};
> +
> +struct parm_type bad_function( struct parm_type arg0 )
> +{
> + struct parm_type rv;
> + struct S2 var4;
> + switch( arg0.U.var_2._u2t ) {
> + case 4294967041:
> + var4._s1 = arg0.U.var_1._s2._s1;
> + rv.U.var_1._u1t = 4294967041;
> + rv.U.var_1._s2 = var4;
> + break;
> + case 4294967043:
> + rv.U.var_2._u2t = 4294967043;
> + rv.U.var_2._s1 = arg0.U.var_2._s1;
> + break;
> + default:
> + break;
> + }
> + return rv;
> +}
> +
> +int main() {
> + struct parm_type val;
> + struct parm_type out;
> + val.U.var_2._u2t = 4294967043;
> + val.U.var_2._s1._0 = 0x01010101;
> + val.U.var_2._s1._1 = 0x02020202;
> + out = bad_function(val);
> + if (val.U.var_2._u2t != 4294967043)
> + __builtin_abort ();
> + if (out.U.var_2._s1._0 != 0x01010101)
> + __builtin_abort ();
> + if (val.U.var_2._s1._1 != 0x02020202 )
> + __builtin_abort ();
> + return 0;
> +}
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index 081c51b58a4..099e8dbe873 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -1667,7 +1667,18 @@ build_ref_for_offset (location_t loc, tree base, poly_int64 offset,
> static tree
> build_reconstructed_reference (location_t, tree base, struct access *model)
> {
> - tree expr = model->expr, prev_expr = NULL;
> + tree expr = model->expr;
> + /* We have to make sure to start just below the outermost union. */
> + tree start_expr = expr;
> + while (handled_component_p (expr))
> + {
> + if (TREE_CODE (TREE_TYPE (TREE_OPERAND (expr, 0))) == UNION_TYPE)
> + start_expr = expr;
> + expr = TREE_OPERAND (expr, 0);
> + }
> +
> + expr = start_expr;
> + tree prev_expr = NULL_TREE;
> while (!types_compatible_p (TREE_TYPE (expr), TREE_TYPE (base)))
> {
> if (!handled_component_p (expr))
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Frankenstra
next prev parent reply other threads:[~2022-07-04 6:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 20:48 Martin Jambor
2022-07-04 6:15 ` Richard Biener [this message]
2022-07-04 14:48 ` Martin Jambor
2022-07-05 7:34 ` Richard Biener
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=nycvar.YFH.7.77.849.2207040610410.14950@jbgna.fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=mjambor@suse.cz \
/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).