https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573
--- Comment #9 from Tarik Ibrahimović <tarik.ibrahimo...@chili-chips.xyz> --- (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.
