diff options
author | Jakub Jelinek <jakub@redhat.com> | 2023-01-13 18:23:57 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2023-01-13 18:23:57 +0100 |
commit | 3456db4de8940235b303ca38a689353854c9239f (patch) | |
tree | 8ed8ca4781c33441f22e56dd743915016e9520c5 /gcc/function.cc | |
parent | 325a79b2c629bb7a2271dfebd678a27afcef4d01 (diff) | |
download | gcc-3456db4de8940235b303ca38a689353854c9239f.zip gcc-3456db4de8940235b303ca38a689353854c9239f.tar.gz gcc-3456db4de8940235b303ca38a689353854c9239f.tar.bz2 |
c++: Avoid some false positive -Wfloat-conversion warnings with extended precision [PR108285]
On the following testcase trunk emits a false positive warning on ia32.
convert_like_internal is there called with type of double and
expr EXCESS_PRECISION_EXPR with float type with long double operand
2.L * (long double) x.
Now, for the code generation we do the right thing, cp_convert
to double from that 2.L * (long double) x, but we call even
cp_convert_and_check with that and that emits the -Wfloat-conversion
warning. Looking at what the C FE does in this case, it calls
convert_and_check with the EXCESS_PRECISION_EXPR expression rather
than its operand, and essentially uses the operand for code generation
and EXCESS_PRECISION_EXPR itself for warnings.
The following patch does that too for the C++ FE.
2023-01-13 Jakub Jelinek <jakub@redhat.com>
PR c++/108285
* cvt.cc (cp_convert_and_check): For EXCESS_PRECISION_EXPR
use its operand except that for warning purposes use the original
EXCESS_PRECISION_EXPR.
* call.cc (convert_like_internal): Only look through
EXCESS_PRECISION_EXPR when calling cp_convert, not when calling
cp_convert_and_check.
* g++.dg/warn/pr108285.C: New test.
Diffstat (limited to 'gcc/function.cc')
0 files changed, 0 insertions, 0 deletions