[Bug c/109055] New: Code generation error when function decorated for execution in SRAM

[Bug c/109055] New: Code generation error when function decorated for execution in SRAM

[cjmh.gt at gmail dot com]

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

            Bug ID: 109055
           Summary: Code generation error when function decorated for
                    execution in SRAM
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cjmh.gt at gmail dot com
  Target Milestone: ---

I have found an assembly code generation error that will be hard to reproduce
in the GCC 10. 2.1 arm-none-eabi compiler running on a Raspberry Pi 400 and
also the 12.2.0 arm-none-eabi compiler running on 64-bit x86 Windows 10
platform.

I’m developing C code using VS Code (on both platforms) for the RP2040 (Cortex
M0 dual core processor) using the Pico SDK.

The issue only seems to happen when the code is compiled to run in SRAM. The
Pico SDK defines a preprocessor macro function for compiling a C function for
execution out of SRAM instead of flash. For example:

int __not_in_flash_func(test)(int a) {}

expands to

int __attribute__((section(".time_critical." __STRING(test)))) test(int a) {}

On rare occasions, the compiler will not generate the assembly code correctly
even though it compiles without signaling any errors. Specific cases vary.
Often, when it happens, it will have a pointer in R3, then use R3 to do an
unrelated comparison for a branch operation (trashing the pointer in R3), then
use R3 as if it still had the pointer in R3 which usually results in a fault
during execution (thankfully). In other words, it neglects to reload R3 with
the pointer before using it.

The frustrating part of this is that I end up altering the code to track down
why the compiler is generating bad code and the problem resolves itself. I can
look at the generated code while debugging and now it correctly reloads R3 with
the pointer as it should.

At first, I though I must be mistaken somehow. But in subsequent times this has
happened I tried to be very careful in how I changed the code when tracking it
down. The most recent example of this issue is as follows:

typedef struct packet_hdr {
    unsigned pcnt:8;
    unsigned pdecript:4;
    unsigned immead:1;
    unsigned dst_type:9;
    unsigned src:9;
    unsigned bcast:1;
} packet_hdr_t;

typedef struct packet_buffer {
    packet_hdr_t header;
    uint32_t        data[MAX_PACKET_LEN];
} packet_buffer_t;
packet_buffer_t tx_buffer[3];

void __not_in_flash_func(processPackets)(void) {
 :
 : 

        int j;
        for (j=0; j<2; j++) {
            if (++packetLen > MAX_PACKET_LEN) {
                packetLen = 0;
            }
            if (packetLen == 0) {
                tx_buffer[j].header.immead = true;
            } else {
                tx_buffer[j].header.pcnt = packetLen;
                tx_buffer[j].header.immead = false;
            }
            dma_tx_queue(&(DmaTx[j]), &(tx_buffer[j]), 0, packetLen+1);
        }

Both the code snippet and the called function “dma_tx_queue” are decorated for
execution in SRAM.

The issue is that the compiler did not calculate the address of &(tx_buffer[j])
properly and instead passed a bogus pointer into dma_tx_queue. All the rest of
the function variables were calculated correctly.

I cleaned and rebuilding the project with the same result. Then I changed the
code to look like this:

            packet_buffer_t *pSrc = &(tx_buffer[j]); <------- pre-computed the
source
            dma_tx_queue(&(DmaTx[j]), pSrc, 0, packetLen+1);

Recompiled and it worked correctly. Then I changed it back to the way it was to
start with and recompiled it and still worked correctly. I was very careful to
not do anything else that might have effected the outcome of the compilation.

I have tried to make a simple example to reproduce the problem, but it does not
happen with any reliability. And when it does, modifying the code slightly
fixes the problem somehow. Then putting the code back the way it was does not
reproduce the error in generating the assembly code. I can do a clean and
rebuild and the code is still generates correctly. To say this issue, when it
happens on rare occasions, is frustrating is an understatement.

And the issue has happened on both platforms so it is not platform dependent.

Windows GCC:
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --buil
d=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-head
er-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap
--enable-checking=release --wit
h-arch=nocona --with-tune=generic
--enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable
-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-d
ynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --ena
ble-lto --enable-libgomp --disable-multilib --disable-rpath
--disable-win32-registry --disable-nls -
-disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/mingw64 --with-mpfr
=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev7,
Built by MSYS2 project' -
-with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-li
bstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Rev7, Built by MSYS2 project)

RPI400 GCC:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 10.2.1-6+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard
--disable-werror --enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Raspbian 10.2.1-6+rpi1)

[Bug target/109055] Code generation error when function decorated for execution in SRAM

[cjmh.gt at gmail dot com]

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

--- Comment #1 from Chris Hodges <cjmh.gt at gmail dot com> ---
I listed the compiler for the native GCC instead of

arm-none-eabi-gcc -v

The RPI400 compiiler for the Cortex M0 is 8.3.1

RPI400:
arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/8.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --build=arm-linux-gnueabihf --prefix=/usr
--includedir='/usr/lib/include' --mandir='/usr/lib/share/man'
--infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/lib/arm-linux-gnueabihf'
--libexecdir='/usr/lib/lib/arm-linux-gnueabihf' --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man
--enable-languages=c,c++,lto --enable-multilib --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --enable-tls --build=arm-linux-gnueabihf
--target=arm-none-eabi --with-system-zlib --with-gnu-as --with-gnu-ld
--with-pkgversion=15:8-2019-q3-1+b1 --without-included-gettext
--prefix=/usr/lib --infodir=/usr/share/doc/gcc-arm-none-eabi/info
--htmldir=/usr/share/doc/gcc-arm-none-eabi/html
--pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3
--host=arm-linux-gnueabihf --with-headers=no --without-newlib
--with-multilib-list=rmprofile CFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2'
CXXFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' FCFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' FFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' GCJFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' LDFLAGS=-Wl,-z,relro OBJCFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' OBJCXXFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-arm-none-eabi-3BFy9A/gcc-arm-none-eabi-8-2019-q3=.
-fstack-protector-strong' INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0
AR_FOR_TARGET=arm-none-eabi-ar AS_FOR_TARGET=arm-none-eabi-as
LD_FOR_TARGET=arm-none-eabi-ld NM_FOR_TARGET=arm-none-eabi-nm
OBJDUMP_FOR_TARGET=arm-none-eabi-objdump RANLIB_FOR_TARGET=arm-none-eabi-ranlib
READELF_FOR_TARGET=arm-none-eabi-readelf STRIP_FOR_TARGET=arm-none-eabi-strip
Thread model: single
gcc version 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
(15:8-2019-q3-1+b1) 


Windows10:
 arm-none-eabi-gcc.exe -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\arm-none-eabi-gcc.exe
COLLECT_LTO_WRAPPER=c:/msys64/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/lto-wrapper.exe
Target: arm-none-eabi
Configured with: ../configure --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --prefix=/mingw64
 --target=arm-none-eabi --with-native-system-header-dir=/mingw64/include
--libexecdir=/mingw64/lib -
-enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --
disable-shared --disable-threads --disable-tls --disable-libada --with-gnu-as
--with-gnu-ld --with-s
ystem-zlib --with-newlib --with-headers=/mingw64/arm-none-eabi/include
--with-python-dir=share/gcc-a
rm-none-eabi --with-gmp --with-mpfr --with-mpc --with-isl --with-libelf
--enable-gnu-indirect_functi
on --with-multilib-list=rmprofile --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdyna
mic -lm' --enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\
-static-libgcc\ -pipe\ -Wl,--stack
,12582912' LDFLAGS='-pipe -Wl,--disable-dynamicbase'
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)