This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4575. No formal wording associates single total order of allocation/deallocation operations with the coherence rule

Section: 17.6.3.5 [new.delete.dataraces] Status: New Submitter: jim x Opened: 2026-05-03 Last modified: 2026-05-09

Priority: Not Prioritized

View other active issues in [new.delete.dataraces].

View all other issues in [new.delete.dataraces].

View all issues with New status.

Discussion:

17.6.3.5 [new.delete.dataraces] p1 says:

Calls to these functions that allocate or deallocate a particular unit of storage shall occur in a single total order, and each such deallocation call shall happen before the next allocation (if any) in this order.

Consider this example:

#include <thread>
#include <atomic>

int main(){
   std::atomic<bool> flag = false;
   std::jthread t1([&](){
      auto p = operator new(sizeof(int));  // #1
      while(!flag.load(std::memory_order::acquire))
        ;
      operator delete(p, sizeof(int)); // #2
   });

  std::jthread t2([&](){
    auto p2 = operator new(sizeof(int));  // #3
    flag.store(true, std::memory_order::release);
  });
}

Both #1 and #3 happens-before #2. Is it possible that #1 and #3 return the same address? We don't associate the single total order of allocation/deallocation operations with the happens-before(i.e., coherence rule defined in 6.10.2.2 [intro.races]).

Suggested Resolution Approach:

Associate the single total order with the coherence rule; this issue is similar to LWG 4519⁽ⁱ⁾. The current wording is hard to use proof by contradiction to prove that #1 and #3 cannot return the same address. Moreover, "the next allocation (if any) in this order" is also vague, which the "next" is relative to? Is the next allocation relative to the previous allocation in the total order, or to the previous deallocation? However, in this example, even if we associate the coherence rule with happens-before, the total order is #1 < #3 < #2(or, #3 < #1 < #2), it seems that the "next allocation" is meaningless if it is relative to the deallocation. Furthermore, de-shall is meaningful here because we impose a requirement on the implementations.

Proposed resolution: