A workaround which does not require the lowering of the optimization level is to place the "buf" data object in its own section. i.e. #pragma DATA_SECTION(buf, ".data:buf") #pragma DATA_ALIGN(buf, 1024) static int buf[32]; The extra space in the original example is being introduced because the "buf" data object is being combined with other data objects into the .data section. If "buf" is not first in the .data section, then its alignment requirement will insert a large space between the data object that appears directly before "buf" in the .data section and "buf" itself in order to ensure that "buf" is properly aligned. By using the DATA_SECTION pragma to place "buf" in a separate section, the linker will ensure that the alignment requirements attached to the "buf" section will be honored at link-time. That is, at link time, the other data objects in the .data section will be placed independently from the "buf" data object in the .data:buf sub-section. If you want to explicitly control the placement of "buf" at link time, you can reference the section that "buf" is defined in from your linker command file. The above DATA_SECTION pragma will define "buf" in the .data:buf section which causes the linker to collect the .data:buf section into the same output section as the regular .data section. Most likely, the .data:buf section will be the first input section in the .data output section since it has the highest alignment requirements, the remaining objects defined in .data will likely be defined after "buf" in the output file generated by the linker. The end result should be a much smaller data size.

When the DATA_ALIGN pragma is used to give a global variable an alignment larger than its natural alignment, and the compiler groups globals to share a common base address (as it does at -o3 and -o4), the resulting data space can be excessively large as the compiler fails to arrange the variables optimally.