On 6/9/19 8:45 PM, Marek Polacek wrote:
The problem here is that we're getting "requested alignment is not an integer constant" since r261971, because of this part of the patch:@ -4676,7 +4685,11 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t, conversion. */ return fold (t); - if (tcode == UNARY_PLUS_EXPR) + /* Handle an array's bounds having been deduced after we built + the wrapping expression. */ + if (same_type_ignoring_tlq_and_bounds_p (type, TREE_TYPE (op))) + r = op; + else if (tcode == UNARY_PLUS_EXPR) r = fold_convert (TREE_TYPE (t), op); else r = fold_build1 (tcode, type, op); where type was "int" and TREE_TYPE (op) was "const int", so we just used OP which was an INTEGER_CST of type "const int". That resulted in a NOP_EXPR causing the error above. Previously, we'd fold_build, returning an INTEGER_CST with type "int". It seems weird to me to have an INTEGER_CST with a cv-qual type, so the following patch handles that case in adjust_temp_type. Bootstrapped/regtested on x86_64-linux, ok for trunk and 9?
OK. Jason
