Hello,
ARM support and R52 TRM have indicated that the R52 core requires maintaining an 8-byte aligned Stack (meaning compiler shall always push/pop registers in even numbers), and I see in my current setup the GNU GCC compiler is not adhering to that requirement. Subsequently in my core simulations I see R52 erroneous behavior if the stack is not maintained as such, especially if only a single register is pushed/popped for a function.
Am I missing some GNU GCC option to force 8-byte stack alignment? Also since ARM support stated this was a necessary requirement, shouldn't that be automatically implemented in the -mtune=cortex-r52 options?
My current setup is using ARM recommended version gcc-arm-none-eabi-9-2020-q2-update (according to the GNU toolchain developer website)
(I have also tested the version gcc-arm-none-eabi-10-2020-q2-preview, still seeing same problems)
My GCC command has the following options:
gcc-arm-none-eabi-10-2020-q2-preview/bin/arm-none-eabi-gcc -march=armv8-r -mfpu=neon-fp-armv8 -mtune=cortex-r52 -marm -c -g -O3 -fno-inline -fno-strict-aliasing -DGCC -falign-functions=16 -falign-jumps=8 -falign-loops=8 -fomit-frame-pointer -funroll-loops -mapcs-frame -DITERATIONS=20 -save-temps -DCR52 -Werror -Wall -Dcr52 -DCORE_0 -std=c99 -o alive_CORE_0.o -c alive.c
From above example, my compile results in the following odd-number of registers pushed onto stack: (see snippet from .lst file)
int main (void) { 2a980: e92dd810 push {r4, fp, ip, lr, pc} <<<=== ODD NUMBER OF REGISTER IN PUSH INSTRUCTION:
NOTE: the problem also occurs if I use -mthumb mode.
Other notes: I added the -fno-inline as according to an internal verification decision that we want to avoid the code in-lining optimization. Additionally I added the -mapcs-frame in an attempt to fix this issue, and this option seems to make the problem a lot better, but doesn't completely fix the problem.
Or is this a GNU GCC bug for the -mtune=cortex-r52 set of tuning options?
Thanks in advance for any help.