This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: asking for __attribute__((aligned()) clarification



> On Aug 21, 2019, at 10:28 AM, Alexander Monakov <amonakov@ispras.ru> wrote:
> 
> On Tue, 20 Aug 2019, "Markus Fröschle" wrote:
> 
>> Thank you (and others) for your answers. Now I'm just as smart as before, however.
>> 
>> Is it a supported, documented, 'long term' feature we can rely on or not?
>> 
>> If yes, I would expect it to be properly documented. If not, never mind.
> 
> I think it's properly documented in gcc-9:
> 
>  https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes.html
> 
> (the "old" behavior where the compiler would neither honor reduced alignment
> nor issue a warning seems questionable, the new documentation promises a more
> sensible approach)

I agree, but if the new approach generates a warning for code that was written to the old rules, that would be unfortunate.

> In portable code one can also use memcpy to move unaligned data, the compiler
> should translate it like an unaligned load/store when size is a suitable
> constant:
> 
>  int val;
>  memcpy(&val, ptr, sizeof val);
> 
> (or __builtin_memcpy when -ffreestanding is in effect)

Yes.  But last I tried, optimizing that for > 1 alignment is problematic because that information often doesn't make it down to the target code even though it is documented to do so.

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]