From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7C29F3858C30; Tue, 7 Mar 2023 16:06:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C29F3858C30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678205163; bh=08aHeeqMhHKerZ8Mqd+Scziifw/pCnqwlRBBEy0Evnc=; h=From:To:Subject:Date:From; b=G0PMlG6t4KFWaTuIXxhj7ncqJMJDapKgT9dUpV1YCyBTxuO8zWXZSLkaK1v1CA9Px B+KNOvpopJJnMBiVxEYOjzj1HnIOrsvDE7eEAo09GCHvYEHMjZ6GGRpHBlsc7I7+cn mpPbSwsm833xXutT1d5NT2Cxj2npxDSBRCGumvT8= From: "cjmh.gt at gmail dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cjmh.gt at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109055 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 reprodu= ce 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=E2=80=99m developing C code using VS Code (on both platforms) for the RP2= 040 (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 f= or 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 correct= ly 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), t= hen 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 do= wn 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 { =C2=A0 =C2=A0 packet_hdr_t header; =C2=A0 =C2=A0 uint32_t =C2=A0 =C2=A0 =C2=A0 =C2=A0data[MAX_PACKET_LEN]; } packet_buffer_t; packet_buffer_t tx_buffer[3]; void __not_in_flash_func(processPackets)(void) { : :=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int j; =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (j=3D0; j<2; j++) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (++packetLen > MAX_PACKET_LEN)= { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packetLen =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (packetLen =3D=3D 0) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tx_buffer[j].header= .immead =3D true; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } else { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tx_buffer[j].header= .pcnt =3D packetLen; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tx_buffer[j].header= .immead =3D false; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dma_tx_queue(&(DmaTx[j]), &(tx_bu= ffer[j]), 0, packetLen+1); =C2=A0 =C2=A0 =C2=A0 =C2=A0 } Both the code snippet and the called function =E2=80=9Cdma_tx_queue=E2=80= =9D 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 t= he code to look like this: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 packet_buffer_t *pSrc =3D &(tx_bu= ffer[j]); <------- pre-computed the source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dma_tx_queue(&(DmaTx[j]), pSrc, 0= , packetLen+1); Recompiled and it worked correctly. Then I changed it back to the way it wa= s 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 compilatio= n. 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 n= ot 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 dependen= t. Windows GCC: $ gcc -v Using built-in specs. COLLECT_GCC=3DC:\msys64\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=3DC:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/1= 2.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-12.2.0/configure --prefix=3D/mingw64 --with-local-prefix=3D/mingw64/local --buil d=3Dx86_64-w64-mingw32 --host=3Dx86_64-w64-mingw32 --target=3Dx86_64-w64-mi= ngw32 --with-native-system-head er-dir=3D/mingw64/include --libexecdir=3D/mingw64/lib --enable-bootstrap --enable-checking=3Drelease --wit h-arch=3Dnocona --with-tune=3Dgeneric --enable-languages=3Dc,lto,c++,fortran,ada,objc,obj-c++,jit --enable -shared --enable-static --enable-libatomic --enable-threads=3Dposix --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=3D/mingw64 --with-mpfr =3D/mingw64 --with-mpc=3D/mingw64 --with-isl=3D/mingw64 --with-pkgversion= =3D'Rev7, Built by MSYS2 project' - -with-bugurl=3Dhttps://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-li bstdcxx-debug --with-boot-ldflags=3D-static-libstdc++ --with-stage1-ldflags=3D-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=3Dgcc COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion=3D'Raspbian 10.2.1-6= +rpi1' --with-bugurl=3Dfile:///usr/share/doc/gcc-10/README.Bugs --enable-languages=3Dc,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=3D/usr --with-gcc-major-version-only --program-suffix=3D-10 --program-prefix=3Darm-linux-gnueabihf- --enable-shared --enable-linker-bui= ld-id --libexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dposix --libdir=3D/usr/lib --enable-nls --enable-bootstrap --enable-clocale=3Dgnu --enable-libstdcxx-debug --enable-libstdcxx-time=3Dyes --with-default-libstdcxx-abi=3Dnew --enable-gnu-unique-object --disable-lib= itm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=3Drelease --with-target-system-zlib=3Dauto --enable-objc-gc=3Dauto --enable-multiarch --disable-sjlj-exceptions --with-arch=3Darmv6 --with-fpu=3Dvfp --with-float= =3Dhard --disable-werror --enable-checking=3Drelease --build=3Darm-linux-gnueabihf --host=3Darm-linux-gnueabihf --target=3Darm-linux-gnueabihf Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Raspbian 10.2.1-6+rpi1)=