[Bug c/108575] New: Bug in gcc arm non eabi

[Bug c/108575] New: Bug in gcc arm non eabi

[ergasies.uni at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

            Bug ID: 108575
           Summary: Bug in gcc arm non eabi
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ergasies.uni at gmail dot com
  Target Milestone: ---

Created attachment 54363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54363&action=edit
i files and some screenshots.

Hi,

I use the gcc-arm-none-eabi-10.3-2021.10 version. I working on Fedora 29. 

My C Code is auto-generated from Simulink.
The following code is the function call. 
    /* ModelReference: '<Root>/AngleCalculation' incorporates:
     *  DataStoreRead: '<Root>/Data Store Read'
     *  Inport: '<Root>/Input'
     *  Inport: '<Root>/Input1'
     *  UnitDelay: '<Root>/Unit Delay'
     */
    ConvertPWMtoAngle(&qSoll, &rtb_UnitDelay_n, &UnitDelay_DSTATE,
                      &rtb_AngleCalculation_o1, &Sig_MechanicalAngle);

and this is the declaration of the function. 

/* Output and update for referenced model: 'ConvertPWMtoAngle' */
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)

The global variable Sig_MechanicalAngle according to map file has the address
0x0000000020004c94. 

In the function ConvertPWMtoAngle the implementation looks like this: 

continuesAngle = (degresProCounter * (real32_T)rtb_Switch_d) +
(*rtu_AngleMecIn); 

and the assembly looks like this: 

 0800837C   4B14        LDR            R3, =EncoderCounter           ; [PC,
#80] [0x080083D0] =0x20000224
     0800837E   881B        LDRH           R3, [R3]
     08008380   4A0E        LDR            R2, =ConvertPWMtoAngle_DW     ; [PC,
#56] [0x080083BC] =0x20004CF0
     08008382   8912        LDRH           R2, [R2, #8]
     08008384   1A9B        SUBS           R3, R3, R2
     08008386   B21B        SXTH           R3, R3
     08008388   EE07 3A90   VMOV           S15, R3
     0800838C   EEF8 7AE7   VCVT.F32.S32   S15, S15
     08008390   4B15        LDR            R3, =degresProCounter         ; [PC,
#84] [0x080083E8] =0x080102E0
     08008392   ED93 7A00   VLDR           S14, [R3]
     08008396   EE67 7A87   VMUL.F32       S15, S15, S14
     0800839A   ED96 7A00   VLDR           S14, [R6]
     0800839E   EE77 7A87   VADD.F32       S15, S15, S14
     080083A2   4B12        LDR            R3, =continuesAngle           ; [PC,
#72] [0x080083EC] =0x20004D0C
     080083A4   EDC3 7A00   VSTR           S15, [R3]
     080083A8   E7CC        B              0x08008344                    ;
<ConvertPWMtoAngle>+0x11C

in line 0800839A   ED96 7A00   VLDR           S14, [R6] 
the controller loads from the memory address in R6 the value in S14. 
But when I check the register R6 Value the has the address value 2001 1548 and
this is not the correct address, this is not the address from variable
Sig_MechanicalAngle. And always the Register S14 has the value 0. The address
2001 1548 exist not in my map file as variable. 

This is the map entry in this address area: 
               0x0000000020011394                testTask500msHandle
                0x0000000020011398                ComputationINTBuffer
                0x0000000020011598                testTask500msBuffer
 COMMON         0x0000000020011d98       0x2c ./Core/Src/main.o
                0x0000000020011d98                ClockInfos
                0x0000000020011dac                adcBuffer

I changed my implementation to continuesAngle = (degresProCounter *
(real32_T)rtb_Switch_d) +
(Sig_MechanicalAngle); and the software is working properly. 

I checked also my stack and i did not find a stack overflow. 

That means when I use a pointer I have a big trouble and when I use the object
of the variable then everything is ok. 

Could you help me and see if is it a bug?

[Bug target/108575] Bug in gcc arm non eabi

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-01-27
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What is the command line you are using to compile the sources?

Does -fno-strict-aliasing help?
Does it work at -O0?

[Bug target/108575] Bug in gcc arm non eabi

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I may be reading the code incorrectly, but ISTM that rtu_AngleMecIn is the 3rd
parameter of the function, so you pass &UnitDelay_DSTATE,
while you pass &Sig_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

[ergasies.uni at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

--- Comment #3 from Nikos Tosis <ergasies.uni at gmail dot com> ---
(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 &UnitDelay_DSTATE,
> while you pass &Sig_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(&qSoll, &rtb_UnitDelay_n, &UnitDelay_DSTATE,
                      &rtb_AngleCalculation_o1, &Sig_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

[ergasies.uni at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

--- Comment #4 from Nikos Tosis <ergasies.uni at gmail dot com> ---
(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

[ergasies.uni at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

--- Comment #5 from Nikos Tosis <ergasies.uni at gmail dot com> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>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

[ergasies.uni at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

--- Comment #7 from Nikos Tosis <ergasies.uni at gmail dot com> ---
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

[ergasies.uni at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

--- Comment #8 from Nikos Tosis <ergasies.uni at gmail dot com> ---
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

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
.