public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: gcc-patches@gcc.gnu.org, msebor@redhat.com
Subject: Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores
Date: Fri, 17 Feb 2023 08:53:00 +0100	[thread overview]
Message-ID: <CAFiYyc1-Zw3P=Fji+hf-RxW83O=JLZDzvSfMKDYhi=aQkC6Xgw@mail.gmail.com> (raw)
In-Reply-To: <ork00gsr8w.fsf@lxoliva.fsfla.org>

On Fri, Feb 17, 2023 at 8:09 AM Alexandre Oliva via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
> check_dangling_stores has some weirdnesses that causes its behavior to
> change when the target ABI requires C++ ctors to return this: while
> scanning stmts backwards in e.g. the AS ctor on a target that returns
> this in ctors, the scan first encounters a copy of this to the SSA
> name used to hold the return value.  m_ptr_query.get_ref resolves lhs
> (the return SSA name) to the rhs (the default SSA name for this), does
> not skip it because auto_var_p is false for SSA_NAMEs, and proceeds to
> add it to stores, which seems to prevent later attempts to add stores
> into *this from succeeding, which disables warnings that should have
> triggered.
>
> This is also the case when the backwards search finds unrelated stores
> to other fields of *this before it reaches stores that IMHO should be
> warned about.  The store found first disables checking of other
> stores, as if the store appearing later in the code would necessarily
> overwrite the store that should be warned about.  I've added an
> xfailed variant of the existing test (struct An) that triggers this
> problem, but I'm not sure how to go about fixing it.
>
> Meanwhile, this patch prevents assignments with SSA_NAMEs in the lhs
> from being regarded as stores, which is enough to remove the
> undesirable side effect on -Wdangling-pointer of ABI-mandated ctors'
> returning this.  Another variant of the existing test (struct Al) that
> demonstrates the problem regardless of this aspect of the ABI, and
> that gets the desired warning with the proposed patch, but not
> without.
>
> Curiously, this fix exposes yet another problem in
> Wdangling-pointer-5.c: it is the return stmt of the unrelated pointer
> p, not the store into possibly-overlapping *vpp2, that caused the
> warning to not be issued for the store in *vpp1.  I'm not sure whether
> we should or should not warn in that case, but this patch adjusts the
> test to reflect the behavior change.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

It seems the case should run into

      else if (TREE_CODE (lhs_ref.ref) == SSA_NAME)
        {
          gimple *def_stmt = SSA_NAME_DEF_STMT (lhs_ref.ref);
          if (!gimple_nop_p (def_stmt))
            /* Avoid looking at or before stores into unknown objects.  */
            return;

          tree var = SSA_NAME_VAR (lhs_ref.ref);
          if (TREE_CODE (var) == PARM_DECL && DECL_BY_REFERENCE (var))
            /* Avoid by-value arguments transformed into by-reference.  */
            continue;

and what your patch tried to avoid is running into

      if (stores.add (lhs_ref.ref))
        continue;

?  I wonder what the circumstances are that we want the latter to happen if
the former condition is true?

> for  gcc/ChangeLog
>
>         * gimple-ssa-warn-access.cc
>         (pass_waccess::check_dangling_stores): Skip non-stores.
>
> for  gcc/testsuite/ChangeLog
>
>         * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
>         two new variants, one fixed, one xfailed.
>         * c-c++-common/Wdangling-pointer-5.c
>         (nowarn_store_arg_store_arg): Add now-expected warnings.
> ---
>  gcc/gimple-ssa-warn-access.cc                    |    3 ++
>  gcc/testsuite/c-c++-common/Wdangling-pointer-5.c |    4 ++-
>  gcc/testsuite/g++.dg/warn/Wdangling-pointer.C    |   29 +++++++++++++++++++++-
>  3 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
> index 2eab1d59abd05..c0efb3fdb4e52 100644
> --- a/gcc/gimple-ssa-warn-access.cc
> +++ b/gcc/gimple-ssa-warn-access.cc
> @@ -4511,7 +4511,8 @@ pass_waccess::check_dangling_stores (basic_block bb,
>            use the escaped locals.  */
>         return;
>
> -      if (!is_gimple_assign (stmt) || gimple_clobber_p (stmt))
> +      if (!is_gimple_assign (stmt) || gimple_clobber_p (stmt)
> +         || !gimple_store_p (stmt))
>         continue;
>
>        access_ref lhs_ref;
> diff --git a/gcc/testsuite/c-c++-common/Wdangling-pointer-5.c b/gcc/testsuite/c-c++-common/Wdangling-pointer-5.c
> index 2a165cea76768..cb6da9e86394d 100644
> --- a/gcc/testsuite/c-c++-common/Wdangling-pointer-5.c
> +++ b/gcc/testsuite/c-c++-common/Wdangling-pointer-5.c
> @@ -75,9 +75,9 @@ void nowarn_store_arg_store (void **vpp)
>
>  void* nowarn_store_arg_store_arg (void **vpp1, void **vpp2)
>  {
> -  int x;
> +  int x;              // { dg-message "'x' declared here" }
>    void **p = (void**)sink (0);
> -  *vpp1 = &x;         // warn here?
> +  *vpp1 = &x;         // { dg-warning "storing the address of local variable 'x' in '\\*vpp1'" }
>    *vpp2 = 0;          // might overwrite *vpp1
>    return p;
>  }
> diff --git a/gcc/testsuite/g++.dg/warn/Wdangling-pointer.C b/gcc/testsuite/g++.dg/warn/Wdangling-pointer.C
> index 22c559e4adafe..a94477a647666 100644
> --- a/gcc/testsuite/g++.dg/warn/Wdangling-pointer.C
> +++ b/gcc/testsuite/g++.dg/warn/Wdangling-pointer.C
> @@ -35,7 +35,34 @@ void warn_init_ref_member ()
>      { }
>    } ai;
>
> -  sink (&as, &ai);
> +  struct Al
> +  {
> +    const S &sref;
> +    Al ():
> +      // The temporary S object is destroyed when Al::Al() returns.
> +      sref (S ())  // { dg-warning "storing the address" }
> +    {
> +      // Copying this to an SSA_NAME used to disable the warning:
> +      Al *ptr = this;
> +      asm ("" : "+r" (ptr));
> +    }
> +  } al;
> +
> +  struct An
> +  {
> +    An *next;
> +    const S &sref;
> +    An ():
> +      next (0),
> +      // The temporary S object is destroyed when An::An() returns.
> +      sref (S ())  // { dg-warning "storing the address" "" { xfail *-*-* } }
> +    {
> +      // ??? Writing to another part of *this disables the warning:
> +      next = 0;
> +    }
> +  } an;
> +
> +  sink (&as, &ai, &al, &an);
>  }
>
>
>
> --
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>

  reply	other threads:[~2023-02-17  7:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17  7:09 Alexandre Oliva
2023-02-17  7:53 ` Richard Biener [this message]
2023-02-17  8:35   ` Alexandre Oliva
2023-02-17  9:09     ` Alexandre Oliva
2023-03-03  8:30   ` Alexandre Oliva
2023-03-03 11:12     ` Richard Biener
2023-03-08 13:04       ` Martin Liška
2023-03-08 13:08         ` Richard Biener
2023-03-09  8:23           ` Alexandre Oliva

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='CAFiYyc1-Zw3P=Fji+hf-RxW83O=JLZDzvSfMKDYhi=aQkC6Xgw@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@redhat.com \
    --cc=oliva@adacore.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).