Bug 36212 - Vector alignment overides Target alignment
Summary: Vector alignment overides Target alignment
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 minor
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2008-05-11 19:30 UTC by Andy Hutchinson
Modified: 2008-06-02 17:10 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: avr-unknown-none
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Andy Hutchinson 2008-05-11 19:30:48 UTC
For avr we have multiple failures of testcases due to alignment warnings such as:

gcc/gcc/testsuite/gcc.dg/debug/const-1.c:3: warning: alignment of 'Foo' is       greater than maximum object file alignment.  Using 1

Which in this example occurs due to:

    typedef float FloatVect __attribute__((__vector_size__(16)));
    FloatVect Foo = { 250000000.0, 0.0, 0.0, 0.0 };

While trying to fix this I have discovered several issues which make the "correct" fix somewhat unclear and perhaps indicating more than one bug.

The warning occurs because alignment of the vector is 16 bytes regardless of all target alignment controls. In particular:


By default this also determines MAX_OFILE_ALIGNMENT which is used by the alignment check in varasm.c (if (16>1) Warning)

Problem 1) varasm.c - is the only place MAX_OFILE_ALIGNMENT is used. Here it immediately tries to increase or decrease alignment AFTER it does check - which suggests the check is misplaced or not useful in the first place.

To get around the test failure target MAX_OFILE_ALIGNMENT can be increased. (and logically should be to permit user defined alignments)

Problem 2) Without hard limit imposed by MAX_OFILE_ALIGNMENT vectors are aligned at 16 bytes - which break the supposed limit of BIGGEST_ALIGNMENT (1 byte).

Vector size is set in stor-layout.c :

	/* Always naturally align vectors.  This prevents ABI changes
	   depending on whether or not native vector modes are supported.  */
	TYPE_ALIGN (type) = tree_low_cst (TYPE_SIZE (type), 0);

There is no way for target to override this alignment. It does not seem correct to assume a specific vector alignment independent of target. Perhaps there should be:


Some may say that vectors are relevant only targets that support hardware vector operations and thus alignment choice is currently moot. But..

Problem 3) gcc provide no hooks for  the target or testsuite to elegantly disable vector extensions (that I can find anyway).
Comment 1 Andrew Pinski 2008-05-11 19:38:17 UTC
>Problem 3) gcc provide no hooks for  the target or testsuite to elegantly
> disable vector extensions (that I can find anyway).

Problem 3 is bogus as vector extensions are generic and use what ever exist for your target.  Now the alignment should also be constraint by BIGGEST_ALIGNMENT .

I am in the process of rewriting the vector extension documentation so it should become more clear that it is a generic extension and has nothing to do with the target at all except for the fact they become faster.
Comment 2 Andy Hutchinson 2008-05-11 19:53:28 UTC
I was just covering bases with 3. I'll be quite content if the vectors could obey BIGGEST_ALIGNMENT.

Comment 3 Andy Hutchinson 2008-05-28 00:44:17 UTC

Will do 4.3 latter.

2008-05-12 Andy Hutchinson <hutchinsonandy@aim.com>

* config/avr/avr.h (MAX_OFILE_ALIGNMENT): Define.