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.
