public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/99143] New: Bad section alignment on AArch64
@ 2021-02-17 23:14 nyphbl8d at gmail dot com
  2021-02-17 23:43 ` [Bug target/99143] " pinskia at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: nyphbl8d at gmail dot com @ 2021-02-17 23:14 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

            Bug ID: 99143
           Summary: Bad section alignment on AArch64
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nyphbl8d at gmail dot com
  Target Milestone: ---

aarch64-rtems6-gcc -v output:
Using built-in specs.
COLLECT_GCC=aarch64-rtems6-gcc
COLLECT_LTO_WRAPPER=/home/opticron/rtems-development/tools/libexec/gcc/aarch64-rtems6/10.2.1/lto-wrapper
Target: aarch64-rtems6
Configured with: ../gnu-mirror-gcc-949e0ad/configure
--prefix=/home/opticron/rtems-development/tools
--bindir=/home/opticron/rtems-development/tools/bin
--exec_prefix=/home/opticron/rtems-development/tools
--includedir=/home/opticron/rtems-development/tools/include
--libdir=/home/opticron/rtems-development/tools/lib
--libexecdir=/home/opticron/rtems-development/tools/libexec
--mandir=/home/opticron/rtems-development/tools/share/man
--infodir=/home/opticron/rtems-development/tools/share/info
--datadir=/home/opticron/rtems-development/tools/share --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=aarch64-rtems6 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
Thread model: rtems
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200918 (RTEMS 6, RSB
f5fc2bfabbd18f31901ffa6fc0e5b6b47874797c-modified, Newlib 749cbcc) (GCC)

Source file test-align.c:
char i;
char j[1];
char z[0];
unsigned long ai = _Alignof(i);
unsigned long aj = _Alignof(j);
unsigned long az = _Alignof(z);

Command line:
aarch64-rtems6-gcc -O2 -S -o - test-align.c -mabi=ilp32 -fdata-sections

Compiler output:
        .arch armv8-a
        .file   "test-align.c"
        .text
        .global az
        .global aj
        .global ai
        .global z
        .global j
        .global i
        .section        .bss.i,"aw",@nobits
        .type   i, %object
        .size   i, 1
i:
        .zero   1
        .section        .bss.j,"aw",@nobits
        .align  3
        .type   j, %object
        .size   j, 1
j:
        .zero   1
        .section        .bss.z,"aw",@nobits
        .align  3
        .type   z, %object
        .size   z, 0
z:
        .section        .data.ai,"aw"
        .align  2
        .type   ai, %object
        .size   ai, 4
ai:
        .word   1
        .section        .data.aj,"aw"
        .align  2
        .type   aj, %object
        .size   aj, 4
aj:
        .word   1
        .section        .data.az,"aw"
        .align  2
        .type   az, %object
        .size   az, 4
az:
        .word   1
        .ident  "GCC: (GNU) 10.2.1 20200918 (RTEMS 6, RSB
f5fc2bfabbd18f31901ffa6fc0e5b6b47874797c-modified, Newlib 749cbcc)"

test-align.i from --save-temps:
# 1 "test-align.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test-align.c"
char i;
char j[1];
char z[0];
unsigned long ai = _Alignof(i);
unsigned long aj = _Alignof(j);
unsigned long az = _Alignof(z);

Description:
When generating data sections for i, j, z for AArch64/ILP32 (also applies to
LP64), GCC does not align data sections to anything less than 8 bytes, even
when _Alignof() claims that the alignment of all three data elements should be
1 byte.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
@ 2021-02-17 23:43 ` pinskia at gcc dot gnu.org
  2021-02-18 14:16 ` nyphbl8d at gmail dot com
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-02-17 23:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-17
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
are you complaining that the objects j and z are aligned in the object file as
8 bytes?  Or that aj, az have the value of 1?
Both are valid things to do.

This is the code which does exactly that GCC:

/* Align definitions of arrays, unions and structures so that
   initializations and copies can be made more efficient.  This is not
   ABI-changing, so it only affects places where we can see the
   definition.  Increasing the alignment tends to introduce padding,
   so don't do this when optimizing for size/conserving stack space.  */
#define AARCH64_EXPAND_ALIGNMENT(COND, EXP, ALIGN)                      \
  (((COND) && ((ALIGN) < BITS_PER_WORD)                                 \
    && (TREE_CODE (EXP) == ARRAY_TYPE                                   \
        || TREE_CODE (EXP) == UNION_TYPE                                \
        || TREE_CODE (EXP) == RECORD_TYPE)) ? BITS_PER_WORD : (ALIGN))

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
  2021-02-17 23:43 ` [Bug target/99143] " pinskia at gcc dot gnu.org
