Re: C++ PATCH for c++/90473 - wrong code with nullptr in default argument

[Jason Merrill <jason@redhat.com>]

On 8/8/19 8:56 PM, Marek Polacek wrote:
> This is a wrong-code bug where we are throwing away the function call in
> the default argument here:
> 
>    void fn1 (void* p = (f(), nullptr)) { }
> 
> and thus dropping the possible side-effects of that call to the floor.
> 
> That happens because check_default_argument returns nullptr_node when it
> sees a null_ptr_cst_p argument.  In this case the argument is a COMPOUND_EXPR
> "f(), nullptr" and null_ptr_cst_p returns true for it.  And so the effects of
> the LHS expression of the compound expr are forgotten.  Fixed as below.
> 
> It's tempting to change null_ptr_cst_p to return false when it sees something
> that has TREE_SIDE_EFFECTS, but that would be wrong I think: [conv.ptr] says
> that a null pointer constant is an integer literal with value zero or a prvalue
> of type std::nullptr_t.  An expression "a, b", the built-in comma expression,
> is a prvalue if 'b' is an rvalue.  And so "f(), nullptr" is a prvalue of type
> std::nullptr_t.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-08-08  Marek Polacek  <polacek@redhat.com>
> 
> 	PR c++/90473 - wrong code with nullptr in default argument.
> 	* call.c (null_ptr_cst_p): Update quote from the standard.
> 	* decl.c (check_default_argument): Don't return nullptr when the arg
> 	has side-effects.

OK.

Jason