[Bug target/91927] New: -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
Bug ID: 91927
Summary: -mstrict-align doesn't prevent unaligned accesses at
-O2 and -O3 on AARCH64 targets
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gr.audio at gmail dot com
Target Milestone: ---
Target: aarch64-elf
Hello,
I'm writing code for an AARCH64 target, and ran into the following issue.
First off, at the stage my code runs, the MMU is not enabled, so the CPU
doesn't allow unaligned accesses. I thus enabled the "-mstrict-align" option.
The GCC (8.3.0) binaries I'm using are from ARM:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads
but I built GCC 9.2.0 for aarch64-elf and got the same issue.
I get an exception (unaligned access) when my code runs, and investigated. Here
is how it happens.
I'm accessing successively two successive uint32_t members of a packed struct:
eg:
---
typedef struct __attribute__((__packed__))
{
...
uint32_t nWidth;
uint32_t nHeight;
...
} MyStruct_t;
...
MyStruct_t sThisStruct;
...
// My code accesses them just like so:
... = sThisStruct.nWidth;
... = sThisStruct.nHeight;
---
At -O2 and -O3, despite the "-mstrict-align" option, GCC emits code that
creates an unaligned access:
ldr d0, [sp, 52]
(SP + 52 is 4-byte aligned obviously, but not 8-byte aligned, and thus, this
64-bit access yields an exception.)
GCC optimizes the two 32-bit accesses in one 64-bit access, but it shouldn't in
this case, with the "-mstrict-align" option.
At -O1 and below, GCC correctly emits:
ldr w0, [sp, 52]
...
ldr w0, [sp, 56]
instead, which are correctly aligned accesses.
This issue looks like a cousin to the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71727
It looks like the "-mstrict-align" option is not correctly enforced at certain
optimization levels, for different optimizations (but with the same overall
problem of potentially unaligned accesses).
---
GCC version:
Target: aarch64-elf
Configured with:
/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-elf/build/src/gcc/configure
--target=aarch64-elf
--prefix=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-elf/build/bui
ld-mingw-aarch64-elf/install//
--with-gmp=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-el
f/build/build-mingw-aarch64-elf/host-tools
--with-mpfr=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i68
6--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--with-mpc=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot
/mingw32-i686--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--with-isl=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i
686/buildbot/mingw32-i686--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--disable-shared --disable-nls --disable-thre
ads --disable-tls --enable-checking=release --enable-languages=c,c++,fortran
--with-newlib --with-libiconv-prefix=/tmp/dgbote
r/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--host=i68
6-w64-mingw32 --with-pkgversion='GNU Toolchain for the A-profile Architecture
8.3-2019.03 (arm-rel-8.36)' --with-bugurl=https
://bugs.linaro.org/
Thread model: single
gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03
(arm-rel-8.36))
---
Also happens with aarch-64-elf-gcc 9.2.0 (custom built).
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 --- Comment #2 from Guillaume --- Thanks for your quick reply. Yes, I actually managed to write a minimal test case showing the problem (attached source file). Compiling it with: aarch64-elf-gcc -mcpu=cortex-a72 -march=armv8-a+crc -O3 -mstrict-align -S Unaligned_Access.c I get the following assembly code: TestCase: cbz x0, .L7 stp x29, x30, [sp, -48]! mov x29, sp str x19, [sp, 16] mov x19, x0 add x0, sp, 32 str xzr, [sp, 32] str wzr, [sp, 40] bl SetTag ldr d0, [sp, 36] str d0, [x19, 8] ldr x19, [sp, 16] ldp x29, x30, [sp], 48 ret As can be seen here, an "ldr d0, [sp, 36]" instruction is emitted, which is a 64-bit transfer on an address aligned to 4-byte, but not aligned to 8-byte (sp + 36). This particular test case doesn't seem to generate a problem with -O2, only with -O3, but my own code did. With -O2, it emits "ldp w1, w0, [sp, 36]" instead of " ldr d0, [sp, 36]", which I believe should be aligned? I didn't find how to show the same behavior with -O2 as happens with -O3, with a simple test case, so far, so you may add to the report that the problem with -O2 is unconfirmed. Thanks for your time, Le sam. 28 sept. 2019 à 00:53, pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> a écrit : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 > > --- Comment #1 from Andrew Pinski --- > Do you have a full testcase? > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 --- Comment #4 from Guillaume --- Thanks :) Le sam. 28 sept. 2019 à 02:13, pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> a écrit : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 > > Andrew Pinski changed: > >What|Removed |Added > > >Keywords||wrong-code > Status|UNCONFIRMED |NEW >Last reconfirmed||2019-09-28 > Ever confirmed|0 |1 > Known to fail||7.3.0 > > --- Comment #3 from Andrew Pinski --- > Confirmed. > The misalignment check does not take into account if the misalignment is > known > at compile time :). > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
--- Comment #5 from Guillaume ---
I think I found a work-around for the time being.
If you define your packed structs with the 'volatile' qualifier, the bug
doesn't seem to show up. May not be completely ideal, but it appears to work,
and the reason why makes sense.
Like so: typedef volatile struct __attribute__((__packed__)) { ... }
Of course, would still be nice to fix the misalignment check...
[Bug libstdc++/80196] fenv_t not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80196 Guillaume changed: What|Removed |Added CC||gr.audio at gmail dot com --- Comment #7 from Guillaume --- Same problem while trying to build gcc 11.1.0 on Arch Linux (host and target = Windows). Configuration: configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix="$PREFIX" --disable-nls --enable-languages=c,c++,ada --with-pkgversion=GR20210618 --enable-threads=win32 --disable-win32-registry --disable-multilib --enable-shared --enable-static --disable-sjlj-exceptions --with-dwarf2 Adding the '--disable-libstdcxx-pch' option doesn't help in my case, same errors. The cross-compiler installed on my Arch Linux for building Windows executables is x86_64-w64-mingw32-gcc. 'x86_64-w64-mingw32-gcc -v' yields: Utilisation des specs internes. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/lto-wrapper Cible : x86_64-w64-mingw32 Configuré? avec: /build/mingw-w64-gcc/src/gcc/configure --prefix=/usr --libexecdir=/usr/lib --target=x86_64-w64-mingw32 --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,lto,c++,ada,objc,obj-c++,fortran --enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --with-system-zlib --enable-cloog-backend=isl --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-sjlj-exceptions --with-dwarf2 Modè?le de thread: posix Algorithmes de compression LTO supporté?s: zlib zstd gcc version 11.1.0 (GCC)
[Bug libstdc++/80196] fenv_t not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80196 --- Comment #11 from Guillaume --- Thanks! Wasn't happening with previous versions. Is there a workaround?
[Bug libstdc++/80196] fenv_t not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80196 --- Comment #14 from Guillaume --- OK, this patch fixes it for me as well.
[Bug c/116211] New: C Functions returning a struct always manipulate the stack pointer on RISC-V targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116211
Bug ID: 116211
Summary: C Functions returning a struct always manipulate the
stack pointer on RISC-V targets
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gr.audio at gmail dot com
Target Milestone: ---
Here's what I consider a "bug" for RISC-V targets (32 & 64) with GCC 14.1
(tested down to v8, so that's a long-standing one), even if it doesn't produce
incorrect code, it generates unnecessary code.
Any C function returning a struct, even when the stack is not used within said
function, generates instructions for reserving space on the stack, and
restoring sp afterwards. I don't see an ABI reason for doing so, and FYI, LLVM
doesn't generate such code.
Here is a minimal code that triggers this oddity;
[code]
#include
typedef struct
{
double x;
uint64_t n;
} Test_t;
Test_t Foo(double x1, uint64_t n1)
{
return (Test_t){ .x = x1, .n = n1 };
}
[/code]
The generated assembly at -O1 to -O3 is:
[code]
Foo:
addisp,sp,-32
addisp,sp,32
jr ra
[/code]
Note that the struct needs to have at least 2 fields for this unncessary
manipulation of sp to happen.
[Bug middle-end/116211] C Functions returning a struct always manipulate the stack pointer on RISC-V targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116211 --- Comment #2 from Guillaume --- Hi, thanks. Yes it looks like it, but I could not reproduce this exact problem with x86_64. Maybe present for other targets though.
[Bug middle-end/116211] C Functions returning a struct always manipulate the stack pointer on RISC-V targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116211 --- Comment #4 from Guillaume --- OK thanks!
[Bug modula2/109675] New: GCC 13.1: the Modula-2 front-end fails to build on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109675 Bug ID: 109675 Summary: GCC 13.1: the Modula-2 front-end fails to build on some platforms Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gr.audio at gmail dot com Target Milestone: --- Happens on any platform on which the 'long unsigned int' type can't hold a pointer (for instance: Windows/mingw64). The culprit is this: ../../gcc-13.1.0/gcc/m2/mc-boot/GDynamicStrings.cc: In function 'void writeAddress(void*)': ../../gcc-13.1.0/gcc/m2/mc-boot/GDynamicStrings.cc:909:18: error: cast from 'void*' to 'long unsigned int' loses precision [-fpermissive] 909 | writeLongcard ((long unsigned int ) (a)); | ^~~~ Casting a pointer to a 'long unsigned int' is not exactly portable.
