This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT
- From: dewar at gnat dot com (Robert Dewar)
- To: aoliva at redhat dot com, kenner at vlsi1 dot ultra dot nyu dot edu
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Sat, 19 Apr 2003 22:23:00 -0400 (EDT)
- Subject: Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT
> Thanks, I do see your point now. However, I still don't think the
> compiler should disregard alignment requirements set to the type just
> because an object is not part of a record. I do agree that the
> compiler may do it, and it may even happen by chance, but the property
> of the type should carry over to objects and fields uniformly, in the
> absence of an overrider. The same point you make for someone setting
> the alignment for an object to something different than the type's
> alignment could be made for someone setting the alignment for say a
> typedef, expecting it to affect all uses of the typedef.
> Distinguishing between type-specified and decl-specified alignments
> defeats this purpose.
yes, of course the properties of the type must carry over to objects. But
once again, if you specify an alignment of 1 for a big string (in fact
this is the default alignmment):
type R is new string (1 .. 1000);
for R'Alignment use 1;
Then most certainly any stand alone object of type R must have an alignment
of 1, but most certainly may have a larger alignment, and giving stand alone
objects of this type nice large alignments is in fact a very appropriate
optimization (and one that is quite target dependent, so we certainly do
NOT want the user to have to specify a large alignment explicitly).