[Bug c/105886] New: GCC optimizes structs with FP registers but ignores alignment in this case

[Bug c/105886] New: GCC optimizes structs with FP registers but ignores alignment in this case

[keven.kloeckner at siemens dot com]

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

            Bug ID: 105886
           Summary: GCC optimizes structs with FP registers but ignores
                    alignment in this case
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: keven.kloeckner at siemens dot com
  Target Milestone: ---

Compiler output -v:

Using built-in specs.
COLLECT_GCC=aarch64-elf-gcc.exe
COLLECT_LTO_WRAPPER=c:/git/s74100gcc11/s74100cpu/s7p.tools/aarch64_gcc_elf_11.2.0/bin/../libexec/gcc/aarch64-elf/11.2.0/lto-wrapper.exe
Target: aarch64-elf
Configured with: ../../gcc-11.2.0//configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32
--prefix=/build/aarch64-elf_11.2.0-1/cross-gcc/aarch64-elf --target=aarch64-elf
--disable-nls --enable-multilib --with-multilib-list=lp64,ilp32
--enable-languages=c,c++ --disable-decimal-float
--with-sysroot=/build/aarch64-elf_11.2.0-1/cross-gcc/aarch64-elf
--without-headers --disable-shared --disable-threads --disable-lto
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libffi
--disable-libstdcxx-pch --disable-win32-registry
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-newlib --with-gcc --with-gnu-as --with-gnu-ld
--with-gmp=/build/aarch64-elf_11.2.0-1/host
--with-mpfr=/build/aarch64-elf_11.2.0-1/host
--with-mpc=/build/aarch64-elf_11.2.0-1/host
--with-isl=/build/aarch64-elf_11.2.0-1/host
--with-zstd=/build/aarch64-elf_11.2.0-1/host : (reconfigured)
../../gcc-11.2.0//configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --enable-languages=c,c++ --enable-multilib
--with-multilib-list=lp64,ilp32 --disable-lto --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libffi --with-newlib --with-gcc
--with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-libstdcxx-pch
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--target=aarch64-elf --prefix=/build/aarch64-elf_11.2.0-1/cross-gcc/aarch64-elf
--with-gmp=/build/aarch64-elf_11.2.0-1/host
--with-mpfr=/build/aarch64-elf_11.2.0-1/host
--with-mpc=/build/aarch64-elf_11.2.0-1/host
--with-isl=/build/aarch64-elf_11.2.0-1/host
--with-zstd=/build/aarch64-elf_11.2.0-1/host
--with-sysroot=/build/aarch64-elf_11.2.0-1/cross-gcc/aarch64-elf
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)


The problem occurs on our Windows to Arm Cortex A53 Cross compile.
No errors or warnings during compilation. We have enabled alignment check for
some purposes and we cannot disable it. This problem occurs also in C++, not
only in C (iam sorry if i put the bug wrong).

(for readability i removed all defines and link inputs)
Command Line: 
../../../../aarch64_gcc_elf_11.2.0/bin/aarch64-elf-gcc           -fno-builtin  
 -c    -std=gnu11    -Wno-pointer-to-int-cast    -Wno-int-to-pointer-cast   
-Wno-maybe-uninitialized       -Werror                
-mabi=ilp32 -march=armv8-a+crypto+crc -mtune=cortex-a53 -mstrict-align
-mno-outline-atomics      -Werror=return-type   -Werror=format  
-Werror=address   -Werror=array-bounds   -Werror=format-extra-args  
-Werror=init-self   -Wno-error=array-bounds        -Wno-error=stringop-overflow
    -Wno-error=free-nonheap-object       -mlittle-endian   -fno-common  
-fno-merge-constants   -ffunction-sections   -fdata-sections  
-fno-toplevel-reorder   -O0      -Werror      -nostdinc   -ggdb

For some reason the GCC 11.2 is using floating point register instructions to
optimize initialization of structs if a lot of members are initialized with the
same constant successively. 
The problem is that the GCC generates the following instructions:
stp   q0, q0, [x0]  //128 bit alignment required problem -> usually we use 64
bit 
                    //alignment
str   q0, [x0, #32] // 64 bit alignment -> ok
stur  q0, [x0, #44] // offset with 32 bit alignment but intruction with 64 bit 
                    //required alignment -> hard problem

My assumption is the compiler somehow thinks the FP registers are 4 byte or the
instructions require 4 byte alignment. I expected the compiler to ensure the
alignment if he is optimizing, which i can clearly see he is ignoring or doing
it wrong. If more informations are needed please contact me.

With kind regards
Keven Kloeckner

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2022-06-08
            Summary|GCC optimizes structs with  |-mstrict-align is ignorning
                   |FP registers but ignores    |unalign in some cases
                   |alignment in this case      |
     Ever confirmed|0                           |1
          Component|c                           |target
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you attach the preprocessed source?

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |103100

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect this is a dup of bug 103100 really.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
[Bug 103100] [11/12/13 Regression] unaligned access generated with memset or {}
and -O2 -mstrict-align

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[keven.kloeckner at siemens dot com]

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

--- Comment #3 from Keven <keven.kloeckner at siemens dot com> ---
Created attachment 53110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53110&action=edit
precompiled file

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[keven.kloeckner at siemens dot com]

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

--- Comment #4 from Keven <keven.kloeckner at siemens dot com> ---
Created attachment 53111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53111&action=edit
Disassembly screen

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[keven.kloeckner at siemens dot com]

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

--- Comment #5 from Keven <keven.kloeckner at siemens dot com> ---
Created attachment 53112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53112&action=edit
source file

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes it is a dup of bug 103100 . I hope next week I finish up the patch for it.

*** This bug has been marked as a duplicate of bug 103100 ***

[Bug target/105886] -mstrict-align is ignorning unalign in some cases

[keven.kloeckner at siemens dot com]

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

--- Comment #7 from Keven <keven.kloeckner at siemens dot com> ---
Thank you for your fast investigation :)