This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Issue 2 with "[libstdc++/65033] Give alignment info to libatomic"


(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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]