Hi,
On 13/04/2018 19:45, Jason Merrill wrote:
Ah, I see. The problem is that even though convert_to_integer_1 was
called with dofold false, we lose that when it calls convert(). Why
not recurse directly to convert_to_integer_1 with the underlying type?
That would avoid the undesired folding.
Interesting. I had no idea that this seemingly simple error-recovery
issue was ultimately due to a substantive if latent issue in convert.c.
Anyway, in the meanwhile I tried a few variants of direct recursion
without much success, my boostraps all failed pretty quickly and pretty
badly. However the below - which isn't far from the spirit of your
analysis, I think - is holding up well, at least bootstrap + C++
testsuite are definitely OK. Should I continue testing it over the weekend?
Thanks!
Paolo.
///////////////////
Index: convert.c
===================================================================
--- convert.c (revision 259376)
+++ convert.c (working copy)
@@ -741,8 +741,12 @@ convert_to_integer_1 (tree type, tree expr, bool d
else if (TREE_CODE (type) == ENUMERAL_TYPE
|| maybe_ne (outprec, GET_MODE_PRECISION (TYPE_MODE (type))))
{
- expr = convert (lang_hooks.types.type_for_mode
- (TYPE_MODE (type), TYPE_UNSIGNED (type)), expr);
+ tree utype = (lang_hooks.types.type_for_mode
+ (TYPE_MODE (type), TYPE_UNSIGNED (type)));
+ if (dofold)
+ expr = convert (utype, expr);
+ else
+ expr = build1 (CONVERT_EXPR, utype, expr);
return maybe_fold_build1_loc (dofold, loc, NOP_EXPR, type, expr);
}
Index: testsuite/g++.dg/cpp0x/pr85112.C
===================================================================
--- testsuite/g++.dg/cpp0x/pr85112.C (nonexistent)
+++ testsuite/g++.dg/cpp0x/pr85112.C (working copy)
@@ -0,0 +1,17 @@
+// PR c++/85112
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ int m;
+ int n : 4;
+};
+
+int i; // { dg-message "not const" }
+
+void foo()
+{
+ constexpr int j = i; // { dg-error "not usable" }
+ A a;
+ a.n = j;
+}
