[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed by the above commit
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f89e844f9c589d1717248597641d25d81a4acb41 commit r10-6262-gf89e844f9c589d1717248597641d25d81a4acb41 Author: David Malcolm Date: Fri Jan 17 11:03:15 2020 -0500 analyzer: fix pattern-test-2.c (PR 93291) 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 ; [51.12%] else goto ; [48.88%] but on other targets (e.g. powerpc64le) as control flow: if (p_2(D) == 0B) goto ; [18.09%] else goto ; [81.91%] [local count: 879501929]: if (q_3(D) == 0B) goto ; [30.95%] else goto ; [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. This patch rewrites the test to make explicit use of bitwise-or, and adds coverage for bitwise-and for good measure. 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.
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:da7cf663b75513e4d2baf5a579ffcb4f8a61193b commit r10-6152-gda7cf663b75513e4d2baf5a579ffcb4f8a61193b Author: David Malcolm Date: Wed Jan 22 02:45:48 2020 +0100 analyzer: testsuite fixes for alloca, getpass, and setjmp (PR 93316) PR analyzer/93316 reports various testsuite failures where I accidentally relied on properties of x86_64-pc-linux-gnu. The following patch fixes them on sparc-sun-solaris2.11 (gcc211 in the GCC compile farm), and, I hope, the other configurations showing failures. There may still be other failures for pattern-test-2.c, which I'm tracking separately as PR analyzer/93291. gcc/analyzer/ChangeLog: PR analyzer/93316 * analyzer.cc (is_setjmp_call_p): Check for "setjmp" as well as "_setjmp". gcc/testsuite/ChangeLog: PR analyzer/93316 * gcc.dg/analyzer/data-model-1.c: Include . * gcc.dg/analyzer/malloc-1.c: Likewise. * gcc.dg/analyzer/malloc-callbacks.c (get_alloca): Return __builtin_alloca rather than alloca. * gcc.dg/analyzer/malloc-paths-8.c: Include . * gcc.dg/analyzer/sensitive-1.c: Define __EXTENSIONS__ before including unistd.h. * gcc.dg/analyzer/setjmp-2.c: Replace include of with "test-setjmp.h" and usage of setjmp with new SETJMP macro. * gcc.dg/analyzer/setjmp-3.c: Likewise. * gcc.dg/analyzer/setjmp-4.c: Likewise. * gcc.dg/analyzer/setjmp-5.c: Likewise. * gcc.dg/analyzer/setjmp-6.c: Likewise. * gcc.dg/analyzer/setjmp-7.c: Likewise. * gcc.dg/analyzer/setjmp-7a.c: Likewise. * gcc.dg/analyzer/setjmp-8.c: Likewise. * gcc.dg/analyzer/setjmp-9.c: Likewise. * gcc.dg/analyzer/test-setjmp.h: New header.
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 --- Comment #5 from David Malcolm --- (In reply to seurer from comment #4) > Not sure if the patch was done but the failure changed a bit over the > weekend. > > New failures (update from 3684bbb022cd75da55e1457673f269980aa12cdf to > f4d83eba60b5b1292a7cae660f03a2377e92a845): > FAIL: gcc.dg/analyzer/pattern-test-2.c == 0 (test for warnings, > line 21) > FAIL: gcc.dg/analyzer/pattern-test-2.c != 0 (test for warnings, > line 21) > > New passes: > FAIL: gcc.dg/analyzer/pattern-test-2.c (test for warnings, line 21) > FAIL: gcc.dg/analyzer/pattern-test-2.c (test for warnings, line 21) I haven't applied the patch from comment #3 yet; I think what you're seeing is the effect of 8863f61c9c9dcec6003c4d61665b226569c0c3b2, which added unique names to the four dg-warning tests at line 21.
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #4 from seurer at gcc dot gnu.org --- Not sure if the patch was done but the failure changed a bit over the weekend. New failures (update from 3684bbb022cd75da55e1457673f269980aa12cdf to f4d83eba60b5b1292a7cae660f03a2377e92a845): FAIL: gcc.dg/analyzer/pattern-test-2.c == 0 (test for warnings, line 21) FAIL: gcc.dg/analyzer/pattern-test-2.c != 0 (test for warnings, line 21) New passes: FAIL: gcc.dg/analyzer/pattern-test-2.c (test for warnings, line 21) FAIL: gcc.dg/analyzer/pattern-test-2.c (test for warnings, line 21)
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-17 Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- Thanks. Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01069.html
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 --- Comment #2 from Andrew Pinski --- (In reply to David Malcolm from comment #1) > I'm not sure where the difference between the targets originates; is there a > way to force the usage of bitwise-or here? Try to write it this way: bool tmp1 = p == 0B; bool tmp2 = q == 0B bool tmp = tmp1 | tmp2; if (tmp)
[Bug analyzer/93291] 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291 --- Comment #1 from David Malcolm --- Thanks. The test is rather over-specified, it seems. x86_64 gimple for test_2 is: _1 = p_5(D) == 0B; _2 = q_6(D) == 0B; _3 = _1 | _2; if (_3 != 0) goto ; [51.12%] else goto ; [48.88%] powerpc64le gimple for test_2 has: if (p_2(D) == 0B) goto ; [18.09%] else goto ; [81.91%] [local count: 879501929]: if (q_3(D) == 0B) goto ; [30.95%] else goto ; [69.05%] So on x86_64, it's done both comparisons against NULL first, and optimized the || into: _3 = _1 | _2; whereas on powerpc64le it uses control flow to do this. The purpose of this test is to verify that the pattern-matching detects the underlying conditionals in the presence of that "_3 = _1 | _2;" optimization, so maybe a gimple FE test might be appropriate here. I'm not sure where the difference between the targets originates; is there a way to force the usage of bitwise-or here?
