Undoc'd Feature?

[jte]

(07-17-2022 01:05 PM)Wes Loewer Wrote:  ⋮
It does not seem to be an optimization issue. Even without optimizations turned on, the compiler gives the same results.

Here’s a simple, intentionally undefined example that indicates what each compiler is probably doing.

Code:

a = 5;
a = 1000*a++ + 100*a++ + 10*a++;  // undefined expression.

Note: Since this is undefined, there is no guarantee that the results are indicative of the results a compiler would produce in a defined case, but it does suggest what a compiler might be doing. That said, here are some results:

gcc/clang/intel all print 5670
ms prints 5553
⋮

As an additional data point, I thought I’d try an Intel compiler (ICC 2021.5.0, optimizations on) on the following function:

Code:

int Wes2(int a)
{
a = 5;
a = 1000 * a++ + 100 * a++ + 10 * a++;
return a;
}

I got the following as output:

Code:

Wes2(int):
        mov       eax, 5553
        ret

I thought I’d also try the following, slightly different, function:

Code:

int Wes3(int &a)
{
a = 5;
a = 1000 * a++ + 100 * a++ + 10 * a++;
return a;
}

This slightly different function has the compiler producing the following, noticably distinct, output:

Code:

Wes3(int&):
        mov       eax, 6
        mov       DWORD PTR [rdi], 6
        ret

(Without optimization, for this last function, the compiler is producing code that increments three distinct temporaries by one and then assigning, as a final value for “a”, one of those three incremented-once temporaries, post increment.)

When one goes rooting around with undefined behaviour, one can certainly feel the hidden contours of the magic machinery behind the scenes. That said, after seeing the above, I tried a few other similar functions and there does seem to be some issues with the Intel compiler’s handling of assignment operations post-C++17. (Even with a command-line option given to specify the version of C++ wanted.)

[Wes Loewer]

(07-31-2022 01:29 AM)jte Wrote:  When I try that function out with MSVC++ v14.28 / 1928 (x64), optimizations on, I get the following:
...
But, if I add “/std:c++17” as a command-line option, I instead get the following:
...
So it seems that conformance with this part of the C++17 language does depend on the options given to the Microsoft compiler that I tried.

How careless of me. I incorrectly assumed that the compiler would default to the latest standard. I see now that even the current 2022 MS compiler (19.32.31332 for x64) still defaults to c++14. Thanks for pointing that out.

[Wes Loewer]

(07-31-2022 02:12 AM)jte Wrote:  [quote='Wes Loewer' pid='162310' dateline='1658063144']

Code:

a = 5;
a = 1000*a++ + 100*a++ + 10*a++;  // undefined expression.

Note: Since this is undefined, there is no guarantee that the results are indicative of the results a compiler would produce in a defined case, but it does suggest what a compiler might be doing. That said, here are some results:

gcc/clang/intel all print 5670

Just for fun, I installed my old MS Quick C 2.51 from 1990 in DOSBox. It produces 7650.

[toml_12953]

(07-31-2022 06:43 PM)Wes Loewer Wrote:  

(07-31-2022 02:12 AM)jte Wrote:  [quote='Wes Loewer' pid='162310' dateline='1658063144']

Code:

a = 5;
a = 1000*a++ + 100*a++ + 10*a++;  // undefined expression.

Note: Since this is undefined, there is no guarantee that the results are indicative of the results a compiler would produce in a defined case, but it does suggest what a compiler might be doing. That said, here are some results:

gcc/clang/intel all print 5670

Just for fun, I installed my old MS Quick C 2.51 from 1990 in DOSBox. It produces 7650.

At least all the digits are right!

[Wes Loewer]

(07-31-2022 07:25 PM)toml_12953 Wrote:  

(07-31-2022 06:43 PM)Wes Loewer Wrote:  gcc/clang/intel all print 5670
...
Just for fun, I installed my old MS Quick C 2.51 from 1990 in DOSBox. It produces 7650.

At least all the digits are right!

Since the expression was undefined, evaluating left-to-right or right-to-left are equally valid, or perhaps equally invalid. :-)

[xerxes]

(07-03-2022 09:38 AM)toml_12953 Wrote:  If it's not actually doing a decrement, it's an awfully big coincidence that it should still work the same, no?

That was my first thought too. i tried to find out, if it is possible to get the result of 876 without calculating the first solution correctly,
but every change of the code causes an incorrect result or an infinite loop. So I don't think, that this is possible or I'm missing something.