Why does i += a[i]++ assign i before incrementing a[i] with Visual C++?

Question

Problem

• This example is a minimal reproduction of this issue encountered a code golf attempt. I am not advocating anyone use this style.

• I am aware I may have hit undefined behaviour, my question is: why specifically, and does this go for C as well as C++?

I have this file:

#include <stdio.h>
int main() {
    int a[]={1, 0}, i=0;
    i += a[i]++;
    printf("i=%d a=[%d, %d]\n", i, a[0], a[1]);
    return 0;
}

With GCC on Ubuntu on WSL I get the expected i=1 a=[2, 0] but with Visual C++ it is i=1 a=[1, 1]

The problem is fixed if I do this:

delta = a[i]++;
i += delta;

Whilst order of evaluation of assignment is unspecified, I am surprised that it appears that a[i] is evaluated again for the increment, after the assignment of i. The disassembly below seems to confirm this.

Do either the C or C++ standards allow this?

---

Background

Build command line and output on Windows:

>cl test.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.12.25830.2 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 14.12.25830.2
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj

Dissasembly of the statement (built with /Zi):

     4:     i += a[i]++;
00007FF6CBBA626C  movsxd      rax,dword ptr [i]  
00007FF6CBBA6271  mov         eax,dword ptr a[rax*4]  
00007FF6CBBA6275  mov         ecx,dword ptr [i]  
00007FF6CBBA6279  add         ecx,eax  
00007FF6CBBA627B  mov         eax,ecx  
00007FF6CBBA627D  mov         dword ptr [i],eax  
00007FF6CBBA6281  movsxd      rax,dword ptr [i]  
00007FF6CBBA6286  mov         eax,dword ptr a[rax*4]  
00007FF6CBBA628A  inc         eax  
00007FF6CBBA628C  movsxd      rcx,dword ptr [i]  
00007FF6CBBA6291  mov         dword ptr a[rcx*4],eax  

Answer 1

The code is well-defined in all versions of C and C++. You are seeing a bug in MSVC.

The definition of the += operator is that x += y means x = x + y, except that x is only evaluated once. (Note that "evaluate" is different to "lvalue conversion").

So we are looking at i = i + a[i]++.

Informally: the new value to store in i cannot be computed until both operands of + have been evaluated, and had lvalue conversion performed. Because we need the result of that lvalue conversion in order to know the value to store.

The term "evaluate" for an lvalue means to determine the memory location which the lvalue refers to. Evaluating a[i]++ when i is 0 beforehand means to determine that we are referring to a[0]. Then lvalue conversion retrieves the stored value of a[0], and the unsequenced side-effect is that the stored value of a[0] will be updated sooner or later.

Writing to a[0] has nothing to do with i, so there is no reason to believe there might be undefined behaviour.

---

More formally: prior to 2011, the C and C++ standards used a somewhat confusing sentence that expressed the logic in my "Informally:" paragraph. If the expression reads and writes i then it is well-defined only if the reads of i are all necessary to determine the new value to store in i, because that will guarantee that the reads have all happened before it is possible to store the new value.

In C11 and C++11 the language changed but not the implication. C11 6.5.16/3 (Assignment operators) says:

The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands.

which leaves no doubt that the write to i is sequenced after all reads of i on the right-hand side.

C++11 has similar language:

In all cases, the assignment is sequenced after the value computation of the right and left operands,