public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/108575] New: Bug in gcc arm non eabi
@ 2023-01-27 18:07 ergasies.uni at gmail dot com
2023-01-27 18:13 ` [Bug target/108575] " pinskia at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: ergasies.uni at gmail dot com @ 2023-01-27 18:07 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
@ 2023-01-27 18:13 ` pinskia at gcc dot gnu.org
2023-01-27 18:39 ` clyon at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-27 18:13 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
2023-01-27 18:13 ` [Bug target/108575] " pinskia at gcc dot gnu.org
@ 2023-01-27 18:39 ` clyon at gcc dot gnu.org
2023-01-27 20:59 ` ergasies.uni at gmail dot com
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: clyon at gcc dot gnu.org @ 2023-01-27 18:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
2023-01-27 18:13 ` [Bug target/108575] " pinskia at gcc dot gnu.org
2023-01-27 18:39 ` clyon at gcc dot gnu.org
@ 2023-01-27 20:59 ` ergasies.uni at gmail dot com
2023-01-27 21:13 ` ergasies.uni at gmail dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ergasies.uni at gmail dot com @ 2023-01-27 20:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
` (2 preceding siblings ...)
2023-01-27 20:59 ` ergasies.uni at gmail dot com
@ 2023-01-27 21:13 ` ergasies.uni at gmail dot com
2023-07-09 19:37 ` ergasies.uni at gmail dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ergasies.uni at gmail dot com @ 2023-01-27 21:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
` (3 preceding siblings ...)
2023-01-27 21:13 ` ergasies.uni at gmail dot com
@ 2023-07-09 19:37 ` ergasies.uni at gmail dot com
2023-07-09 20:41 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ergasies.uni at gmail dot com @ 2023-07-09 19:37 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
` (4 preceding siblings ...)
2023-07-09 19:37 ` ergasies.uni at gmail dot com
@ 2023-07-09 20:41 ` pinskia at gcc dot gnu.org
2023-07-09 21:13 ` ergasies.uni at gmail dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-09 20:41 UTC (permalink / raw)
To: gcc-bugs
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 .
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
` (5 preceding siblings ...)
2023-07-09 20:41 ` pinskia at gcc dot gnu.org
@ 2023-07-09 21:13 ` ergasies.uni at gmail dot com
2023-09-24 12:22 ` ergasies.uni at gmail dot com
2023-09-24 13:45 ` xry111 at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: ergasies.uni at gmail dot com @ 2023-07-09 21:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
` (6 preceding siblings ...)
2023-07-09 21:13 ` ergasies.uni at gmail dot com
@ 2023-09-24 12:22 ` ergasies.uni at gmail dot com
2023-09-24 13:45 ` xry111 at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: ergasies.uni at gmail dot com @ 2023-09-24 12:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/108575] Bug in gcc arm non eabi
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
` (7 preceding siblings ...)
2023-09-24 12:22 ` ergasies.uni at gmail dot com
@ 2023-09-24 13:45 ` xry111 at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-24 13:45 UTC (permalink / raw)
To: gcc-bugs
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> ---
.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-09-24 13:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-27 18:07 [Bug c/108575] New: Bug in gcc arm non eabi ergasies.uni at gmail dot com
2023-01-27 18:13 ` [Bug target/108575] " pinskia at gcc dot gnu.org
2023-01-27 18:39 ` clyon at gcc dot gnu.org
2023-01-27 20:59 ` ergasies.uni at gmail dot com
2023-01-27 21:13 ` ergasies.uni at gmail dot com
2023-07-09 19:37 ` ergasies.uni at gmail dot com
2023-07-09 20:41 ` pinskia at gcc dot gnu.org
2023-07-09 21:13 ` ergasies.uni at gmail dot com
2023-09-24 12:22 ` ergasies.uni at gmail dot com
2023-09-24 13:45 ` xry111 at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).