public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/100828] New: Arbitrary limit on constraint complexity
@ 2021-05-30 0:15 matthewjbarichello at gmail dot com
2021-07-19 18:56 ` [Bug c++/100828] " ppalka at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: matthewjbarichello at gmail dot com @ 2021-05-30 0:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828
Bug ID: 100828
Summary: Arbitrary limit on constraint complexity
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthewjbarichello at gmail dot com
Target Milestone: ---
Created attachment 50889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50889&action=edit
Patch to remove the constraint complexity limit from gcc-11.1.0
It would seem that there is an arbitrary limit on the complexity of constraints
in gcc 11.
#define a (0 || 0 && 0)
namespace e {
template<typename>
struct f;
}
template<typename g>
concept f = e::f<g>::h && true && a;
template<typename>
concept i = a && a;
template <typename, typename j>
requires(i<j> || f<j>)
struct k;
template<typename g, typename j>
requires(i<j> && i<g>)
struct k<g, j>;
This example, reduced with c-reduce, yields:
<source>:19:8: error: ‘0 \/ 0 /\ 0 /\ 0 \/ 0 /\ 0 \/ e::f<
<template-parameter-1-1> >::h [with g = j] /\ true /\ 0 \/ 0 /\ 0’ exceeds the
maximum constraint complexity
19 | struct k<g, j>;
| ^~~~~~~
Attached is a patch for gcc, as of the releases/gcc-11.1.0 tag, which allows
gcc to compile the example without an issue.
Clang does not seem to have this limitation and has no problem compiling the
example. Is there a reason for this limit?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/100828] Arbitrary limit on constraint complexity
2021-05-30 0:15 [Bug c++/100828] New: Arbitrary limit on constraint complexity matthewjbarichello at gmail dot com
@ 2021-07-19 18:56 ` ppalka at gcc dot gnu.org
2021-07-28 7:07 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-07-19 18:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
CC| |ppalka at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2021-07-19
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
Target Milestone|--- |11.2
--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed. This complexity limit is probably there because the subsumption
algorithm (namely the conversion to DNF/CNF) can use an exponential amount of
space, but I think we can improve this and avoid the exponential memory usage
in the first place. Then we could safely remove the complexity limit.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/100828] Arbitrary limit on constraint complexity
2021-05-30 0:15 [Bug c++/100828] New: Arbitrary limit on constraint complexity matthewjbarichello at gmail dot com
2021-07-19 18:56 ` [Bug c++/100828] " ppalka at gcc dot gnu.org
@ 2021-07-28 7:07 ` rguenth at gcc dot gnu.org
2021-08-02 14:05 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-07-28 7:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|11.2 |11.3
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/100828] Arbitrary limit on constraint complexity
2021-05-30 0:15 [Bug c++/100828] New: Arbitrary limit on constraint complexity matthewjbarichello at gmail dot com
2021-07-19 18:56 ` [Bug c++/100828] " ppalka at gcc dot gnu.org
2021-07-28 7:07 ` rguenth at gcc dot gnu.org
@ 2021-08-02 14:05 ` cvs-commit at gcc dot gnu.org
2021-08-11 15:55 ` cvs-commit at gcc dot gnu.org
2021-08-11 15:59 ` ppalka at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-02 14:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:f48c3cd2e3f9cd9e3c329eb2d3185bd26e7c7607
commit r12-2658-gf48c3cd2e3f9cd9e3c329eb2d3185bd26e7c7607
Author: Patrick Palka <ppalka@redhat.com>
Date: Mon Aug 2 09:59:56 2021 -0400
c++: Improve memory usage of subsumption [PR100828]
Constraint subsumption is implemented in two steps. The first step
computes the disjunctive (or conjunctive) normal form of one of the
constraints, and the second step verifies that each clause in the
decomposed form implies the other constraint. Performing these two
steps separately is problematic because in the first step the DNF/CNF
can be exponentially larger than the original constraint, and by
computing it ahead of time we'd have to keep all of it in memory.
This patch fixes this exponential blowup in memory usage by interleaving
the two steps, so that as soon as we decompose one clause we check
implication for it. In turn, memory usage during subsumption is now
worst case linear in the size of the constraints rather than
exponential, and so we can safely remove the hard limit of 16 clauses
without introducing runaway memory usage on some inputs. (Note the
_time_ complexity of subsumption is still exponential in the worst case.)
In order for this to work we need to make formula::branch() insert the
copy of the current clause directly after the current clause rather than
at the end of the list, so that we fully decompose a clause shortly
after creating it. Otherwise we'd end up accumulating exponentially
many (partially decomposed) clauses in memory anyway.
PR c++/100828
gcc/cp/ChangeLog:
* logic.cc (formula::formula): Use emplace_back instead of
push_back.
(formula::branch): Insert a copy of m_current directly after
m_current instead of at the end of the list.
(formula::erase): Define.
(decompose_formula): Remove.
(decompose_antecedents): Remove.
(decompose_consequents): Remove.
(derive_proofs): Remove.
(max_problem_size): Remove.
(diagnose_constraint_size): Remove.
(subsumes_constraints_nonnull): Rewrite directly in terms of
decompose_clause and derive_proof, interleaving decomposition
with implication checking. Remove limit on constraint complexity.
Use formula::erase to free the current clause before moving on to
the next one.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/100828] Arbitrary limit on constraint complexity
2021-05-30 0:15 [Bug c++/100828] New: Arbitrary limit on constraint complexity matthewjbarichello at gmail dot com
` (2 preceding siblings ...)
2021-08-02 14:05 ` cvs-commit at gcc dot gnu.org
@ 2021-08-11 15:55 ` cvs-commit at gcc dot gnu.org
2021-08-11 15:59 ` ppalka at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-11 15:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:90f3dd128bc709a76c52b5ae29b40903acb26f20
commit r11-8851-g90f3dd128bc709a76c52b5ae29b40903acb26f20
Author: Patrick Palka <ppalka@redhat.com>
Date: Mon Aug 2 09:59:56 2021 -0400
c++: Improve memory usage of subsumption [PR100828]
Constraint subsumption is implemented in two steps. The first step
computes the disjunctive (or conjunctive) normal form of one of the
constraints, and the second step verifies that each clause in the
decomposed form implies the other constraint. Performing these two
steps separately is problematic because in the first step the DNF/CNF
can be exponentially larger than the original constraint, and by
computing it ahead of time we'd have to keep all of it in memory.
This patch fixes this exponential blowup in memory usage by interleaving
the two steps, so that as soon as we decompose one clause we check
implication for it. In turn, memory usage during subsumption is now
worst case linear in the size of the constraints rather than
exponential, and so we can safely remove the hard limit of 16 clauses
without introducing runaway memory usage on some inputs. (Note the
_time_ complexity of subsumption is still exponential in the worst case.)
In order for this to work we need to make formula::branch() insert the
copy of the current clause directly after the current clause rather than
at the end of the list, so that we fully decompose a clause shortly
after creating it. Otherwise we'd end up accumulating exponentially
many (partially decomposed) clauses in memory anyway.
PR c++/100828
gcc/cp/ChangeLog:
* logic.cc (formula::formula): Use emplace_back instead of
push_back.
(formula::branch): Insert a copy of m_current directly after
m_current instead of at the end of the list.
(formula::erase): Define.
(decompose_formula): Remove.
(decompose_antecedents): Remove.
(decompose_consequents): Remove.
(derive_proofs): Remove.
(max_problem_size): Remove.
(diagnose_constraint_size): Remove.
(subsumes_constraints_nonnull): Rewrite directly in terms of
decompose_clause and derive_proof, interleaving decomposition
with implication checking. Remove limit on constraint complexity.
Use formula::erase to free the current clause before moving on to
the next one.
(cherry picked from commit f48c3cd2e3f9cd9e3c329eb2d3185bd26e7c7607)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/100828] Arbitrary limit on constraint complexity
2021-05-30 0:15 [Bug c++/100828] New: Arbitrary limit on constraint complexity matthewjbarichello at gmail dot com
` (3 preceding siblings ...)
2021-08-11 15:55 ` cvs-commit at gcc dot gnu.org
@ 2021-08-11 15:59 ` ppalka at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-08-11 15:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 11.3 and 12, thanks for the bug report!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-08-11 15:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-30 0:15 [Bug c++/100828] New: Arbitrary limit on constraint complexity matthewjbarichello at gmail dot com
2021-07-19 18:56 ` [Bug c++/100828] " ppalka at gcc dot gnu.org
2021-07-28 7:07 ` rguenth at gcc dot gnu.org
2021-08-02 14:05 ` cvs-commit at gcc dot gnu.org
2021-08-11 15:55 ` cvs-commit at gcc dot gnu.org
2021-08-11 15:59 ` ppalka at gcc dot gnu.org
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).