Hi,
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.
Thanks,
Paolo.
///////////////////
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?
/cp
2014-03-17 Paolo Carlini <paolo.carl...@oracle.com>
PR c++/59571
* typeck2.c (check_narrowing): Use fold_non_dependent_expr_sfinae.
/testsuite
2014-03-17 Paolo Carlini <paolo.carl...@oracle.com>
PR c++/59571
* g++.dg/cpp0x/constexpr-ice13.C: New.
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};
+};
