This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Options of fixing biggest alignment in PR target/38736
- From: Ian Lance Taylor <iant at google dot com>
- To: "Ye\, Joey" <joey dot ye at intel dot com>
- Cc: "gcc\ at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "Lu\, Hongjiu" <hongjiu dot lu at intel dot com>, Andrew Pinski <pinskia at gmail dot com>, "Guo\, Xuepeng" <xuepeng dot guo at intel dot com>, "Girkar\, Milind" <milind dot girkar at intel dot com>
- Date: Wed, 07 Jan 2009 07:55:42 -0800
- Subject: Re: Options of fixing biggest alignment in PR target/38736
- References: <F2363DE71B5050498545B523673042DE0190C38B78@pdsmsx503.ccr.corp.intel.com>
"Ye, Joey" <joey.ye@intel.com> writes:
> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for
> all x86 target, and extend to 64 or more bytes in future.
Assuming that code compiled with -mavx is intended to interoperate
with code compiled without -mavx, I believe that this is the only
viable long-term option. Unfortunately that would be a change in the
ABI for any code which exposes a struct with an attribute((aligned))
field.
BIGGEST_ALIGNMENT should always be a constant for code which can
interoperate.
I doubt that many ABIs expose a struct with a field with
attribute((aligned)), but as far as I can see we are going to have to
break those ABIs eventually. The question now is whether we should
break them for 4.4, for 4.5, or for some later version.
That said, I should also note that the glibc solution has been to fix
the maximum alignment at 8, in that that is the alignment which malloc
returns on the x86. I don't think that is a wise choice, but it is a
choice that we could also make: we could simply fix the x86
BIGGEST_ALIGNMENT at 16 and never change it in the future.
Ian