Missing compiler options and output binary discrepancy

[KMcle.2]

I noticed some descrpancy between the output binary from CubeIDE build and the VS Code build. While investigating this I noticed that there was some missing compiler options in the cmake file. The options missing are -fno-strict-aliasing from GCC compiler optimization settings, -mthumb, -fstack-usage, and -c. 

The flags and options in the cmake output files are,

After rectifying the missing complier flags, I still notice that the output binary between VS Code and Cube IDE still do not match. At this point, I'm not sure where the discrepancy is coming through. I have check that the same tool chain is being invoked in both scenarios, and have checked GG_COLLECT_OPTIONS for any discrepancies.

-----------------------------------------------------------------------------------------------------

Toolchain VS Code: "C:/ST/STM32CubeIDE_1.10.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127/tools/bin"

Toolchain CubeIDE:

Options for the c compiler in CubeIDE:

-mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F413xx -DDEBUG -c -I../Inc -I../Drivers/CMSIS/Include -I../Drivers/STM32F4xx_HAL_Driver/Inc -I../Drivers/CMSIS/Device/ST/STM32F4xx/Include -I../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy -I../rs1_drivers/inc -Ofast -ffunction-sections -fdata-sections -fno-strict-aliasing -Wall -fcommon -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb

[Paolo ALBERELLI_O]

At identical flags the produced binaries should differ only because of the link order.

CubeIDE's objects.list order is not identical to VS Code's st-project.cmake .

If you manually reorder the latter according for the former you should get the exact same binary.

I did try this a while back confirming the observation, but I haven't retried it recently.

I believe VS Code's importer strictly follows the .cproject order while CubeIDE sorts the source tree in a slightly different way.

Is it a strong requirement to have the exact same binary ?

If so, is manual rearrangement of st-project.cmake a suitable workaround ?