Nicholas, Your suggestion is not good either. First of all, 'packed' attribute may also change the layout of the structure and may incur performance penalties even if the layout stays the same (e.g. on some machines it may make compiler generate the code which accesses the structure in bytes access to the structure instead of word/half-word access). I'd like to avoid that. As I said, I worked it around by adding __attribute__((aligned(4))) instead. There is an even better solution: add __attribute__((aligned(__alignof__(struct foo)))) to the instances of the affected structures; this automatically selects the alignment as specified by command line options, structure contents, etc. E.g., -malign-double on i386 would cause the structure containing 'double' members to be aligned to 8 bytes. However, the questions from original mail still stand: * Why does GCC perform such alignments? * Is it possible to turn such alignments off globally? Regards, Alexey. > Add the packed attribute "__attribute__ ((packed))" to where you are > instantiating these structures, if not the structures themselves. This > should override the aligning that is automatically done on it. > >> -----Original Message----- >> From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On >> Behalf Of Alexey Neyman >> Sent: Sunday, July 13, 2008 2:28 PM >> To: gcc-help@xxxxxxxxxxx >> Subject: Alignment of large structures in GCC >> >> Hi, >> >> I ran into the following problem using gcc: I am using some structures, >> which are put into a dedicated section. The linker concatenates these >> sections from all files; I have a linker script which assigns symbols >> to the start and end of this section. When I need to traverse all these >> structures, I then use the following loop: >> >> struct somename *p; >> for (p = &__start_section; p < &__end_section; p++) { >> ... >> >> All worked well when the size of the structure was below 32 bytes. When >> I added an additional field, GCC suddenly started aligning each >> structure to 32 bytes - so the structures in this section are padded to >> 32-byte boundary. As the size of the structure is 36 bytes, though, the >> loop above breaks on the 2nd element: it tries to access it at >> &__start_section + 36, while the structure is actually at >> &__start_section + 64. >> >> I narrowed it down to the following example: >> >> <<< >> struct { >> int xxx[NINT]; >> } aaa __attribute__((section(".foo"))); >> <<<< >> >> When compiled, GCC selects the following alignments: >> >> $ gcc -o - -S gg.c -DNINT=7 | grep align >> .align 4 >> $ gcc -o - -S gg.c -DNINT=8 | grep align >> .align 32 >> $ gcc -o - -S gg.c -DNINT=9 | grep align >> .align 32 >> >> That's especially strange since __alignof__ reports the alignment of >> this structure as 4. It seems natural that the size of the structure >> should be a multiple of its alignment. >> >> For now, I circumvented it by adding __attribute__((aligned(4))) to >> these structures. However, it may not be good if this structure gets a >> new member which would have a 8-byte alignment. >> >> The question is, why does GCC perform such 32-byte alignment and is it >> possible to turn off such behavior globally? >> >> P.S. GCC version: >> >> $ gcc -v >> Using built-in specs. >> Target: i386-redhat-linux >> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man >> --infodir=/usr/share/info --enable-shared --enable-threads=posix >> --enable-checking=release --with-system-zlib --enable-__cxa_atexit >> --disable-libunwind-exceptions >> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada >> --enable-java-awt=gtk --disable-dssi --enable-plugin >> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre >> --enable-libgcj-multifile --enable-java-maintainer-mode >> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic >> --host=i386-redhat-linux >> Thread model: posix >> gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) >> >> Best regards, >> Alexey.
