This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Florian Weimer <fweimer at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Mon, 23 Mar 2015 18:41:27 +0000
- Subject: Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1425285061 dot git dot fweimer at redhat dot com> <7a6fe503fb764beee3d5b89662d3bbf65242161c dot 1425285061 dot git dot fweimer at redhat dot com> <54F4BB15 dot 7070409 at cs dot ucla dot edu> <550C37F7 dot 10504 at redhat dot com> <550C4AE0 dot 60205 at cs dot ucla dot edu> <55103BEA dot 7070305 at redhat dot com> <5510505B dot 8060209 at cs dot ucla dot edu>
On Mon, 23 Mar 2015, Paul Eggert wrote:
> Florian Weimer wrote:
> > I would rather go with intmax_t because it's not
> > clear to me if __alignof__ (max_align_t) increases to 64 if AVX-512 is
> > enabled on x86_64.
>
> That would be a bug in the C compiler, right?
>
> Since C allows platforms where pointers and/or floating-point values have
> alignments stricter than intmax_t, I suggest using 'max (__alignof__
> (intmax_t), __alignof__ (max_align_t))' along with a comment explaining why
> you don't trust max_align_t here.
max_align_t was added to stddef.h in GCC 4.7, so we can't rely on it in
glibc without appropriate conditionals. However, I see no need to allow
for it being wrong (in code that isn't used outside of glibc).
It may well be more-aligned than intmax_t, on platforms where long double
has 16-byte size and alignment and intmax_t has 8-byte size and alignment
- so that does need allowing for in glibc.
--
Joseph S. Myers
joseph@codesourcery.com