STM32U5xx HAL Won't Build With arm-none-eabi-gcc 14.2. Toolchain

[lgacnik97]

As the title suggest, non-STM32CubeIDE build setup won't compile successfully with arm-none-eabi-gcc version 14.2 (the latest from ARM) while the same setup compilation is successful with 12.3. version (also supported in STM32CubeIDE). The problem is the inclusion of <math> standard library in the following files: "system_stm32u5xx.c" and "stm32u5xx_hal_def.h" files (I assume same goes for other MCUs).

This is merely a suggestion to HAL support team to make HAL more compliant with newer ARM GCC versions rather than a bug. The only thing these two math-dependent files actually use is the definition of float_t and double_t. The actual code that appears useful to the HAL files I'm using is the one below (which could be made available by one of generic HAL headers):

#if defined FLT_EVAL_METHOD
/* FLT_EVAL_METHOD == 16 has meaning as defined in ISO/IEC TS 18661-3,
 * which provides non-compliant extensions to C and POSIX (by adding
 * additional positive values for FLT_EVAL_METHOD).  It effectively has
 * same meaning as the C99 and C11 definitions for value 0, while also
 * serving as a flag that the _Float16 (float16_t) type exists.
 *
 * FLT_EVAL_METHOD could be any number of bits of supported floating point
 * format (e.g. 32, 64, 128), but currently only AArch64 and few other targets
 * might define that as 16.  */
  #if (FLT_EVAL_METHOD == 0) \
      || (FLT_EVAL_METHOD == 16)
    typedef float  float_t;
    typedef double double_t;
   #elif FLT_EVAL_METHOD == 1
    typedef double float_t;
    typedef double double_t;
   #elif FLT_EVAL_METHOD == 2
    typedef long double float_t;
    typedef long double double_t;
   #else
    /* Implementation-defined.  Assume float_t and double_t have been
     * defined previously for this configuration (e.g. config.h). */

   /* If __DOUBLE_TYPE is defined (__FLOAT_TYPE is then supposed to be
      defined as well) float_t and double_t definition is suggested by
      an arch specific header.  */
   #ifdef __DOUBLE_TYPE
    typedef __DOUBLE_TYPE double_t;
    typedef __FLOAT_TYPE float_t;
   #endif
   /* Assume config.h has provided these types.  */
  #endif
#else
    /* Assume basic definitions.  */
    typedef float  float_t;
    typedef double double_t;
#endif

The newer GCC versions suggests <math> should be optional to non-hosted code. Also, newer GCC versions delve deeper into what dependencies of freestanding C/C++ implementation are made available (per my understanding). 

My resolution of such problem is no other than remove the two inclusions of <math> library, delivered with the toolchain, from HAL files and globally defining float_t and double_t. However, this is not maintainable and leads to frustrations and such. Therefore, if HAL team would find out, upon inspection, that HAL can truly do without this dependency directly, this would most certainly be a relief.

If anyone else has an idea how to resolve such an issue without manually removing <math> after each code re-generation from CubeMX, I would love to hear your opinion.