On 10/30/2018 04:34 PM, Joseph Myers wrote:
On Tue, 30 Oct 2018, Martin Sebor wrote:
So it seems that the attribute handler should be using this macro
instead. I also took the liberty to add more detail to the error
Note that it should only be used for alignments relevant to the object
file - *not* for alignments of variables with automatic storage duration
(and thus not for alignments of types / struct fields, because such types
might only be used on the stack) since GCC supports arbitrary alignments
on the stack via dynamically realigning it.
So you need testcases that verify that large alignments are still allowed
for types / fields / on the stack, even when the object file only
supports
smaller alignments.
Good catch, thanks! Attached is an updated patch that relaxes
the restriction to allow auto variables to be aligned on a more
restrictive boundary than MAX_OFILE_ALIGNMENT would imply.
I spent far more time building and testing various cross-toolchains
than I did on the GCC change, mainly because I couldn't find a way
to programmatically detect the value of MAX_OFILE_ALIGNMENT (or
the maximum alignment supported by GCC). In the end I stuck with
the hardcoding. If there isn't one, how about adding a couple
predefined macros for these?
The test is also pretty hacky (and I wouldn't surprised if it
failed on some system I didn't exercise). Having GCC expose
these parameters in some way would make the test cleaner (and
more robust, though one might make the argument that relying
on GCC-generated values to verify those same values would
actually make it less robust).
In this revision I also updated the MAX_OFILE_ALIGNMENT desciption
in the internals manual.
Retested on x86_64-linux, plus using cross-compilers for hppa64,
pdp11, and powerpc-darwin.
Martin