[libc++] ABI break: std::deque changes its size in LLVM 21

[zibi2]

The following code shows how the size of std::deque has changed in LLVM version 21.

// t.h

#include <deque>
#include <memory>
#include <cassert>


struct malloc_allocator_base {
  static std::size_t outstanding_bytes;
  static std::size_t alloc_count;
  static std::size_t dealloc_count;
  static bool disable_default_constructor;

  static std::size_t outstanding_alloc() {
    assert(alloc_count >= dealloc_count);
    return (alloc_count - dealloc_count);
  }

  static void reset() {
    assert(outstanding_alloc() == 0);
    disable_default_constructor = false;
    outstanding_bytes           = 0;
    alloc_count                 = 0;
    dealloc_count               = 0;
  }
};

size_t malloc_allocator_base::outstanding_bytes         = 0;
size_t malloc_allocator_base::alloc_count               = 0;
size_t malloc_allocator_base::dealloc_count             = 0;
bool malloc_allocator_base::disable_default_constructor = false;

template <class T>
class malloc_allocator : public malloc_allocator_base {
public:
  typedef T value_type;

  malloc_allocator() noexcept { assert(!disable_default_constructor); }

  template <class U>
  malloc_allocator(malloc_allocator<U>) noexcept {}

  T* allocate(std::size_t n) {
    const std::size_t nbytes = n * sizeof(T);
    ++alloc_count;
    outstanding_bytes += nbytes;
    return static_cast<T*>(std::malloc(nbytes));
  }

  void deallocate(T* p, std::size_t n) {
    const std::size_t nbytes = n * sizeof(T);
    ++dealloc_count;
    outstanding_bytes -= nbytes;
    std::free(static_cast<void*>(p));
  }

  friend bool operator==(malloc_allocator, malloc_allocator) { return true; }
  friend bool operator!=(malloc_allocator x, malloc_allocator y) { return !(x == y); }
};


int sizeOfCreatedDeque();
std::deque<int, malloc_allocator<int> > dq;

t.C

#include "t.h"

int sizeOfCreatedDeque() {
  dq.push_front(1);
  dq.push_front(2);
  dq.push_front(3);
  return sizeof(dq);
}

// t2.C

#include "t.h"
#include <iostream>

int main() {
using namespace std;
  int previousSize = sizeOfCreatedDeque();
  int currentSize = sizeof(dq);
  if (currentSize != previousSize)
    cerr << "ABI break std::deque`s size changed from " << previousSize << " to " << currentSize << endl;
  return 0;
}

Compile t2.C with LLVM 21/20 clang and t.C with previous version, for example LLVM 19 . Then, run executable:
I'm getting the following:
**ABI break std::deques size changed from 48 to 56** I compiled t.C` with clang version 18.1.8 but any version prior to PR 76756 would do as well.

My investigation point to #76756 as culprit.

[frederick-vs-ja]

The old __compressed_pair achieved EBO more thoroughly, while the new approach always puts the second member after the first one, which sometimes fails to reuse padding bytes of empty classes due to ABI restriction. CC @philnik777.

[perry-ca]

Sounds like this is something that needs to be fixed in LLVM 21. Agree?

[ldionne]

Yes, we need to fix this. We will also need to determine the extent of the breakage (we did similar changes in many many types) and get it addressed everywhere.

I will sync up with @philnik777 tomorrow.

[perry-ca]

Thanks Louis. Zibi did testing with the lit tests and the dump record layout to compare layouts between llvm 18 and llvm 21. We can share the results if you like.

[ldionne]

Thanks Louis. Zibi did testing with the lit tests and the dump record layout to compare layouts between llvm 18 and llvm 21. We can share the results if you like.

Yes, I think anything you have to share would be helpful.

Edit: @perry-ca Actually, I think we managed to get a decent understanding of the issue, no need to post additional data unless you have other reproducers that we might not be aware of. I'd be curious to know how you folks came across this ABI break though?

[ldionne]

Alright folks, I just met with @philnik777 and we went over this issue. This is the reproducer we came up with based on the OP: https://godbolt.org/z/o17Tb8f36

It appears that an empty member of type T marked with [[no_unique_address]] might end up at the end of the enclosing class (say Enclosing) if there is already a member of type T in Enclosing or in a subobject of Enclosing. We understand that the compiler needs to select a different address from the first T member, however we don't understand why the compiler decides to move the empty object to the end of the class, which ends up increasing the size of the overall type.

Sadly, this has a pretty large blast radius. It means that even code like this changes ABI whenever malloc_allocator<int> is empty:

struct UserContainer {
    std::vector<int, malloc_allocator<int> > vec_;
    [[no_unique_address]] malloc_allocator<int> alloc_;
};

// sizeof(UserContainer) changed between LLVM 19 and LLVM 20

This also applies to several other types where we made the _LIBCPP_COMPRESSED_PAIR change, including std::basic_string.

std::deque is a bit special (but perhaps not unique) in that std::deque holds a member of type __split_buffer, and that __split_buffer itself holds the allocator as a member. That is why the issue reproduces by checking sizeof(deque) directly in the OP, as opposed to witnessing the ABI break through another user-defined type.

We believe we have a fix for this issue but it will require a bit more work. The workaround is basically to use an anonymous struct around the members of the _LIBCPP_COMPRESSED_PAIR: https://godbolt.org/z/5K7ra7dE4. That allows restoring the old (pre-_LIBCPP_COMPRESSED_PAIR) ABI in the cases that we looked at.

Sadly, the timing for finding out about this issue is not ideal. The issue was introduced in LLVM 20, which is now considered "done" as we are working towards the LLVM 21 release (planned on August 26th according to https://llvm.org).

We would be able to fix this in LLVM 21, however I will also sync up with the release managers to discuss whether fixing LLVM 20 might still be doable. I suspect that many vendors for whom ABI stability is important (and are sometimes lagging a bit behind) might not have been impacted yet by the issue.

Summary

@tru @tstellar

We shipped an ABI break in LLVM 20. We believe we can fix it in time for LLVM 21.1.0 without further impacting the release process, but we would like to discuss the course of action for LLVM 20.

@philnik777 is working on getting us test coverage for this regression and preparing a fix. I will handle vendor communication once we've agreed on a decisive course of action.