[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573 Tarik Ibrahimović changed: What|Removed |Added CC||tarik.ibrahimovic@chili-chi ||ps.xyz --- Comment #2 from Tarik Ibrahimović --- Created attachment 59675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59675&action=edit Preprocessed files concatenated
[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573 --- Comment #3 from Tarik Ibrahimović --- Created attachment 59676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59676&action=edit Disassembly of the program
[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573 --- Comment #4 from Tarik Ibrahimović --- Hi, I'm hereby providing a testcase for the reported bug. The bug is that there is a full-word misaligned store to address 0x1517 when compiler optimizations are used (-02 in specific). In case of no compiler optimizations there is no misalignment in memory accesses. Instruction causing the misaligned access is on address 0x42c in the provided disassembly file. Be careful, this instruction is first executed without making any misalignment exceptions, only the second time does it introduce a misalignment issue. Though this bug is not proved simulating the code in an ISS simulator, this behavior has been verified in two RISC-V CPUs. GCC Version details: Using built-in specs. COLLECT_GCC=riscv64-unknown-elf-gcc COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv64-unknown-elf/14.2.0/lto-wrapper Target: riscv64-unknown-elf Configured with: /home/tibrahimovic/0.git-repo/riscv-gnu-toolchain/gcc/configure --target=riscv64-unknown-elf --prefix=/opt/riscv --disable-shared --disable-threads --enable-languages=c,c++ --with-pkgversion=g04696df0963 --with-system-zlib --enable-tls --with-newlib --with-sysroot=/opt/riscv/riscv64-unknown-elf --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-tm-clone-registry --src=.././gcc --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-Os-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os -mcmodel=medlow' Thread model: single Supported LTO compression algorithms: zlib gcc version 14.2.0 (g04696df0963) Exact command run for compilation: riscv64-unknown-elf-gcc \ -DTCM=1 -DHARVARD=1 \ -march=rv32i \ -mabi=ilp32 \ -mstrict-align \ -mcmodel=medlow \ -Wl,--relax,-Bstatic,-T,$(SW_BLD)/main.lds,-Map,$(SW_BLD)/main.map \ \ -ffreestanding \ -fno-builtin \ -mrelax \ -fno-pic \ -nostdlib \ -static \ -Winline \ -Wno-implicit-int -Wno-implicit-function-declaration \ -g \ -fverbose-asm \ -o $(SW_BLD)/main.elf \ -O2 \ \ $(SW_SRC)/boot_crt.S \ $(SW_APP)/soc.c \ $(SW_APP)/memtest.c \ $(SW_APP)/uart.c \ $(SW_APP)/dac.c \ $(SW_APP)/adc.c \ $(SW_APP)/dhry.h \ $(SW_APP)/dhry_1.c $(SW_APP)/dhry_2.c -lgcc Due to the unawareness of where the bug begins, I'm concatenating all .i preprocessed files in one and presenting them here. I also included the disassembly which causes the error.
[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573 --- Comment #6 from Tarik Ibrahimović --- Does "corrupted" mean it got mixed up somewhere in the compiling process? I emphasize once again, that the generated code does not cause any misalignments when -O0 is used. One more thing which may be of importance is that CPU implementations which ignore the overflowing part of the misaligned memory access execute the code correctly.
[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573 --- Comment #7 from Tarik Ibrahimović --- Does "corrupted" mean it got mixed up somewhere in the compiling process? I emphasize once again, that the generated code does not cause any misalignments when -O0 is used. One more thing which may be of importance is that CPU implementations which ignore the overflowing part of the misaligned memory access execute the code correctly.
[Bug target/117573] RISC-V target -O2 generates Misaligned Access despite -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573 --- Comment #9 from Tarik Ibrahimović --- (In reply to Andrew Pinski from comment #8) > (In reply to Tarik Ibrahimović from comment #7) > > Does "corrupted" mean it got mixed up somewhere in the compiling process? I > > emphasize once again, that the generated code does not cause any > > misalignments when -O0 is used. > > You made mention that -O0 it works. And I looked at -O0 code generation and > there is a word store there still. > > This is why I said it looks like the value was corrupted somehow; I don't > think the bug is due to the access there but rather somewhere else the value > of Ptr_Val_Par->Ptr_Comp is changing to be incorrect. > > Since you are working on a simulator, have you looked at where the value of > Ptr_Val_Par->Ptr_Comp gets changed? Does it seem reasonible? > > > I know this is a long shot, does it work with a different version of GCC? > Like GCC 13.3.0? I did this first with GCC 10, then updated to the latest version, looking for a solution, so I tried it with different versions. The word store there should be there, but the address given to it never goes out of alignment. I am working on a RTL functional simulator simulating the hardware, and the hardware executes the instructions. I have no possibility of looking into the pointer modification you suggest, since the instructions are uploaded to the CPU as a binary and are then run, with no debugging possibility on the level of source code.
