Hi,
On 11/17/2011 09:52 PM, Paolo Carlini wrote:
On 11/17/2011 09:37 PM, Jason Merrill wrote:
On 11/16/2011 10:00 AM, Paolo Carlini wrote:
this is an ICE on valid, 4.6/4.7 Regression, which manifests itself as
tree codes unhandled by cxx_eval_constant_expression.
Hmm, those codes shouldn't make it this far; we should go through
fold_non_dependent_expr before we get to cxx_eval_constant_expression.
Ok, I'll investigate what is happening instead.
So, these are my first observations. For sure we go through
fold_non_dependent_expr, and exactly in store_init_value, like this:
value = fold_non_dependent_expr (value);
value = maybe_constant_init (value);
thus it's called right before maybe_constant_init, which then leads
immediately to the cxx_eval_* calls. The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched. For example, for 'const int now1 = (double)(val);':
<fix_trunc_expr 0x7ffff5774e38
type <integer_type 0x7ffff56475e8 int public type_6 SI
size <integer_cst 0x7ffff564a2c0 constant 32>
unit size <integer_cst 0x7ffff564a2e0 constant 4>
align 32 symtab 0 alias set -1 canonical type 0x7ffff56475e8
precision 32 min <integer_cst 0x7ffff564a260 -2147483648> max
<integer_cst 0x7ffff564a280 2147483647>
pointer_to_this <pointer_type 0x7ffff56552a0>>
side-effects
arg 0 <cast_expr 0x7ffff5774dc0
type <real_type 0x7ffff5647f18 double type_6 DF
size <integer_cst 0x7ffff562ef40 constant 64>
unit size <integer_cst 0x7ffff562ef60 constant 8>
align 64 symtab 0 alias set -1 canonical type
0x7ffff5647f18 precision 64
pointer_to_this <pointer_type 0x7ffff5655150>>
side-effects
arg 0 <tree_list 0x7ffff5774d98 value <parm_decl 0x7ffff56375d8
val>>>>
after a few cxx_eval_* calls the CAST_EXPR gives problems in
cxx_eval_constant_expression.
Should fold_non_dependent_expr work harder on these FIX_TRUNC_EXPRs?
Thanks,
Paolo.
