F4 loops bug in O3, runs fine with O2

[Romain1]

Hi, I'm having the weirdest bug with this code. It's just 2 for loops expecting to count from 0 to 5 and 0 to 8.

When compiling with O3, i becomes very high and the execution gets stuck in the loops.

 

Running STM32 Cube IDE 1.9.0

STM32Cube FW_F4 V1.27.0

com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127/tools/bin/../lib/gcc/arm-none-eabi/10.3.1

[Romain1]

By the way, the loops use constants:

#define nbOutputRows 8

#define nbOutputGroups 5

[TDK]

It could be that i has been optimized out and the debugger doesn't monitor it correctly. I would imagine the access to outputs[] to cause a hard fault if i is absurdly high.

[KnarfB]

Enable at least minimal debug level (-g1) in the C/C++ Build Settings for the Release Config to get plausible values for local variables. It also makes sense to debug step-by-step, if possible at instruction level, to understand what's happening.

Make sure that the function calls have a side effect (like assigning to a volatile variable) and are not optimized out.

Comment out parts of your code ("bisecting") and observe changes.

Doubt that you caught a compiler bug.

hth

KnarfB

[Romain1]

When I comment out line 110 it does say that "i" is optimized out and the infinite loop goes away.

[waclawek.jan]

Post sources of functions you use there, and disasm.

JW

[RFont]

The main difference between O2 and O3 seems to be the loop unrolling.

The function calls do have a side effect as it is setting a pin high or low in the loops:

if (gpioStatus)
  gpioSet(COOUT);		// Set
else
  gpioReset(COOUT);	// Reset

Changing the type of the table output[] to volatile fixed the issue in O3, the code no longer hangs and the loop counters work as expected (even though they struggle to show properly in the Expressions view).

I have attached the source file and the disasm compiled with O3.

[RFont]

disasm file.