This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Issue 2 with "[libstdc++/65033] Give alignment info to libatomic"
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: <jwakely at redhat dot com>, <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 17:53:08 +0000
- Subject: Re: Issue 2 with "[libstdc++/65033] Give alignment info to libatomic"
- Authentication-results: sourceware.org; auth=none
- References: <201504130559 dot t3D5xnGu004491 at ignucius dot se dot axis dot com>
On Mon, 13 Apr 2015, Hans-Peter Nilsson wrote:
> 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?
When I was making sure C diagnosed unsupported extended alignments, my
conclusion was that the support for realigning the stack means that
MAX_OFILE_ALIGNMENT is supported everywhere (except for malloc, of
course). See <https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02187.html>
for my analysis.
--
Joseph S. Myers
joseph@codesourcery.com