Re: Altivec + 16 byte alignment

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> Please let us agree that this is just a bug, regardless of the CPU's
> requirements.  The alignment declaration might be used by the programmer
> to ensure that the lower bits are available for use as tag bits.
> 
> For example, the following program should result in either success
> or a compile error (if the requested alignment is not supported).
> But IMHO it should not result in an assertion failure.
> 
> 	#include <assert.h>
> 	#define ALIGN 32
> 	int main() {
> 		char c __attribute__((aligned(ALIGN)));
> 		assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
> 		return 0;
> 	}

You have my vote on the matter.

If we go back to Franz's original reply to my post regarding the
rs6000 port, he said "BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY
is 64 unless you give -mabi=altivec (in 3.2+)."   If you look at
assign_stack_temp_for_type and assign_stack_local_1, you will see
that BLKmode objects are aligned to BIGGEST_ALIGNMENT.  Thus, without
-mabi=altivec, you would randomly get an assertion failure, depending
on the stack alignment, if you checked the alignment of structs with
code similar to that above.  In other words, you aren't getting the
alignment of BLKmode stack locals that you have specified in the
backend.  Possibly, this doesn't matter, but it seems inconsistent
and I think would lead to problems if the compiler checked alignment
requests as suggested above.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)