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.
Jason
