Re: [C++ Patch] PR 51150

[Paolo Carlini <paolo dot carlini at oracle dot com>]

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.