public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cjmh.gt at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/109055] New: Code generation error when function decorated for execution in SRAM Date: Tue, 07 Mar 2023 16:06:02 +0000 [thread overview] Message-ID: <bug-109055-4@http.gcc.gnu.org/bugzilla/> (raw) 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)
next reply other threads:[~2023-03-07 16:06 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-07 16:06 cjmh.gt at gmail dot com [this message] 2023-03-07 17:40 ` [Bug target/109055] " cjmh.gt at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-109055-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).