diff options
author | David Malcolm <dmalcolm@redhat.com> | 2020-09-15 05:51:04 -0400 |
---|---|---|
committer | David Malcolm <dmalcolm@redhat.com> | 2020-09-15 17:46:13 -0400 |
commit | 50ddbd0282e06614b29f0d3f3be5fbe70085a8bd (patch) | |
tree | bf10d46f9bb5455675a79c99bc7d6c14e105fbf2 /libgomp | |
parent | 1b9bdd52037061d7a5bd77d177b060c93c528a5d (diff) | |
download | gcc-50ddbd0282e06614b29f0d3f3be5fbe70085a8bd.zip gcc-50ddbd0282e06614b29f0d3f3be5fbe70085a8bd.tar.gz gcc-50ddbd0282e06614b29f0d3f3be5fbe70085a8bd.tar.bz2 |
analyzer: fix ICE when merging constraints w/o transitivity [PR96650]
PR analyzer/96650 reports an assertion failure when merging the
intersection of two sets of constraints, due to the resulting
constraints being infeasible.
It turns out that the two input sets were each infeasible if
transitivity were considered, but -fanalyzer-transitivity was off.
However for this case, the merging code was "discovering" the
transitive infeasibility of the intersection of the constraints even
when -fanalyzer-transitivity is off, triggering an assertion failure.
I attempted various fixes for this, but each of them would have
introduced O(N^2) logic into the constraint-handling code into the
-fno-analyzer-transitivity case (with N == the number of constraints).
This patch fixes the ICE by tweaking the assertion, so that we
silently drop such constraints if -fanalyzer-transitivity is off.
gcc/analyzer/ChangeLog:
PR analyzer/96650
* constraint-manager.cc (merger_fact_visitor::on_fact): Replace
assertion that add_constraint succeeded with an assertion that
if it fails, -fanalyzer-transitivity is off.
gcc/testsuite/ChangeLog:
PR analyzer/96650
* gcc.dg/analyzer/pr96650-1-notrans.c: New test.
* gcc.dg/analyzer/pr96650-1-trans.c: New test.
* gcc.dg/analyzer/pr96650-2-notrans.c: New test.
* gcc.dg/analyzer/pr96650-2-trans.c: New test.
Diffstat (limited to 'libgomp')
0 files changed, 0 insertions, 0 deletions