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 <pola...@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
