[Bug c++/101649] New: -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles

2021-07-27 Thread make_all--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101649 Bug ID: 101649 Summary: -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles Product: gcc Version: 11.1.0 Status: UNCONFI

[Bug c++/101649] -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles

2021-07-27 Thread make_all--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101649 --- Comment #2 from make_...@t-online.de --- I don't want to avoid double promotion as double promotion is not actually happening. I want to not be bothered by a false warning :)

[Bug c++/101649] -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles

2021-07-27 Thread make_all--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101649 --- Comment #4 from South Window --- For the user of GCC it doesn't matter whether GCC at compile times converts the literal to a double, and then notices that 32 bits of are zero, and uses a float instead, or if GCC knows right away that 0.5 (a

[Bug c++/101649] -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles

2021-08-02 Thread make_all--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101649 --- Comment #6 from South Window --- Not doing this optimization in -O0 would still leave this warning wrong when optimization is turned on. In my view, the fundamental difference between a generic linter and compiler warnings is that the compil

[Bug c++/101649] -Wdouble-promotion warning emitted when floating point literals are not actually promoted to doubles

2021-08-02 Thread make_all--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101649 --- Comment #7 from South Window --- Since the code generation seems to always reduce a double literal to a floating point in the cases this discussed here, could the function that throws this warning be extended to not throw the warning if all