On Sun, Apr 29, 2018 at 3:23 AM, Paolo Carlini <paolo.carl...@oracle.com> wrote:
> Hi,
>
> On 28/04/2018 18:41, Jason Merrill wrote:
>>
>> On Fri, Apr 27, 2018 at 7:26 PM, Paolo Carlini <paolo.carl...@oracle.com>
>> wrote:
>>>
>>> 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;
>>> }
>>
>> Maybe we should move this code up, then.
>
> You are totally right. Yesterday I realized that and tested on x86_64-linux
> the below, both with and without Jakub's fix.
+ if (!TREE_SIDE_EFFECTS (e))
+ return nullptr_node;
So what happens if e has side-effects?
Jason
