http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56481
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-02-28
CC| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-28
11:59:57 UTC ---
Reduced testcase:
struct S
{
bool foo () const;
#define A(n) , f##n##0, f##n##1, f##n##2, f##n##3
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3)
#define C B(0) B(1) B(2) B(3)
bool f C;
};
bool
S::foo () const
{
#undef A
#define A(n) && f##n##0 && f##n##1 && f##n##2 && f##n##3
const bool ret = f C;
return ret;
}
Started with my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192862
It actually isn't endless, just the compile time complexity is bad.
The problem is I think in:
if (!potential_constant_expression_1 (op, rval, flags))
return false;
if (!processing_template_decl)
op = maybe_constant_value (op);
in TRUTH_{AND,OR}*_EXPR handling in potential_constant_expression_1, because
maybe_constant_value calls potential_constant_expression (op) again.
They are called with different second/third argument (false, tf_none inside
maybe_constant_value, or true (== rval), flags above) though, so I think the
fix wouldn't be as easy as inlining maybe_constant_value by hand here and
avoiding the potential_constant_expression there.
Jason, any ideas?
For large && or || expressions perhaps we could just handle the cases where
op is the same code specially, still we wouldn't get rid of the large
complexity if say TRUTH_AND*_EXPR is only in every second code and there is
some other code in between.
