https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80208
Bug ID: 80208 Summary: DJGPP max object file alignment regression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: gcc at pkh dot me Target Milestone: --- Using DJGPP, requested alignment is not clamped anymore: [/tmp]☭ echo 'int __attribute__ ((aligned (16))) x;' > a.c && i686-pc-msdosdjgpp-cc -c a.c [/tmp]☭ echo 'int __attribute__ ((aligned (32))) x;' > a.c && i686-pc-msdosdjgpp-cc -c a.c a.c:1:36: error: alignment of ‘x’ is greater than maximum object file alignment 16 int __attribute__ ((aligned (32))) x; ^ [/tmp]☠ This is a regression since r205040 (https://github.com/gcc-mirror/gcc/commit/f8f7421ff48c9a90a63281bb09ff67d4f56755cf). We hit that issue in the FFmpeg project where such alignment is requested in random places (because we sometimes have AVX2 optimizations, which shouldn't concern a FreeDOS configuration). Here is a simple patch that fixes the issue: --- gcc/varasm.c 2017-03-26 20:10:03.082212374 +0200 +++ gcc/varasm.c 2017-03-26 20:10:00.079320606 +0200 @@ -1005,8 +1005,8 @@ if (align > MAX_OFILE_ALIGNMENT) { - error ("alignment of %q+D is greater than maximum object " + warning (0, "alignment of %q+D is greater than maximum object " "file alignment %d", decl, MAX_OFILE_ALIGNMENT/BITS_PER_UNIT); align = MAX_OFILE_ALIGNMENT; } The fallback to MAX_OFILE_ALIGNMENT is still present so it's enough to fix the problem.