This is expected behavior, not a compiler bug — the confusion comes from mixing up two different guarantees.

The left-to-right evaluation guarantee you're thinking of applies to braced-init-list element evaluation order (each element of { ... } is sequenced before the next). That part is correctly honored by all three compilers: element 0 (args[0] + step()) is fully evaluated before element 1, which is fully evaluated before element 2.

But that guarantee only sequences the elements relative to each other — it says nothing about the order of evaluation of the two operands within a single element, i.e. args + step(). The order of evaluating the left operand (args) vs. the right operand (step()) of operator+ is unspecified in C++ (and was even unsequenced pre-C++17 relative to each other; as of C++17 the operands of most binary operators are indeterminately sequenced, not interleaved, but there's still no rule that says "left operand's side effects visible before right operand evaluates" for a plain +).

So for each array element (args[i] + step()):

• GCC evaluates args[i] first, then calls step() — giving 10+1, 20+2, 30+3 -> 11 22 33
• Clang/MSVC evaluate step() first, then use args[i] — giving (call step() -> returns 1, but by the time all three step() calls happen in whatever order the compiler chose along with reads of args)...

Actually to be precise about your specific numbers (13 22 31): that pattern is consistent with step() being evaluated for all elements in a different order than left-to-right, or with the compiler choosing right-operand-first evaluation per element while still keeping elements sequenced. Either way, the root cause is the same: the standard does not fix the evaluation order of args + step()'s two operands, only the order of the array elements themselves. Because step() has an observable side effect (mutating counter) and there's no sequencing between it and the read of args, the overall program has unspecified (not undefined, since no single scalar is modified twice without sequencing) behavior with respect to which counter value each args[i] gets paired with.

This is not related to parameter pack expansion order at all — (args + step())... expanding into {a0+step(), a1+step(), a2+step()} is deterministic and left-to-right across elements on every conformant compiler. The nondeterminism is purely from operator+'s unspecified operand evaluation order, colliding with a global side effect in one operand.

To get guaranteed, portable left-to-right pairing, force sequencing explicitly, e.g.:

int arr[] = { (step(), args)... };  // still relies on comma operator sequencing, but changes what's paired

or cleaner, decouple the side effect from the expression entirely:

int i = 0;
int arr[] = { (args + (++i))... };

or use an immediately-invoked lambda per element to force order:

int arr[] = { [&]{ int s = step(); return args + s; }()... };

Any of these removes the unspecified-order operand pairing and will give you consistent 11 22 33 on every compiler.