This is the mail archive of the 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++] PR19531 NRV is performed on volatile temporary

Mark Mitchell wrote:
Christian BRUEL wrote:

it is the other way: with the nrv8.C (attached in the patch) test, only
the check on the RESULT_DECL is necessary, testing the volatility of the
*volatile A l;* object.

Oh!  Right, top-level qualifiers on return types are discarded from the
point of view of the language.

But, sadly, I'm still confused. Your example is:

A bar()
  volatile A l;
  return l;

Why is RESULT_DECL volatile in this case, before we call finalize_nrv?
Is this is just an accident because we have only one return statement?
For example:

A bar(bool b) {
  A a;
  volatile A va;
  if (b)
    return a;
  return va;

Is the RESULT_DECL still volatile?

In this example there are 2 retvals with 2 TREE_TYPEs, so one TREE_TYPE's is volatile and the other is not. But here NRV is avoided because there are 2 different return values, regardless of one that is volatile.

It seems like it would be simpler to fix this problem by changing
check_return_expr to set named_return_value_okay_p to false if the
TREE_TYPE (retval) is volatile.  What do you think about that?

yes you are right, it's would be a better place to do the check. but...

In fact the code is already there :

     /* The cv-unqualified type of the returned value must be the
        same as the cv-unqualified return type of the
        function.  */
     && same_type_p ((TYPE_MAIN_VARIANT (TREE_TYPE (retval))),
                      (TREE_TYPE (TREE_TYPE(current_function_decl))))));

Indeed, I reread the parts on volatile and object copying, the standard states nrv is allowed if the cv-unqualified types match, so strictly speaking
the object
volatile A a;
and the function
A bar()
have the same cv-unqualified type...

so this volatile optimization is surprisingly correct !

Nevertheless, it would have been useful to have a way to force a call to the copy constructor... but the standard allows this optimisation here, that's it.

Unless there is a consensus that this optimisation could be avoided on volatile objects for convenience, this is not a bug and I will update PR19531 accordingly.

Best Regards


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