This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Issue 2 with "[libstdc++/65033] Give alignment info to libatomic"
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: jwakely at redhat dot com
- Cc: rth at redhat dot com, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, dodji at redhat dot com
- Date: Mon, 13 Apr 2015 07:59:49 +0200
- Subject: Issue 2 with "[libstdc++/65033] Give alignment info to libatomic"
- Authentication-results: sourceware.org; auth=none
(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