Is implementation-defined behavior required to be consistent between runs in C++?

Question

Is a standard-conforming C++ implementation allowed to implement some behavior that is said to be implementation-defined in the standard in such way that it is different between different runs of the same compiled once program with the same input data?

For example, is an implementation allowed to say "the behavior is this on weekends and that otherwise" and implement behavior according to such statement?

Answer 1

Of course, if the implementation documents when exactly the behavior changes with different runs, that's fine. Notice that the implementation-defined behavior is part of the parameters of the abstract machine:

The semantic descriptions in this International Standard define a parameterized nondeterministic abstract machine.

Certain aspects and operations of the abstract machine are described in this International Standard as implementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects. Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the ‘‘corresponding instance’’ below).

This does not allow changing the behavior in a single run of the compiler. But between different runs of the compiler, the compiler may use a different corresponding abstract machine which differs by different implementation defined values, according to what the implementation defined. Command line parameters like -Wall (which changes the implementation-defined set of diagnostic messages) are the most common example of this. This is a difference to unspecified behavior in addition to the documentation requirements. Unspecified behavior is much less restrictive:

Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function). Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstract machine. An instance of the abstract machine can thus have more than one possible execution sequence for a given program and a given input.

Answer 2

One example I can think of is if the program uses big or little endian representation for numbers. I believe that this would certainly count as implementation defined behaviour.

On some chips, for example certain ARM chips it's possible to switch modes at run time so you might want a compiler which could produce a program that would run in either mode meaning that you have implementation defined behaviour which could potentially be different on each run depending on external settings.

Similarly I guess you could write a compiler which produced both 32 ad 64 bit compiled of the same program - and the mode it executed could be determined at run time. Again, the documentation would have to say that ints were 32 bit or 64 bit depending on how you ran it.

To be honest I can't see anyone doing either of these things, but they both sound vaguely plausible examples of what you were asking for and I can't see why they wouldn't be legal under the standard as long as the documentation properly documented the nature of the system dependent behaviour.