[cfe-dev] Alignment problems in Clang's internal data structures?

[Ahmed Bougacha]

Hi all,

I've been looking into what might be alignment issues throughout clang.

Consider "DeclRefExpr::Create(.., NameInfo, ..)".  It allocates itself
and a few other structs in a single allocation, using the well-known
pattern:

  std::size_t Size = sizeof(DeclRefExpr);
  if (...)
    Size += sizeof(...);
  ...
  void *Mem = Context.Allocate(Size, llvm::alignOf<DeclRefExpr>());

The alignment should also take into account the trailing classes,
really.  In every Allocate call that has a non-trivial size, the
alignment should be correspondingly non-trivial.  Some calls just use
ASTContext's default, 8 (enough for most purposes, at least; better
than the explicit alignOf, which might be 4).


[skip forward if you don't care about the investigation]

Currently, I think we get away with this because 1) X86 is lenient, 2)
most people don't self-host on another architecture, and 3) at least
on ARM, alignment checking has to be explicitly enabled, statically or
dynamically.

On ARM, if you try running clang with either:
- SCTRL.A==1 (alignment checking on non-strict-aligned instructions)
(I should say I couldn't get this to work); or
- different LLVM CodeGen picking stricter instructions that actually
enforce alignment (what made me investigate),

it should crash, at some point.  On the LIT-tests, the first (of many)
to fail was
  test/Analysis/dead-stores.cpp
Indeed, on trunk clang, the "this" pointer in
  ASTTemplateArgumentListInfo::initializeFrom(Info, b, b, b)
is sometimes dynamically 4-aligned, whereas it is supposed to be
8-aligned (according to alignof and the IR we generate.)



This pattern is pervasive throughout clang, and even though a few
classes try to get it right (with a trailing AlignedCharArray), most
don't.  What do clang developers think?  Did I miss something,
perhaps?

UBSan's alignment sanitizer would be *very* useful here, but my
understanding is, ARM isn't currently supported, and running it on X86
is futile (at least x86_64, maybe i386 could reproduce though; that's
on my todo list.)

Thanks!

-Ahmed