https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99335
Bug ID: 99335
Summary: Comma Operator Evaluation Order - C++ 11 and newer
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aatsnps at gmail dot com
Target Milestone: ---
Filing a bug for tracking this issue:
Test Case:
#include <iostream>
struct CBI;
struct EC;
struct CET;
struct CBI {
CBI& operator,(const CBI& rhs)
{ return *const_cast<CBI*>(&rhs); }
};
struct EC : CBI {
explicit EC(CET* cet) : cet_(cet)
{}
CET* cet_;
};
struct CET {
CBI& operator,(const CBI& rhs) const
{ return *const_cast<CBI*>(&rhs); }
operator EC&() const
{ return *new EC(const_cast<CET*>(this)); }
};
static const CET&
hello() {
std::cout << "Hello " << std::endl;
return *new CET();
}
static const CET&
world() {
std::cout << "World " << std::endl;
return *new CET();
}
static void
test_comma_operator(CBI&) {
}
int main()
{
test_comma_operator ((
hello(),
world()
));
}
As per rule 16 from https://en.cppreference.com/w/cpp/language/eval_order , the
eval order of the above listed test case doesn't look right.
16) Every overloaded operator obeys the sequencing rules of the built-in
operator it overloads when called using operator notation.
CLANG appears to do it right, however, g++ appears to do it wrong.
us01odcvde08782> clang++ -g test.cpp
us01odcvde08782> ./a.out
Hello
World
us01odcvde08782> g++ -g test.cpp
us01odcvde08782> ./a.out
World
Hello
us01odcvde08782>
I was using CentOS6.8 with gcc 6.2. However, trying other versions of GCC
didn't make any difference.
My understanding, based on the rule 16 and the discussions below, is that it is
a GCC bug, so filing a bug.
More details/discussions below:
On Thu, Feb 4, 2021 at 1:33 PM David Brown <david.br...@hesbynett.no> wrote:
On 04/02/2021 22:21, Andreas Schwab wrote:
> On Feb 04 2021, David Brown wrote:
>
>> For the built-in comma operator, you get guaranteed order of evaluation
>> (or more precisely, guaranteed order of visible side-effects). But for
>> a user-defined comma operator, you do not - until C++17, which has
>> guaranteed evaluation ordering in some circumstances.
>
> But not the evaluation order of function arguments. See
> <https://en.cppreference.com/w/cpp/language/eval_order> Sequenced-before
> rules, rule 15.
Correct.
>
>> Try your test again with "-std=c++17" or "-std=g++17" - if the order is
>> still reversed, it's a gcc bug (AFAICS).
>
> I don't think so.
>
Unless I am missing something, in the OP's program it is a user-defined
comma operator that is called. There is only one argument to the
"test_comma_operator" function, the result of that user-defined comma
operator. So rule 15 above does not apply - rule 16 applies.
At least that is /my/ reading of the cppreference page and the OP's program.
David
