(check_cxx_fundamental_alignment_constraints is Dodji's, others CC:ed were already in the thread)
Looking into those atomic things and running tests for cris-elf, I get FAIL for libstdc++-v3/testsuite/29_atomics/atomic/65147.cc, specifically struct S16 { char c[16]; }; static_assert( alignof(std::atomic<S16>) >= 16, "atomic<S16> must be aligned to at least its size" ); which just isn't aligned for cris-elf. Its aligmnent is 1; the default. Trying to investigate using: #include <iostream> using std::cout; using std::endl; struct xx { alignas (16) char x[16]; }; xx ai; int main(void) { cout << "alignof(ai): " << __alignof__(ai) << endl; } yields: b.cc:5:25: warning: requested alignment 16 is larger than 8 [-Wattributes] alignas (16) char x[16]; which is mysterious (where does the 8 come from?), until I grep the error string and find c-family/c-common.c:check_cxx_fundamental_alignment_constraints. In there, I see target macros used, among them BIGGEST_ALIGNMENT. This is 8 for cris-elf: the *bit alignment* (there's a bug there already; bits not bytes) of the biggest *required* alignment (modulo atomics) for types, not the biggest *supported* alignment. So, the wrong macro (and unit) is used. Similarly, BIGGEST_FIELD_ALIGNMENT is about *require*, not *support*. Changing either macro is also an ABI change. Why not allow the presumably most relaxed value for types, like for __attribute__ ((__aligned__())), i.e. MAX_OFILE_ALIGNMENT, then a tighter alignment check when declaring an object? Right now, MAX_OFILE_ALIGNMENT is only used in check_cxx_fundamental_alignment_constraints when the scope is *known* to be file-scope and I know MAX_OFILE_ALIGNMENT sounds like it's only for file-scope variables, but well, that's what we have here, so the error is wrong. So, into what shall BIGGEST_ALIGNMENT change in check_cxx_fundamental_alignment_constraints? brgds, H-P