Variable alignment is checked against MAX_OFILE_ALIGNMENT but function and label (-falign-label=n) alignment is not. This causes requests to the target code to generate alignment directives that the output format doesn't support, causing ICE at least in some targets. The attached testalign.c gets an error (on i386) for variable "ag", and on pdp11 also for variable "a4" (since max alignment on pdp11 is 2 bytes). But the corresponding function alignments do not generate error messages. File testalign2.c with -falign-labels=n also passes the requested alignment to the back end without checking it against MAX_OFILE_ALIGNMENT.
Created attachment 44923 [details] variable and function alignment test case
Created attachment 44924 [details] label alignment test case
*** Bug 87794 has been marked as a duplicate of this bug. ***
I added myself as a CC because I want to see if these become errors or warnings. For core parts of RTEMS, I can see wanting these to be errors since it indicates we did something in core OS code that did not achieve the desired results. But in application code, it might not be as well considered or necessary. So ultimately, it's a hard decision on how to treat mistakes in alignment requests
Confirmed. I get the following output with a pdp11-aout configured cross-compiler: $ cat t.c && gcc -S -O2 -Wall t.c int a2 __attribute__ ((aligned (2))); int a4 __attribute__ ((aligned (4))); int ag __attribute__ ((aligned (65536))); void f2(void) __attribute__ ((aligned (2))); void f4(void) __attribute__ ((aligned (4))); void fg(void) __attribute__ ((aligned (65536))); void f2(void) {} void f4(void) {} void fg(void) {} t.c:2:5: error: alignment of ‘a4’ is greater than maximum object file alignment 2 2 | int a4 __attribute__ ((aligned (4))); | ^~ t.c:3:5: error: alignment of ‘ag’ is greater than maximum object file alignment 2 3 | int ag __attribute__ ((aligned (65536))); | ^~ After removing the variable declarations I get an ICE: during RTL pass: final t.c: In function ‘f4’: t.c:6:1: internal compiler error: in assemble_start_function, at varasm.c:1801 6 | void f4(void) {} | ^~~~ 0x1345817 assemble_start_function(tree_node*, char const*) /ssd/src/gcc/svn/gcc/varasm.c:1801 0xaf2550 rest_of_handle_final /ssd/src/gcc/svn/gcc/final.c:4645 0xaf28c2 execute /ssd/src/gcc/svn/gcc/final.c:4723 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
(In reply to Joel Sherrill from comment #4) > I added myself as a CC because I want to see if these become errors or > warnings. For core parts of RTEMS, I can see wanting these to be errors > since it indicates we did something in core OS code that did not achieve the > desired results. But in application code, it might not be as well considered > or necessary. Interesting point. The current case that is rejected (alignment of variables) is an error, so for consistency I'd say the other cases should do likewise. If there is a desire to make too-large alignment into a warning, that might be better handled as a separate issue. It could be a switch of some sort. If changes are made, they should apply consistently to alignment of all kinds.
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01965.html
Author: msebor Date: Fri Nov 9 17:17:47 2018 New Revision: 265977 URL: https://gcc.gnu.org/viewcvs?rev=265977&root=gcc&view=rev Log: PR c/87795 - Excessive alignment permitted for functions and labels gcc/c-family/ChangeLog: PR c/87795 * c-common.c (check_user_alignment): Use MAX_OFILE_ALIGNMENT. gcc/testsuite/ChangeLog: PR c/87795 * gcc.dg/attr-aligned.c: New test. Added: trunk/gcc/testsuite/gcc.dg/attr-aligned.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/c-decl.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/testsuite/ChangeLog
Fixed for GCC 9 in 265977.