Bug in the latest STM32CubeIDE relating to the compilation of release code using the Ofast optimisation

[Robmar]

Looks like we've come across a bug in the latest STM32CubeIDE relating to the compilation of release code using the Ofast optimisation.

Recompiling using anything else, including O3 "Most optimized" does not cause this failure.

I've copied below the code details; 32F407VG on Discovery board.

BR

Rob

**** O3fast optimisation: sampleRateDecim passed in == 12000

a_buffer passed in is in CCM RAM, this is it´s structure definition:-

typedef float32_t audio_block_t[AUDIO_BLOCK_SIZE];

typedef struct

{

   // Stereo buffers

   iq_buffer_t    iq_buf;

   float32_t      agc_valbuf[IQ_BLOCK_SIZE];

   audio_block_t  a_buffer[2];

   demod_sam_param_t sam;

   iq_correction_data_t iq_corr;

} AudioDriverBuffer;

AudioDriverBuffer section (".ccm") adb;

static void DemodPostprocessing(float32_t (*a_buffer)[AUDIO_BLOCK_SIZE], const size_t blockSize, const size_t blockSizeDecim, const uint32_t sampleRateDecim)

{

   const uint8_t dspActive = ts.dsp.active;

   const uint8_t dmodMode = ts.dmodMode;

   if (!dsp.inhibit)   // dsp.inhibit == 0

   {

       if ((dspActive & DNOTCH_ENABLE) && (dmodMode != DEMOD_CW) && !((dmodMode == DEMOD_SAM) && (sampleRateDecim == 24000)))

       {

           *** Note: not called as sampleRateDecim == 24000 is false

         NotchFilter(blockSizeDecim, a_buffer[0]);    // Do notch filter

       }

   }

   *** FAIL: sampleRateDecim, marked const, is no longer == 12000, changes to something like1958 !!!

[waclawek.jan]

>  *** FAIL: sampleRateDecim, marked const, is no longer == 12000, changes to something like1958 !!!

How do you know?

JW

[Robmar]

We printed the value from release code to the attached LCD, we also had it debugging with Ofast optimization.

[Piranha]

Ofast is like O3+. As for the issue, it could be caused by stack overflow.

[Robmar]

Yes, it could, but I verified stack usage, even wrote a pattern across stack memory to visually verify it, I even increased the stack by 4x to 20 KB, so it's not the stack.

[Bob S]

You don't show what code comes after the line marked "FAIL". Could it be that the compiler is putting sampleRateDecim into a register, and that this variable is not used after that "IF" statement, which means the compiler now uses that register for some other use?

If your code DOES use sampleRateDecim after that line, then indeed that is (probably) a bug.

[Robmar]

Unfortunately no, when sampleRateDecim isn't 12000 the routine simply returns false, causing the application to be unable to process audio. I suspect there are other failures because not even the screen activates.

We've tested this repeatedly and the results are always the same when compiling with Ofast. All other compile optimizations work. It wouldn't be the first time G++ had a bug in the optimization, maybe it only happens in our particular configuaration.

I guess it will need the asm output checking to see if the fail really is the compiler.