On 18/03/25 12:44 +0800, Gwen Fu wrote:
Patch about Bug 119222 - Conversion of inf to integer is not diagnosed
[Classifier] a single patch
[Tags] conversion warning ;c++; inf to integer
[Brief Summary] Add a judgement in the RDIV_EXPR case
[Remark]
This patch does not support -Wall -Wextra to capture inf to integer
warnings .
The -Wall -Wextra options do not check this conversion (and do not allow
the conversion_warning function to be executed completely), instead you
need to add -Wfloat-conversion or -Wconversion》
[Pontential problem]
Is there a case where the conversion result type is not limited to
INTEGER_TYPE?
Thanks for the patch, it's always good to have a new contributor.
Please read https://gcc.gnu.org/contribute.html#legal and
https://gcc.gnu.org/contribute.html#patches for information on
contributing patches. We need the legal prerequisites to be met, and
the format of this patch is ... unusual.
The email subject is a long string of text, the [Classifier], [Tags]
etc. are not needed.
https://cbea.ms/git-commit/ is useful for writing commit messages.
The Git commit message should be used as the email body, because
whatever useful information you want to provide about the patch should
also be in the commit message.
We also need a ChangeLog entry describing where the changes where
made.
From 6924ad5d1a3a96ed46b728a47462a7a054613326 Mon Sep 17 00:00:00 2001
From: Gwen Fu <gwen3293940...@gmail.com>
Date: Tue, 18 Mar 2025 11:37:28 +0800
Subject: [PATCH] fix bug119222 Conversion of inf to integer is not diagnosed
It seems this Subject wasn't actually used as the subject for your
email. You could try using 'git send-email' so that your git commit
message can be reused as the email to gcc-patches.
---
gcc/c-family/c-common.cc | 5 +++--
gcc/c-family/c-warn.cc | 11 +++++++++++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 587d76461e9..dfd5c3d673c 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -1652,11 +1652,12 @@ unsafe_conversion_p (tree type, tree expr, tree result,
bool check_sign)
else
{
/* Warn for real types converted to integer types. */
- if (SCALAR_FLOAT_TYPE_P (expr_type)
+ if ((SCALAR_FLOAT_TYPE_P (expr_type)
+ ||TREE_CODE(expr_type) ==REAL_TYPE)
Please check the use of whitespace here, to be consistent with the GCC
conventions: https://gcc.gnu.org/codingconventions.html
What does this part of the commit do? There's no changelog so I can't
tell if you meant to include it in the patch.
&& (TREE_CODE (type) == INTEGER_TYPE
|| TREE_CODE (type) == BITINT_TYPE))
give_warning = UNSAFE_REAL;
-
+
else if ((TREE_CODE (expr_type) == INTEGER_TYPE
|| TREE_CODE (expr_type) == BITINT_TYPE)
&& (TREE_CODE (type) == INTEGER_TYPE
diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index d547b08f55d..406b591bfa0 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -1283,6 +1283,17 @@ conversion_warning (location_t loc, tree type, tree
expr, tree result)
case CEIL_DIV_EXPR:
case EXACT_DIV_EXPR:
case RDIV_EXPR:
+ /*Issue a warning about infinity conversion to int*/
Doesn't this check also get done for all the other cases, such as
CEIL_DIV_EXPR, not only for RDIV_EXPR? Is that what you want? It
doesn't match your summary of the change above.
+ if( TREE_CODE(type) == INTEGER_TYPE
Missing space before parenthesis.
+ && TREE_CODE (TREE_OPERAND(expr,1)) == REAL_CST && real_zerop
(TREE_OPERAND(expr,1)))
This line is too long, it needs a line break.
+ {
+ bool ret = warning_at(loc , OPT_Wfloat_conversion ,
+ "conversion from %qT to %qT changes infinity to maximum or minimum
integer value",
+ expr_type , type) ;
The message is misleading, the C and C++ standards says the result of
the conversion is undefined.
+ if(!ret) warning_at(loc , OPT_Wconversion ,
Do you need both checks? Isn't -Wfloat-conversion already enabled by
-Wconversion?
+ "conversion from %qT to %qT changes infinity to maximum or minimum
integer value",
+ expr_type , type) ;
+ }
arith_ops = 2;
goto default_;
--
2.45.2
int fooo()
{
return 1/static_cast<double>(0) ;
}
int main()
{
int a = 1/static_cast<double>(0) ;
int b = static_cast<float>(1) / 0 ;
return 0 ;
}
Is this code supposed to be part of the patch?
There should be a new testcase added to the testsuite to verify that
your new warning is emitted when expected, and that it is not emitted
when -Wfloat-conversion is not used.
Also, I think the point of the bug report is that the conversion
(int)(1/0.0) always has undefined behaviour, and the values are known
at compile-time, so it should be possible to warn unconditionally,
even without -Wfloat-conversion. The documentation for
-Wfloat-conversion says "Warn for implicit conversions that reduce the
precision of a real value." This isn't just a case of reducing
precision, it's undefined behaviour.
