[PATCH][C] c/95141 - fix bogus integer overflow warning

[PATCH][C] c/95141 - fix bogus integer overflow warning

[Richard Biener]

This fixes an integer overflow warning that ultimatively happens because
of TREE_OVERFLOW propagating through transforms and the existing guard
against this,

375           if (TREE_OVERFLOW_P (ret)
376               && !TREE_OVERFLOW_P (op0)
377               && !TREE_OVERFLOW_P (op1))
378             overflow_warning (EXPR_LOC_OR_LOC (expr, input_location,

being insufficient.  Rather than trying to use sth like walk_tree to
exhaustively walk operands (with the possibility of introducing
quadraticness when folding larger expressions recursively) the
following amends the above with an ad-hoc test for a binary op0
with a possibly constant op1.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

Thanks,
Richard.

2020-05-19  Richard Biener  <rguenther@suse.de>

	PR c/95141
	c/
	* c-fold.c (c_fully_fold_internal): Enhance guard on
	overflow_warning.

	* gcc.dg/pr95141.c: New testcase.
---
 gcc/c/c-fold.c                 | 1 +
 gcc/testsuite/gcc.dg/pr95141.c | 8 ++++++++
 2 files changed, 9 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr95141.c

diff --git a/gcc/c/c-fold.c b/gcc/c/c-fold.c
index 63becfeaf2c..bd21d247051 100644
--- a/gcc/c/c-fold.c
+++ b/gcc/c/c-fold.c
@@ -374,6 +374,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool *maybe_const_operands,
 	ret = fold (expr);
       if (TREE_OVERFLOW_P (ret)
 	  && !TREE_OVERFLOW_P (op0)
+	  && !(BINARY_CLASS_P (op0) && TREE_OVERFLOW_P (TREE_OPERAND (op0, 1)))
 	  && !TREE_OVERFLOW_P (op1))
 	overflow_warning (EXPR_LOC_OR_LOC (expr, input_location), ret, expr);
       if (code == LSHIFT_EXPR
diff --git a/gcc/testsuite/gcc.dg/pr95141.c b/gcc/testsuite/gcc.dg/pr95141.c
new file mode 100644
index 00000000000..b6cbba2f908
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr95141.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+
+#include <stdint.h>
+
+uint64_t test(uint8_t IA1)
+{
+  return (uint8_t)(IA1 & 158) & 1UL; /* { dg-bogus "integer overflow" } */
+}
-- 
2.25.1

Re: [PATCH][C] c/95141 - fix bogus integer overflow warning

[Joseph Myers]

On Tue, 19 May 2020, Richard Biener wrote:

> This fixes an integer overflow warning that ultimatively happens because
> of TREE_OVERFLOW propagating through transforms and the existing guard
> against this,
> 
> 375           if (TREE_OVERFLOW_P (ret)
> 376               && !TREE_OVERFLOW_P (op0)
> 377               && !TREE_OVERFLOW_P (op1))
> 378             overflow_warning (EXPR_LOC_OR_LOC (expr, input_location,
> 
> being insufficient.  Rather than trying to use sth like walk_tree to
> exhaustively walk operands (with the possibility of introducing
> quadraticness when folding larger expressions recursively) the
> following amends the above with an ad-hoc test for a binary op0
> with a possibly constant op1.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

OK.

The test in bug 32643 looks vaguely similar, but that's an older 
regression, do I take it this patch doesn't help with that one?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][C] c/95141 - fix bogus integer overflow warning

[Richard Biener]

On Tue, 19 May 2020, Joseph Myers wrote:

> On Tue, 19 May 2020, Richard Biener wrote:
> 
> > This fixes an integer overflow warning that ultimatively happens because
> > of TREE_OVERFLOW propagating through transforms and the existing guard
> > against this,
> > 
> > 375           if (TREE_OVERFLOW_P (ret)
> > 376               && !TREE_OVERFLOW_P (op0)
> > 377               && !TREE_OVERFLOW_P (op1))
> > 378             overflow_warning (EXPR_LOC_OR_LOC (expr, input_location,
> > 
> > being insufficient.  Rather than trying to use sth like walk_tree to
> > exhaustively walk operands (with the possibility of introducing
> > quadraticness when folding larger expressions recursively) the
> > following amends the above with an ad-hoc test for a binary op0
> > with a possibly constant op1.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> 
> OK.
> 
> The test in bug 32643 looks vaguely similar, but that's an older 
> regression, do I take it this patch doesn't help with that one?

Yes, it doesn't help with that older bug.  That is, it does not
change in any way where we set TREE_OVERFLOW, it just avoids
emitting an overflow warning in the above spot when overflow
was already present on original operands and thus likely(!)
propagated to the result.

Pushed.

Richard.