Re: [PATCH 01/10] C++ FE: expression ranges v4

[David Malcolm <dmalcolm@redhat.com>]

On Fri, 2015-12-04 at 12:10 -0500, Jason Merrill wrote:
> On 12/03/2015 09:55 AM, David Malcolm wrote:
> > @@ -362,10 +362,11 @@ convert_to_real_1 (tree type, tree expr, bool fold_p)
> >       case REAL_TYPE:
> >         /* Ignore the conversion if we don't need to store intermediate
> >   	 results and neither type is a decimal float.  */
> > -      return build1 ((flag_float_store
> > -		     || DECIMAL_FLOAT_TYPE_P (type)
> > -		     || DECIMAL_FLOAT_TYPE_P (itype))
> > -		     ? CONVERT_EXPR : NOP_EXPR, type, expr);
> > +      return build1_loc (loc,
> > +			 (flag_float_store
> > +			  || DECIMAL_FLOAT_TYPE_P (type)
> > +			  || DECIMAL_FLOAT_TYPE_P (itype))
> > +			 ? CONVERT_EXPR : NOP_EXPR, type, expr);
> ....
> > @@ -5438,7 +5438,7 @@ build_nop (tree type, tree expr)
> >  {
> >    if (type == error_mark_node || error_operand_p (expr))
> >      return expr;
> > -  return build1 (NOP_EXPR, type, expr);
> > +  return build1_loc (EXPR_LOCATION (expr), NOP_EXPR, type, expr);
> 
> Hmm, I'm uneasy about assigning a location to a conversion or other 
> expression that doesn't correspond to particular text; it could be 
> associated with the location of the operand or the enclosing expression 
> that prompted the conversion.  I think we've been deliberately leaving 
> the location unset.  But that causes problems with code that only looks 
> at the top-level EXPR_LOCATION.  Arguably such code should be fixed to 
> look at the pre-conversion expression tree for a location, but I guess 
> this is reasonable.

> Past GCC 6 I think we definitely want to use a new tree code rather than 
> cp_expr; as Jakub pointed out, cp_expr doesn't do anything for templates 
> or language-independent code.
> 
> The current patchset is OK for GCC 6.

Thanks.  I've committed it to trunk as r231293.