[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: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: make_...@t-online.de
  Target Milestone: ---

GCC emits a double promotion warning when using the literal 0.5 with a float.
For example

float func(float num) {
return num * 0.5;
}

warning: implicit conversion from 'float' to 'double' to match other operand of
binary expression [-Wdouble-promotion]
3 | return num * 0.5;

However, GCC does not actually use the double representation for this literal
(and others than can be represented equally in float as in double).
The assembler output for both "0.5" and "0.5f" is the same:

func(float):
pushrbp
mov rbp, rsp
movss   DWORD PTR [rbp-4], xmm0
movss   xmm1, DWORD PTR [rbp-4]
movss   xmm0, DWORD PTR .LC0[rip]
mulss   xmm0, xmm1
pop rbp
ret
.LC0:
.long   1056964608

This warning is misleading and should not be emitted

[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 (and others) don't need to
be promoted.

Promoting first and then completely undoing the promotion is a purely internal
process, effectively a null operation that is of no interest of the user of the
compiler.

One of the most relevant scopes for -Wdouble-promotion is probably optimization
(in particular for SIMD), where the unintended use of a double would cause a
significant performance hit. 
But if the compiler is smart enough and is not using doubles and double
instructions, and no precision is changed anywhere in the process, it should be
smart enough to not through a this warning.

[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 compiler warning should
reflect what the compiler is really doing.

If it is not easy to not emit this warning, could it be possible to undo this
warning from "elsewhere", or at least to accompany this warning with a
withdrawal, e.g.


warning: implicit conversion from 'float' to 'double' to match other operand of
binary expression [-Wdouble-promotion]
warning withdrawn: literal '0.5' can be represented without loss of precision
as 'float'. Therefore, 'float' precision is used instead of 'double'.
[-Wdouble-promotion]

[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 32 least significant bits
of the double literal are zero?