On Mon, 16 Mar 2015, Eric Botcazou wrote: > > If we have BIGGEST_ALIGNMENT=16 that means we have likely a 16 bit > > architecture. I doubt that the strict alignment code makes any sense for > > modesize> BIGGEST_ALIGNMENT. > > Note that m68k is a 32-bit port (UNITS_PER_WORD is 4) but, by definition of > BIGGEST_ALIGNMENT, not honoring an alignment larger than it is perfectly OK.
The context of the above statement is somewhat ambiguous: if the statement is taken to include "no matter what is specified in the program, including use of __attribute__ ((__aligned__ ...))" then I have to object. (I guess Eric, you didn't actually mean that, though.) The definition of BIGGEST_ALIGNMENT is (tm.texi.in): "Biggest alignment that any data type can require on this machine, in bits. Note that this is not the biggest alignment that is supported, just the biggest alignment that, when violated, may cause a fault." So, IMNSHO we'd better *support* a *larger* alignment, as in "if the code specified it by explicit means" at least up to MAX_OFILE_ALIGNMENT. But, "perfectly OK" when the code didn't explicitly say anything else. BTW, unfortunately, BIGGEST_ALIGNMENT can't be blindly followed for atomic accesses to undecorated (without explicit alignment specifiers) code either. Rather the minimum alignment is the natural alignment *absolutely everywhere no matter what target* which matters for targets where BIGGEST_ALIGNMENT < natural_alignment(<all supported types>) (well, as long as the natural alignment is smaller than the target page-size or cache-line, where at least one of the concepts is usually applicable). Q: So why not adjust the BIGGEST_ALIGNMENT definition in such targets to be at least the natural alignment of supported atomic types? A: Because that unfortunately has bad effects on generated code for all accesses to all sizes now <= BIGGEST_ALIGNMENT. brgds, H-P PS. It's very unfortunate that there's now __BIGGEST_ALIGNMENT__ visible to programs.
