[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2021-09-14 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=31130

--- Comment #14 from Andrew Pinski  ---
The xfail was removed with r8-395 which removed -fno-strict-overflow usage.

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2016-08-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Richard Biener  changed:

   What|Removed |Added

   Keywords||xfail
 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #13 from Richard Biener  ---
Re-opening because I am fixing a bug that makes the diagnostic re-appear (it
was "fixed" by a bug that caused us to meet [0, +INF] and [1, +INF(OVF)] as [0,
+INF]
rather than [0, +INF(OVF)]).

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2014-08-18 Thread kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

--- Comment #12 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Aug 18 06:28:35 2014
New Revision: 214084

URL: https://gcc.gnu.org/viewcvs?rev=214084root=gccview=rev
Log:
gcc/testsuite
2014-08-18  Kugan Vivekanandarajah  kug...@linaro.org

PR tree-optimization/52904
* gcc.dg/pr52904.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr52904.c
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2014-08-08 Thread kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kugan at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #9 from kugan at gcc dot gnu.org ---
Incorrect warning is gone from the latest trunk build. VRP is now able to
detect the correct range. This bug can now be closed.


Value ranges after VRP:

channel_8: [1, 1023]  EQUIVALENCES: { channel_10 } (1 elements)
channel_10: [1, 1024]
channel_15: [0, 1023]
.MEM_16: VARYING


Removing basic block 5
wait_reading_process_output ()
{
  int channel;
  int nfds;

  bb 2:

  bb 3:
  # channel_15 = PHI channel_10(3), 0(2)
  foo (channel_15);
  channel_10 = channel_15 + 1;
  if (channel_10 != 1024)
goto bb 3;
  else
goto bb 4;

  bb 4:
  return 0;

}


[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2014-08-08 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to kugan from comment #9)
 Incorrect warning is gone from the latest trunk build. VRP is now able to
 detect the correct range. This bug can now be closed.

Since it was probably fixed by accident, it will get unfixed by accident again.
If you don't add the testcase to the regression testsuite, this will happen
again:

https://gcc.gnu.org/wiki/HowToPrepareATestcase

If you add a testcase pointing to this PR, when it fails people can come back
here and read the discussion.

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2014-08-08 Thread kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

--- Comment #11 from kugan at gcc dot gnu.org ---
I agree. I will post a patch to add this test-case and let the maintainers
decide if this is necessary.


[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2013-12-12 Thread Laurent.Rineau__gcc at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Laurent Rineau Laurent.Rineau__gcc at normalesup dot org changed:

   What|Removed |Added

 CC||Laurent.Rineau__gcc@normale
   ||sup.org

--- Comment #5 from Laurent Rineau Laurent.Rineau__gcc at normalesup dot org 
---
With the following gcc version:
  gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1)

I have a similar result:

$ gcc -c -Wstrict-overflow -O2 v.i
v.i: In function ‘wait_reading_process_output’:
v.i:14:6: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
   if (nfds  0)
  ^

That diagnostic seems right, according to the documentation of
-Wstrict-overflow.

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2013-12-12 Thread eggert at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

--- Comment #6 from eggert at gnu dot org ---
 That diagnostic seems right, according to the documentation of 
 -Wstrict-overflow.

The diagnostic is right only in the sense that it is correctly reporting
that GCC does not deduce that signed overflow cannot possibly occur in
this function.  It is not right in the common sense that a programmer
would ordinarily want, i.e., that the program may have a bug because
signed overflow might lead to undefined behavior.  (Surely the diagnostic
is supposed to be for the benefit of programmers trying to find potential
bugs in their programs, not for the benefit of GCC maintainers trying
to explain how GCC works internally.  :-)


[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2013-12-12 Thread Laurent.Rineau__gcc at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

--- Comment #7 from Laurent Rineau Laurent.Rineau__gcc at normalesup dot org 
---
In the test case, nfds cannot overflow, because of two reasons:
  - nfds is only incremented from 0, and -fstrict-overflow allows gcc to
suppose it will not overflow,
  - the number of iterations of the loop cannot allow nfds to overflow, even
without -fstrict-overflow.

Gcc warns that the test (nfds  0) is useless, because of -fstrict-overflow.
The developer has two solutions:
  - remove that test,
  - or compile with -fno-strict-overflow.


[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2013-12-12 Thread eggert at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

--- Comment #8 from eggert at gnu dot org ---
On 12/12/2013 10:19 AM, Laurent.Rineau__gcc at normalesup dot org wrote:
 The developer has two solutions:
   - remove that test,
   - or compile with -fno-strict-overflow.

Sure, and because of this problem, GNU Emacs has chosen #2, that
is, Emacs doesn't use -Wstrict-overflow any more.  (Removing
the test would unnecessarily complicate Emacs, since the
test is needed on some platforms that are conditionally
compiled away in this stripped-down example.)

A goal of -Wstrict-overflow, at least at the 1 level, is to
not generate false alarms, so that it's generally useful in
real programs.  This bug report gives one example where the
goal is not being met.  Emacs currently has a half dozen or
so such examples of this (please see below for what the
current Emacs bzr trunk would output, if we enabled this
warning) and I thought that the GCC developers would find it
useful to see one of them.  If you're not interested, that's
OK too; Emacs will continue to not use -Wstrict-overflow.

In file included from dispnew.c:26:0:
dispnew.c: In function ‘update_window’:
lisp.h:749:30: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
   return num  lower ? lower : num = upper ? num : upper;

dispnew.c: In function ‘update_frame_1’:
dispnew.c:4490:19: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
   pause_p = 0  i  i  FRAME_LINES (f) - 1;
fileio.c: In function ‘Finsert_file_contents’:
fileio.c:3630:11: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
if (nread  0)
   ^
fileio.c:3632:16: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
else if (nread  0)
^
eval.c: In function ‘backtrace_eval_unrewind’:
eval.c:3496:3: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
   for (; distance  0; distance--)
   ^
intervals.c: In function ‘offset_intervals’:
intervals.c:1364:6: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
   if (length == TOTAL_LENGTH (tree))
  ^
intervals.c:1379:9: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]
   while (left_to_delete  0)
 ^

[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2012-04-10 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-10
 CC||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-04-10 
12:16:54 UTC ---
It's the

  if (nfds  0)

conditional that we warn on.  We cannot currently derive an upper bound
for nfds based on the number of iterations of the loop as it is not
an induction variable we can analyze.

int
wait_reading_process_output (void)
{
  int nfds = 0;
  int channel;
  for (channel = 0; channel  1024; ++channel)
{
  if (foo (channel))
nfds++;
}
  if (nfds  0)
return 1;

This is in some way a missed optimization in value-range analysis as well.


[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop

2012-04-08 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |tree-optimization

--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-08 
10:05:26 UTC ---
(In reply to comment #2)
 Created attachment 27115 [details]
 simplified version of Emacs code, illustrating the bug
 
 Re-uploading the test case, marked as text/plain this time, so it's easier 
 to
 download.

You did not have to re-upload the testcase, you can change the MIME type of the
atttachment after the fact.