@ 2021-02-18 14:16 ` nyphbl8d at gmail dot com
  2021-02-18 14:46 ` schwab@linux-m68k.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: nyphbl8d at gmail dot com @ 2021-02-18 14:16 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

--- Comment #2 from Will <nyphbl8d at gmail dot com> ---
The issue is that these are not getting aligned down to the size of the type
causing extra space in the linker sets. The above may be a bad reduced test
case. Below is a test case that focuses on 4-byte alignment which is the
primary issue on ILP32. When compiling with ARM gcc instead of AArch64 gcc, the
int section is aligned at 4 bytes instead of 8.

An example closer to the real code:
test-linkersets.c:
#define RTEMS_USED __attribute__(( __used__ ))

#define RTEMS_SECTION( _section ) __attribute__(( __section__( _section ) ))

#define RTEMS_LINKER_SET_BEGIN( set ) \
   _Linker_set_##set##_begin

#define RTEMS_LINKER_SET_END( set ) \
   _Linker_set_##set##_end

#define RTEMS_LINKER_ROSET( set, type ) \
   type const RTEMS_LINKER_SET_BEGIN( set )[ 0 ] \
   RTEMS_SECTION( ".rtemsroset." #set ".begin" ) RTEMS_USED; \
   type const RTEMS_LINKER_SET_END( set )[ 0 ] \
   RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED

RTEMS_LINKER_ROSET( i, int );
RTEMS_LINKER_ROSET( ll, long long );

test-linkersets.i:
# 1 "test-linkersets.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test-linkersets.c"
# 17 "test-linkersets.c"
char const _Linker_set_c_begin[ 0 ] __attribute__(( __section__( ".rtemsroset."
"c" ".begin" ) )) __attribute__(( __used__ )); char const _Linker_set_c_end[ 0
] __attribute__(( __section__( ".rtemsroset." "c" ".end" ) )) __attribute__((
__used__ ));
int const _Linker_set_i_begin[ 0 ] __attribute__(( __section__( ".rtemsroset."
"i" ".begin" ) )) __attribute__(( __used__ )); int const _Linker_set_i_end[ 0 ]
__attribute__(( __section__( ".rtemsroset." "i" ".end" ) )) __attribute__((
__used__ ));
long long const _Linker_set_ll_begin[ 0 ] __attribute__(( __section__(
".rtemsroset." "ll" ".begin" ) )) __attribute__(( __used__ )); long long const
_Linker_set_ll_end[ 0 ] __attribute__(( __section__( ".rtemsroset." "ll" ".end"
) )) __attribute__(( __used__ ));

aarch64-rtems6-gcc -O2 -S -mabi=ilp32 -o - test-linkersets.c
        .arch armv8-a
        .file   "test-linkersets.c"
        .text
        .global _Linker_set_ll_end
        .global _Linker_set_ll_begin
        .global _Linker_set_i_end
        .global _Linker_set_i_begin
        .global _Linker_set_c_end
        .global _Linker_set_c_begin
        .section        .rtemsroset.c.begin,"a"
        .align  3
        .type   _Linker_set_c_begin, %object
        .size   _Linker_set_c_begin, 0
_Linker_set_c_begin:
        .section        .rtemsroset.c.end,"a"
        .align  3
        .type   _Linker_set_c_end, %object
        .size   _Linker_set_c_end, 0
_Linker_set_c_end:
        .section        .rtemsroset.i.begin,"a"
        .align  3
        .type   _Linker_set_i_begin, %object
        .size   _Linker_set_i_begin, 0
_Linker_set_i_begin:
        .section        .rtemsroset.i.end,"a"
        .align  3
        .type   _Linker_set_i_end, %object
        .size   _Linker_set_i_end, 0
_Linker_set_i_end:
        .section        .rtemsroset.ll.begin,"a"
        .align  3
        .type   _Linker_set_ll_begin, %object
        .size   _Linker_set_ll_begin, 0
_Linker_set_ll_begin:
        .section        .rtemsroset.ll.end,"a"
        .align  3
        .type   _Linker_set_ll_end, %object
        .size   _Linker_set_ll_end, 0
_Linker_set_ll_end:
        .ident  "GCC: (GNU) 10.2.1 20200918 (RTEMS 6, RSB
f5fc2bfabbd18f31901ffa6fc0e5b6b47874797c-modified, Newlib 749cbcc)"

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
  2021-02-17 23:43 ` [Bug target/99143] " pinskia at gcc dot gnu.org
  2021-02-18 14:16 ` nyphbl8d at gmail dot com
