| Message ID | 5326C29C.3080808@oracle.com |
|---|---|
| State | New |
| Headers | show |
On 03/17/2014 05:38 AM, Paolo Carlini wrote: > noticed this issue, which looks simple to fix. The ICE happens in > cxx_eval_constant_expression, because it cannot handle a CAST_EXPR (or > any othe *_CAST, for that matter). In fact check_narrowing calls > maybe_constant_value, and, because we are in a template, the latter > faces the unfolded CAST_EXPR. Thus it seems easy to just use > fold_non_dependent_expr_sfinae. Tested x86_64-linux. OK. > PS: looking forward, I'm wondering if some semantics/typeck functions > shouldn't try harder before building a tree node and returning, eg, > instead of just checking processing_template_decl, actually checking if > type and expr are dependent? Does this kind of audit make sense for next > Stage 1? In general adding fold_non_dependent_expr where it's needed is the right answer, because normal operation creates tree patterns that tsubst doesn't understand how to deal with. I suppose it might work to always fully build non-instantiation-dependent expressions, wrap them in NON_DEPENDENT_EXPR, and then unshare its operand at instantiation time. But that would be a significant change with unclear benefit. Jason
Index: cp/typeck2.c =================================================================== --- cp/typeck2.c (revision 208605) +++ cp/typeck2.c (working copy) @@ -861,7 +861,7 @@ check_narrowing (tree type, tree init) return; } - init = maybe_constant_value (init); + init = maybe_constant_value (fold_non_dependent_expr_sfinae (init, tf_none)); if (TREE_CODE (type) == INTEGER_TYPE && TREE_CODE (ftype) == REAL_TYPE) Index: testsuite/g++.dg/cpp0x/constexpr-ice13.C =================================================================== --- testsuite/g++.dg/cpp0x/constexpr-ice13.C (revision 0) +++ testsuite/g++.dg/cpp0x/constexpr-ice13.C (working copy) @@ -0,0 +1,8 @@ +// PR c++/59571 +// { dg-do compile { target c++11 } } + +template <class> +struct foo +{ + static constexpr int bar{(int)-1}; +};