[Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards

[Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards

[david at westcontrol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702

            Bug ID: 100702
           Summary: Strict overflow warning regression in gcc 8 onwards
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

Incorrect code like this example relies on two's complement wrapping to do what
the programmer wanted:

void foo(int *a)
{
  int i;
  for (i=0; i<i+1; i++)
    a[i&256]=0;
}

Since signed integer overflow is undefined behaviour, gcc optimises code like
that to an infinite loop.  That's fair enough.  But it would always be helpful
with a warning about such cases.

For gcc 7 and below, gcc can generate a warning but only if
"-Wstrict-overflow=5" is used.

gcc 8 and above have no warning, even with that flag (and -Wall -Wextra -O2).


I realise that these things can change between versions due to re-arrangement
of compiler passes and other differences.  But is there a possibility of a
warning when assumptions about undefined behaviour lead to infinite loops? 
(The compiler knows the loop is infinite - it doesn't bother generating a
return opcode.)

[Bug c/100702] Strict overflow warning regression in gcc 8 onwards

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
            Version|unknown                     |11.1.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
You can use -fsanitize=undefined to get runtime diagnostics, the compile-time
warnings were mostly inefficient and/or had too many false positives to be
useful and thus were largely removed.

[Bug c/100702] Strict overflow warning regression in gcc 8 onwards

[david at westcontrol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702

--- Comment #2 from David Brown <david at westcontrol dot com> ---
Runtime diagnostics can be very useful - but they are a different kind of
warning.  In particular, they only show what errors have occurred during your
testing - they don't show what errors /might/ occur.

There is a general rule that the earlier you find your problems, the cheaper,
faster and easier they are to handle.  Compile-time checks are better than
run-time checks when all else is equal.  Clearly compile-time checks have more
risk of false-positives - that's why it's important that most are optional or
can be disabled by pragmas or particular code constructs.  But when they /can/
be used, they are preferable.

In this particular example, there is no doubt of the undefined behaviour and
the infinite loop.  The compiler knows about them.  It would not be a false
positive to issue a warning in such cases.


Another limitation of runtime diagnostics is their use in embedded systems. 
gcc is heavily used in microcontrollers, where you often do not have much in
the way of a console output, no file system, etc.  Runtime diagnostic
opportunities are far more limited in such cases.


I fully appreciate that compile-time warnings are difficult, especially
avoiding false positives, and if you say that a warning here would be too niche
or too difficult to justify the effort, I am happy to accept that.  But
run-time diagnostics are not a replacement - they are an additional and
complementary tool.  Please do not consider sanitizers as a substitute for
static analysis and compile-time error checking and warnings.

[Bug c/100702] Strict overflow warning regression in gcc 8 onwards

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-05-20
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
It should be possible to detect the wide-spread 'i < i + 1' anipattern in the
front ends without too many false positives (with __builtin_warning it should
even be able to avoid them in dead code).  Let me confirm this request on that
basis.

[Bug middle-end/100702] Strict overflow warning regression in gcc 8 onwards

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
gcc.dg/Wstrict-overflow-7.c is the testcase for this.

[Bug middle-end/100702] Strict overflow warning regression in gcc 8 onwards

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So this is a dup of bug 80511.

*** This bug has been marked as a duplicate of bug 80511 ***