[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #9 from Xi Ruoyao --- .
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #8 from Nikos Tosis --- We found the problem, the bug was in Embedded Ecoder from Mathworks. So the Coder has generated wrong C Code. Thank you all.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #7 from Nikos Tosis --- thank you for the info, I will try tomorrow to see if I made a mistake in simulink or its a bug from simulink.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #6 from Andrew Pinski --- >The address 2001 1548 exist not in my map file as variable. It is a stack address. Since UnitDelay_DSTATE is defined on the stack. Comment #2 applies here. The code that GCC compiles seems to be corresponding to the assembly code that GCC is producing too. rtu_AngleMecIn will contain the address of UnitDelay_DSTATE which is a variable on stack inside MotorControlLib_step .
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #5 from Nikos Tosis --- Hi, I opened this bug report in January and until today I didn't see any reaction. do you need more information about the bug or has been fixed?
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #4 from Nikos Tosis --- (In reply to Andrew Pinski from comment #1) > What is the command line you are using to compile the sources? > > Does -fno-strict-aliasing help? > Does it work at -O0? I use -mcpu=cortex-m4 -std=gnu11 -g -DDEBUG -DUSE_HAL_DRIVER -DSTM32F446xx -Og -ffunction-sections -fdata-sections -Wall -Wextra -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -save-temps -ffile-prefix-map=/home/runner/work/Nyx_Simulink/Nyx_Simulink/Code=. (In reply to Andrew Pinski from comment #1) > What is the command line you are using to compile the sources? > > Does -fno-strict-aliasing help? > Does it work at -O0? I think your suggestion is not working, the assembly code is different but still a wrong address.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #3 from Nikos Tosis --- (In reply to Christophe Lyon from comment #2) > I may be reading the code incorrectly, but ISTM that rtu_AngleMecIn is the > 3rd parameter of the function, so you pass _DSTATE, > while you pass _MechanicalAngle as 5th parameter. > > So it's normal that (*rtu_AngleMecIn) and (Sig_MechanicalAngle) have > different values. This is the declaration void ConvertPWMtoAngle(const int16_T *rtu_qSollin, const boolean_T *rtu_detectStartUpin, const real32_T *rtu_AngleMecIn, real32_T *rty_AngleElec, real32_T *rty_AnlgleMec) and this is the call ConvertPWMtoAngle(, _UnitDelay_n, _DSTATE, _AngleCalculation_o1, _MechanicalAngle); qSoll = 1 rtb_UnitDelay_n = 2 UnitDelay_DSTATE = 3 rtb_AngleCalculation_o1 = 4 Sig_MechanicalAngle = 5 The code is auto genenated from Matlab but I see that everything is ok.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- I may be reading the code incorrectly, but ISTM that rtu_AngleMecIn is the 3rd parameter of the function, so you pass _DSTATE, while you pass _MechanicalAngle as 5th parameter. So it's normal that (*rtu_AngleMecIn) and (Sig_MechanicalAngle) have different values.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-27 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- What is the command line you are using to compile the sources? Does -fno-strict-aliasing help? Does it work at -O0?
