From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] tree-optimization/109170 - bogus use-after-free with __builtin_expect
Date: Tue, 21 Mar 2023 08:21:18 +0000 (UTC) [thread overview]
Message-ID: <nycvar.YFH.7.77.849.2303210820500.18795@jbgna.fhfr.qr> (raw)
In-Reply-To: <ZBhd/rwNkNxMjSCR@tucnak>
On Mon, 20 Mar 2023, Jakub Jelinek wrote:
> On Mon, Mar 20, 2023 at 12:12:14PM +0000, Richard Biener wrote:
> > PR tree-optimization/109170
> > * gimple-range-op.cc (cfn_pass_through_arg1): New.
> > (gimple_range_op_handler::maybe_builtin_call): Handle
> > __builtin_expect and similar via cfn_pass_through_arg1
> > and inspecting the calls fnspec.
> > * builtins.cc (builtin_fnspec): Handle BUILT_IN_EXPECT
> > and BUILT_IN_EXPECT_WITH_PROBABILITY.
>
> I'm still worried about this builtins.cc change, can't we defer
> that part till GCC 14 where there will be enough time to see if it
> doesn't result in some undesirable problems (__builtin_expect* being
> optimized away when it still shouldn't etc.)?
Sure. I've retested and pushed the following.
Richard.
From 02face8ff38e5a7942cfcb8c7444e6cca35d7523 Mon Sep 17 00:00:00 2001
From: Richard Biener <rguenther@suse.de>
Date: Fri, 17 Mar 2023 13:14:49 +0100
Subject: [PATCH] tree-optimization/109170 - bogus use-after-free with
__builtin_expect
To: gcc-patches@gcc.gnu.org
The following adds a missing range-op for __builtin_expect which
helps -Wuse-after-free to detect the case a realloc original
pointer is used when the result was NULL. The implementation
should handle all argument one pass-through builtins we handle
in the fnspec machinery, but that's defered to GCC 14.
The gcc.dg/tree-ssa/ssa-lim-21.c testcase needs adjustment because
for (int j = 0; j < m; j++)
if (__builtin_expect (m, 0))
for (int i = 0; i < m; i++)
is now correctly optimized to a unconditional jump by EVRP - m
cannot be zero when the outer loop is entered. I've adjusted
the outer loop to iterate 'n' times which makes us apply store-motion
to 'count' and 'q->data1' but only out of the inner loop and
as expected not apply store motion to 'q->data' at all.
The gcc.dg/predict-20.c testcase relies on broken behavior of
profile estimation when trying to handle __builtin_expect values
flowing into PHI nodes. I have opened PR109210 and removed
the expected matching from the testcase.
PR tree-optimization/109170
* gimple-range-op.cc (cfn_pass_through_arg1): New.
(gimple_range_op_handler::maybe_builtin_call): Handle
__builtin_expect via cfn_pass_through_arg1.
* gcc.dg/Wuse-after-free-pr109170.c: New testcase.
* gcc.dg/tree-ssa/ssa-lim-21.c: Adjust.
* gcc.dg/predict-20.c: Likewise.
---
gcc/gimple-range-op.cc | 27 +++++++++++++++++++
.../gcc.dg/Wuse-after-free-pr109170.c | 15 +++++++++++
gcc/testsuite/gcc.dg/predict-20.c | 3 ++-
gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-21.c | 7 ++---
4 files changed, 48 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/Wuse-after-free-pr109170.c
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index a5d625387e7..c7c546caf43 100644
--- a/gcc/gimple-range-op.cc
+++ b/gcc/gimple-range-op.cc
@@ -309,6 +309,26 @@ public:
}
} op_cfn_constant_p;
+// Implement range operator for integral/pointer functions returning
+// the first argument.
+class cfn_pass_through_arg1 : public range_operator
+{
+public:
+ using range_operator::fold_range;
+ virtual bool fold_range (irange &r, tree, const irange &lh,
+ const irange &, relation_trio) const
+ {
+ r = lh;
+ return true;
+ }
+ virtual bool op1_range (irange &r, tree, const irange &lhs,
+ const irange &, relation_trio) const
+ {
+ r = lhs;
+ return true;
+ }
+} op_cfn_pass_through_arg1;
+
// Implement range operator for CFN_BUILT_IN_SIGNBIT.
class cfn_signbit : public range_operator_float
{
@@ -966,6 +986,13 @@ gimple_range_op_handler::maybe_builtin_call ()
m_int = &op_cfn_parity;
break;
+ case CFN_BUILT_IN_EXPECT:
+ case CFN_BUILT_IN_EXPECT_WITH_PROBABILITY:
+ m_valid = true;
+ m_op1 = gimple_call_arg (call, 0);
+ m_int = &op_cfn_pass_through_arg1;
+ break;
+
default:
break;
}
diff --git a/gcc/testsuite/gcc.dg/Wuse-after-free-pr109170.c b/gcc/testsuite/gcc.dg/Wuse-after-free-pr109170.c
new file mode 100644
index 00000000000..14f1350aa29
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wuse-after-free-pr109170.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wuse-after-free=2" } */
+
+unsigned long bufmax = 0;
+unsigned long __open_catalog_bufmax;
+void *realloc(void *, __SIZE_TYPE__);
+void free(void *);
+
+void __open_catalog(char *buf)
+{
+ char *old_buf = buf;
+ buf = realloc (buf, bufmax);
+ if (__builtin_expect ((buf == ((void *)0)), 0))
+ free (old_buf); /* { dg-bogus "used after" } */
+}
diff --git a/gcc/testsuite/gcc.dg/predict-20.c b/gcc/testsuite/gcc.dg/predict-20.c
index 31d01835b80..7bb0d411f88 100644
--- a/gcc/testsuite/gcc.dg/predict-20.c
+++ b/gcc/testsuite/gcc.dg/predict-20.c
@@ -16,8 +16,9 @@ c ()
break;
}
int d = b < 0;
+ /* We fail to apply __builtin_expect heuristics here. Se PR109210. */
if (__builtin_expect (d, 0))
asm("");
}
-/* { dg-final { scan-tree-dump-times "__builtin_expect heuristics of edge" 3 "profile_estimate"} } */
+/* { dg-final { scan-tree-dump-times "__builtin_expect heuristics of edge" 2 "profile_estimate" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-21.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-21.c
index ffe6f8f699d..fe29e841f28 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-21.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-21.c
@@ -17,7 +17,7 @@ void
func (int m, int n, int k, struct obj *a)
{
struct obj *q = a;
- for (int j = 0; j < m; j++)
+ for (int j = 0; j < n; j++)
if (__builtin_expect (m, 0))
for (int i = 0; i < m; i++)
{
@@ -31,5 +31,6 @@ func (int m, int n, int k, struct obj *a)
}
}
-/* { dg-final { scan-tree-dump-not "Executing store motion of" "lim2" } } */
-
+/* { dg-final { scan-tree-dump "Executing store motion of count from loop 2" "lim2" } } */
+/* { dg-final { scan-tree-dump "Executing store motion of \[^ \]*data1 from loop 2" "lim2" } } */
+/* { dg-final { scan-tree-dump-times "Executing store motion of" 2 "lim2" } } */
--
2.35.3
next prev parent reply other threads:[~2023-03-21 8:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 12:18 Richard Biener
2023-03-17 12:43 ` Jakub Jelinek
2023-03-17 12:53 ` Richard Biener
2023-03-17 12:59 ` Jakub Jelinek
2023-03-17 13:55 ` Richard Biener
2023-03-17 14:03 ` Jakub Jelinek
2023-03-17 14:18 ` Richard Biener
2023-03-17 14:52 ` Jakub Jelinek
2023-03-20 8:21 ` Richard Biener
2023-03-20 12:12 ` Richard Biener
2023-03-20 13:22 ` Jakub Jelinek
2023-03-21 8:21 ` Richard Biener [this message]
2023-03-21 8:23 ` Jakub Jelinek
2023-03-17 13:59 ` Andrew MacLeod
2023-04-27 12:10 Richard Biener
[not found] <34641.123042708104200740@us-mta-611.us.mimecast.lan>
2023-04-27 12:11 ` Jakub Jelinek
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.2303210820500.18795@jbgna.fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.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).