public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards
@ 2021-05-20 11:01 david at westcontrol dot com
2021-05-20 11:33 ` [Bug c/100702] " rguenth at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: david at westcontrol dot com @ 2021-05-20 11:01 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/100702] Strict overflow warning regression in gcc 8 onwards
2021-05-20 11:01 [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards david at westcontrol dot com
@ 2021-05-20 11:33 ` rguenth at gcc dot gnu.org
2021-05-20 12:23 ` david at westcontrol dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-20 11:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/100702] Strict overflow warning regression in gcc 8 onwards
2021-05-20 11:01 [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards david at westcontrol dot com
2021-05-20 11:33 ` [Bug c/100702] " rguenth at gcc dot gnu.org
@ 2021-05-20 12:23 ` david at westcontrol dot com
2021-05-20 17:43 ` msebor at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: david at westcontrol dot com @ 2021-05-20 12:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c/100702] Strict overflow warning regression in gcc 8 onwards
2021-05-20 11:01 [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards david at westcontrol dot com
2021-05-20 11:33 ` [Bug c/100702] " rguenth at gcc dot gnu.org
2021-05-20 12:23 ` david at westcontrol dot com
@ 2021-05-20 17:43 ` msebor at gcc dot gnu.org
2021-09-05 22:21 ` [Bug middle-end/100702] " pinskia at gcc dot gnu.org
2021-09-05 22:22 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-05-20 17:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/100702] Strict overflow warning regression in gcc 8 onwards
2021-05-20 11:01 [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards david at westcontrol dot com
` (2 preceding siblings ...)
2021-05-20 17:43 ` msebor at gcc dot gnu.org
@ 2021-09-05 22:21 ` pinskia at gcc dot gnu.org
2021-09-05 22:22 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-05 22:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug middle-end/100702] Strict overflow warning regression in gcc 8 onwards
2021-05-20 11:01 [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards david at westcontrol dot com
` (3 preceding siblings ...)
2021-09-05 22:21 ` [Bug middle-end/100702] " pinskia at gcc dot gnu.org
@ 2021-09-05 22:22 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-05 22:22 UTC (permalink / raw)
To: gcc-bugs
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 ***
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-05 22:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-20 11:01 [Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards david at westcontrol dot com
2021-05-20 11:33 ` [Bug c/100702] " rguenth at gcc dot gnu.org
2021-05-20 12:23 ` david at westcontrol dot com
2021-05-20 17:43 ` msebor at gcc dot gnu.org
2021-09-05 22:21 ` [Bug middle-end/100702] " pinskia at gcc dot gnu.org
2021-09-05 22:22 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).