-fsingle-precision-constant breaks C++ standard library Topic is solved

[Spym]

This post is about GCC and C++.

The flag -fsingle-precision-constant is harmful and should be removed from the default build configuration.

1. Its use is incompatible with the C++ standard library shipped with GCC (fails to compile).
2. The application may still need to perform double-precision arithmetic even though it will be emulated in software (my application needs that).

If not removed completely, this flag should be made optional or disableable at the very least.

[Giovanni]

The problem is that the option is needed when the FPU is only able to handle single precision floats as far I know.

I will search more info.

Edit: It is explained here: https://www.embeddedrelated.com/showthr ... 6863-1.php

I will look into making it optional.

Giovanni

[Spym]

The problem is that the option is needed when the FPU is only able to handle single precision floats as far I know.

No, it's not true, it's easy to check by disabling the option (it is disabled in my application) and checking the compiled code (it still uses the FPU for floating-point arithmetics). The only practical effect of this option (according to the documentation https://gcc.gnu.org/wiki/FloatingPointMath) is that the compiler will treat double-precision literals as single-precision literals. This is exactly the behavior that breaks the standard library.

From the documentation:

-fsingle-precision-constant causes floating-point constants to be loaded in single precision even when this is not exact. This avoids promoting operations on single precision variables to double precision like in x + 1.0/3.0. Note that this also uses single precision constants in operations on double precision variables. This can improve performance due to less memory traffic.

[Giovanni]

Improving performance is exactly the point, this is why it is there, in order to avoid unnecessary conversions.

Giovanni

[Spym]

Improving performance is great only as long as you don't break valid code

The developer can always achieve identical results by using the single-precision suffix "F", e.g. "3.14F". All high-integrity coding standards I know (MISRA, HIC++) require this anyway, in order to avoid unintended implicit type conversions.

[faisal]

I also think it should be defined by the user.

Fyi, some stm32f7s and the H7 I believe have hardware double float support... so there's that.

[Spym]

Fyi, some stm32f7s and the H7 I believe have hardware double float support... so there's that.

This is correct. Cortex M7 implemented in upper STM32's supports hardware double precision floating point arighmetic.

[Giovanni]

It has been removed from trunk and 18.2.x, anyway, you could have overridden it by using USE_FPU_OPT in you makefile. Demos for micros with double precision FPU did that already.

Giovanni