@ 2021-02-18 14:46 ` schwab@linux-m68k.org
  2021-02-18 15:09 ` nyphbl8d at gmail dot com
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: schwab@linux-m68k.org @ 2021-02-18 14:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
If you want to save space you should use -Os, not -O2.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
                   ` (2 preceding siblings ...)
  2021-02-18 14:46 ` schwab@linux-m68k.org
@ 2021-02-18 15:09 ` nyphbl8d at gmail dot com
  2021-02-18 15:24 ` schwab@linux-m68k.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: nyphbl8d at gmail dot com @ 2021-02-18 15:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

--- Comment #4 from Will <nyphbl8d at gmail dot com> ---
That's great to know and I may use it as a stopgap/workaround, but it's not so
much about saving space as preserving the packing behavior of sections that
seems to work as expected on other architectures (even 64bit ones).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
                   ` (3 preceding siblings ...)
  2021-02-18 15:09 ` nyphbl8d at gmail dot com
@ 2021-02-18 15:24 ` schwab@linux-m68k.org
  2021-02-18 15:28 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: schwab@linux-m68k.org @ 2021-02-18 15:24 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
That's still sacrificing speed for space.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
                   ` (4 preceding siblings ...)
  2021-02-18 15:24 ` schwab@linux-m68k.org
@ 2021-02-18 15:28 ` jakub at gcc dot gnu.org
  2021-02-18 15:31 ` jakub at gcc dot gnu.org
  2021-03-01 17:05 ` rearnsha at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-18 15:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Those assumptions are just wrong.
As e.g. the kernel people have been told, the only reliable way to ensure no
increases of alignment for speed happens is to use __attribute__((aligned
(...))) on the decls that should not be aligned more than stated (you can use
alignof (...) in the aligned attribute argument.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
                   ` (5 preceding siblings ...)
  2021-02-18 15:28 ` jakub at gcc dot gnu.org
@ 2021-02-18 15:31 ` jakub at gcc dot gnu.org
  2021-03-01 17:05 ` rearnsha at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-18 15:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See e.g.
https://lore.kernel.org/linux-toolchains/20201022073816.GQ2628@hirez.programming.kicks-ass.net/T/#mb5c0e7711db14091d8d7dcbe0f4087f2fb65b6db

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/99143] Bad section alignment on AArch64
  2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
                   ` (6 preceding siblings ...)
  2021-02-18 15:31 ` jakub at gcc dot gnu.org
@ 2021-03-01 17:05 ` rearnsha at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2021-03-01 17:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
There is nothing in C (or other languages for that matter) that will guarantee
that independent objects will be packed without space around them.  

So the premise of this bug report is simply invalid.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-03-01 17:05 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-17 23:14 [Bug c/99143] New: Bad section alignment on AArch64 nyphbl8d at gmail dot com
2021-02-17 23:43 ` [Bug target/99143] " pinskia at gcc dot gnu.org
2021-02-18 14:16 ` nyphbl8d at gmail dot com
2021-02-18 14:46 ` schwab@linux-m68k.org
2021-02-18 15:09 ` nyphbl8d at gmail dot com
2021-02-18 15:24 ` schwab@linux-m68k.org
2021-02-18 15:28 ` jakub at gcc dot gnu.org
2021-02-18 15:31 ` jakub at gcc dot gnu.org
2021-03-01 17:05 ` rearnsha at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).