@@ -1,8 +1,6 @@
/* { dg-additional-options "-fanalyzer-checker=pattern-test -O2" } */
// TODO: run this at every optimization level
-#include <stdlib.h>
-
extern void foo(void *);
extern void bar(void *);
@@ -18,12 +16,38 @@ void test1(void *ptr)
void test_2 (void *p, void *q)
{
- if (p == NULL || q == NULL) /* { dg-line cond_2 } */
+ _Bool tmp1 = p == 0;
+ _Bool tmp2 = q == 0;
+ _Bool tmp = tmp1 | tmp2;
+
+ /* Verify that we can detect the implied conditions on p and q here. */
+ if (tmp) /* { dg-line cond_2 } */
return;
foo(p);
+ /* { dg-warning "pattern match on 'tmp1 == 0'" "tmp1 == 0" { target *-*-* } cond_2 } */
+ /* { dg-warning "pattern match on 'tmp2 == 0'" "tmp2 == 0" { target *-*-* } cond_2 } */
/* { dg-warning "pattern match on '<unknown> == 0'" "<unknown> == 0" { target *-*-* } cond_2 } */
/* { dg-warning "pattern match on '<unknown> != 0'" "<unknown> != 0" { target *-*-* } cond_2 } */
/* { dg-warning "pattern match on 'p != 0'" "p != 0" { target *-*-* } cond_2 } */
/* { dg-warning "pattern match on 'q != 0'" "q != 0" { target *-*-* } cond_2 } */
}
+
+void test_3 (void *p, void *q)
+{
+ _Bool tmp1 = p == 0;
+ _Bool tmp2 = q == 0;
+ _Bool tmp = tmp1 & tmp2;
+
+ /* Verify that we can detect the implied conditions on p and q here. */
+ if (tmp) /* { dg-line cond_3 } */
+ return;
+ foo(p);
+
+ /* { dg-warning "pattern match on 'tmp1 != 0'" "tmp1 != 0" { target *-*-* } cond_3 } */
+ /* { dg-warning "pattern match on 'tmp2 != 0'" "tmp2 != 0" { target *-*-* } cond_3 } */
+ /* { dg-warning "pattern match on '<unknown> == 0'" "<unknown> == 0" { target *-*-* } cond_3 } */
+ /* { dg-warning "pattern match on '<unknown> != 0'" "<unknown> != 0" { target *-*-* } cond_3 } */
+ /* { dg-warning "pattern match on 'p == 0'" "p == 0" { target *-*-* } cond_3 } */
+ /* { dg-warning "pattern match on 'q == 0'" "q == 0" { target *-*-* } cond_3 } */
+}
Amongst the inputs to the analyzer state machines that can lead to state transitions are conditions on CFG edges, such as a test for a pointer being non-NULL. These conditionals can be non-trivial to determine in the face of optimization. For example, at -O2: if (p == NULL || q == NULL) is optimized on some targets (e.g. x86_64) to a bitwise-or: _1 = p_5(D) == 0B; _2 = q_6(D) == 0B; _3 = _1 | _2; if (_3 != 0) goto <bb 4>; [51.12%] else goto <bb 3>; [48.88%] but on other targets (e.g. powerpc64le) as control flow: if (p_2(D) == 0B) goto <bb 5>; [18.09%] else goto <bb 3>; [81.91%] <bb 3> [local count: 879501929]: if (q_3(D) == 0B) goto <bb 5>; [30.95%] else goto <bb 4>; [69.05%] region_model::add_any_constraints_from_ssa_def_stmt attempts to walk SSA def chains to reconstruct the conditions that hold, so that e.g. in the above case of bitwise-or, the state machine for "p" can transition to the "known-null" state along the edge leading to bb 3. In gcc.dg/analyzer/pattern-test-2.c I attempted to write test coverage for this, but the test fails on those targets for which the || is expressed via control flow. Is there a way to force the use of this optimization at -O2, or is it always going to be target dependent? This patch rewrites the test to make explicit use of bitwise-or, and adds coverage for bitwise-and for good measure. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. OK for master? gcc/testsuite/ChangeLog: PR analyzer/93291 * gcc.dg/analyzer/pattern-test-2.c: Remove include of stdlib.h. (test_2): Rewrite to explicitly perform a bitwise-or of two boolean conditions. (test_3): New function, to test bitwise-and. --- .../gcc.dg/analyzer/pattern-test-2.c | 30 +++++++++++++++++-- 1 file changed, 27 insertions(+), 3 deletions(-)