This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]