Title
Scalar object vs memory location in definition of “unsequenced”
Status
cd4
Section
6.9.1 [intro.execution]
Submitter
Jens Maurer

Created on 2015-06-22.00:00:00 last changed 87 months ago

Messages

Date: 2016-02-15.00:00:00

Proposed resolution (February, 2016):

Change 6.9.1 [intro.execution] paragraph 15 as follows:

...If a side effect on a scalar object memory location (6.7.1 [intro.memory]) is unsequenced relative to either another side effect on the same scalar object memory location or a value computation using the value of any object in the same scalar object memory location, and they are not potentially concurrent (6.9.2 [intro.multithread]), the behavior is undefined. [Note: The next section...
Date: 2016-02-15.00:00:00

[Adopted at the February, 2016 meeting.]

According to 6.9.1 [intro.execution] paragraph 15,

If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, and they are not potentially concurrent (6.9.2 [intro.multithread]), the behavior is undefined.

Should this refer to “memory location,” which also encompasses contiguous bit-fields, as the definition of data races in 6.9.2 [intro.multithread] does? For example,

  struct S {
    int x : 4;
    int y : 4;
    int z : 4;
  };

  void f(int, int, int);
  int g(int, S&);

  int main(int argc, char ** argv) {
    S s = { argc, argc+1, argc+2 };
    f(++s.x, g(++s.y, s), ++s.z);
  }
History
Date User Action Args
2017-02-06 00:00:00adminsetstatus: tentatively ready -> cd4
2016-02-15 00:00:00adminsetmessages: + msg5691
2016-02-15 00:00:00adminsetstatus: drafting -> tentatively ready
2015-06-22 00:00:00admincreate