Hi again,
I'm now pretty sure that we have a latent issue in ocp_convert. The bug
fixed by Jakub shows that we used to not have issues with
integer_zero_node. That's easy to explain: at the beginning of
ocp_convert there is code which handles first some special / simple
cases when same_type_ignoring_top_level_qualifiers_p is true. That code
isn't of course used for integer_zero_node as source expression, which
therefore is handled by:
if (NULLPTR_TYPE_P (type) && e && null_ptr_cst_p (e))
{
if (complain & tf_warning)
maybe_warn_zero_as_null_pointer_constant (e, loc);
return nullptr_node;
}
which does the right thing. On the other hand the code at the beginning
of ocp_covert *is* used for nullptr_node but it doesn't notice that the
conversion is really trivial and wraps type and expr in a NOP_EXPR.
Therefore, I think we should handle the special case there, like we
handle it at the beginning of decay_conversion (careful with side
effects, as we (I) learned the hard way with a bug!). Tested
x86_64-linux, of course I also separately checked that the below would
fix 85553 in a different way.
Thanks,
Paolo.
//////////////////
2018-04-28 Paolo Carlini <paolo.carl...@oracle.com>
* cvt.c (ocp_convert): Early handle the special case of
nullptr converted to nullptr.
Index: cvt.c
===================================================================
--- cvt.c (revision 259731)
+++ cvt.c (working copy)
@@ -736,6 +736,8 @@ ocp_convert (tree type, tree expr, int convtype, i
TREE_TYPE (e) = TREE_TYPE (TARGET_EXPR_SLOT (e)) = type;
return e;
}
+ else if (NULLPTR_TYPE_P (type) && !TREE_SIDE_EFFECTS (e))
+ return nullptr_node;
else
{
/* We shouldn't be treating objects of ADDRESSABLE type as
