public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block
@ 2020-10-07 13:17 trnka at scm dot com
2020-10-07 13:31 ` [Bug fortran/97320] " dominiq at lps dot ens.fr
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: trnka at scm dot com @ 2020-10-07 13:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
Bug ID: 97320
Summary: False positive "Array reference out of bounds in loop"
in a protecting if block
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: trnka at scm dot com
Target Milestone: ---
Compiling the following testcase with "gfortran -c -Wdo-subscript
do-subscript-test.f90" leads to a bunch of warnings like the following:
do-subscript-test.f90:13:26:
7 | i_: do i = 1, 10
| 2
......
13 | a(i-4) > a(i-5)) &
| 1
Warning: Array reference at (1) out of bounds (-4 < 1) in loop beginning at (2)
[-Wdo-subscript]
Given that all these accesses are in an "if (i > 5)" block, the warnings are
false positives and the out-of-bounds accesses cannot really occur. Inspecting
the .optimized output confirms this.
I can reproduce this using GCC 8 through 10 (GNU Fortran (GCC) 10.2.1 20200827
(Red Hat 10.2.1-3)), with or without -O2.
===== do-subscript-test.f90 =====
subroutine do_subscript_test()
implicit none
integer :: i
real :: a(10)
i_: do i = 1, 10
if (i > 5) then
if (a(i) > a(i-1) .and. &
a(i-1) > a(i-2) .and. &
a(i-2) > a(i-3) .and. &
a(i-3) > a(i-4) .and. &
a(i-4) > a(i-5)) &
exit i_
end if
end do i_
end subroutine
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
@ 2020-10-07 13:31 ` dominiq at lps dot ens.fr
2020-11-02 15:56 ` Jacques.Lebourlot at obspm dot fr
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: dominiq at lps dot ens.fr @ 2020-10-07 13:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2020-10-07
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The manual says
Warn if an array subscript inside a DO loop could lead to an out-of-bounds
access
even if the compiler cannot prove that the statement is actually executed,
in cases like
or don't use -Wdo-subscript if there is an IF in the DO block.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
2020-10-07 13:31 ` [Bug fortran/97320] " dominiq at lps dot ens.fr
@ 2020-11-02 15:56 ` Jacques.Lebourlot at obspm dot fr
2020-11-02 17:03 ` kargl at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Jacques.Lebourlot at obspm dot fr @ 2020-11-02 15:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
Jacques Le Bourlot <Jacques.Lebourlot at obspm dot fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Jacques.Lebourlot at obspm dot fr
--- Comment #2 from Jacques Le Bourlot <Jacques.Lebourlot at obspm dot fr> ---
Same here.
This is annoying because *some* warnings ARE relevant, and I need them to clean
a huge (and old) code. But they are lost in too many false positives.
Here is the test case I can provide (similar to Tomas')
-----------------------------
PROGRAM Warn_Bug
INTEGER, PARAMETER :: N = 2
INTEGER, DIMENSION(0:N) :: a
INTEGER :: i
a = [ (i, i = 0, N) ]
DO i = 0, N
IF (i == 0) THEN
PRINT *, " Do nothing"
ELSE IF (i >= 1) THEN
PRINT *, " OK:", a(i) - a(i-1)
ENDIF
ENDDO
END PROGRAM Warn_Bug
-----------------------------
The compiler should see that "IF (i >= 1)" THEN "i-1 >= 0". Quoting the manual
is not an adequate answer. An upgrade would be most welcomed.
Thank you.
Jacques
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
2020-10-07 13:31 ` [Bug fortran/97320] " dominiq at lps dot ens.fr
2020-11-02 15:56 ` Jacques.Lebourlot at obspm dot fr
@ 2020-11-02 17:03 ` kargl at gcc dot gnu.org
2020-11-02 17:09 ` Jacques.Lebourlot at obspm dot fr
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: kargl at gcc dot gnu.org @ 2020-11-02 17:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Jacques Le Bourlot from comment #2)
>
> The compiler should see that "IF (i >= 1)" THEN "i-1 >= 0". Quoting the
> manual is not an adequate answer. An upgrade would be most welcomed.
>
gfortran is mostly maintained by a diminishing number of contributors.
Messages telling the few remaining contributors what they ought to
do are likely to fall on deaf ears. Patches from new contributors
are welcomed; otherwise, sometime in the future, perhaps a decade
or so, someone might care enough to try to fix this annoyance. In the
meantime, add -Wno-do-subscript to your options.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
` (2 preceding siblings ...)
2020-11-02 17:03 ` kargl at gcc dot gnu.org
@ 2020-11-02 17:09 ` Jacques.Lebourlot at obspm dot fr
2020-11-02 20:11 ` anlauf at gcc dot gnu.org
2020-11-03 7:18 ` tkoenig at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: Jacques.Lebourlot at obspm dot fr @ 2020-11-02 17:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
--- Comment #4 from Jacques Le Bourlot <Jacques.Lebourlot at obspm dot fr> ---
(In reply to kargl from comment #3)
> (In reply to Jacques Le Bourlot from comment #2)
> >
> > The compiler should see that "IF (i >= 1)" THEN "i-1 >= 0". Quoting the
> > manual is not an adequate answer. An upgrade would be most welcomed.
> >
>
> gfortran is mostly maintained by a diminishing number of contributors.
> Messages telling the few remaining contributors what they ought to
> do are likely to fall on deaf ears. Patches from new contributors
> are welcomed; otherwise, sometime in the future, perhaps a decade
> or so, someone might care enough to try to fix this annoyance. In the
> meantime, add -Wno-do-subscript to your options.
My apologies. I did not mean to be rude or to complain. And I am not skilled
enough to contribute. Sorry.
But I will keep -Wdo-subscript, because I need the few cases that are *real*
positives.
Jacques
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
` (3 preceding siblings ...)
2020-11-02 17:09 ` Jacques.Lebourlot at obspm dot fr
@ 2020-11-02 20:11 ` anlauf at gcc dot gnu.org
2020-11-03 7:18 ` tkoenig at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: anlauf at gcc dot gnu.org @ 2020-11-02 20:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|WAITING |RESOLVED
--- Comment #5 from anlauf at gcc dot gnu.org ---
See PR 94978.
*** This bug has been marked as a duplicate of bug 94978 ***
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
` (4 preceding siblings ...)
2020-11-02 20:11 ` anlauf at gcc dot gnu.org
@ 2020-11-03 7:18 ` tkoenig at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-11-03 7:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu.org
Status|RESOLVED |NEW
Resolution|DUPLICATE |---
Severity|normal |enhancement
Depends on| |90302
--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
It's not an exact duplicate of PR 94978; that bug is about
a false positive without -Wdo-subscript, whereas this one is
about a false positive with -Wdo-subscript.
The reason why this is rather difficult to resolve is one
of translation phases.
In the gfortran front end, we create a syntax tree from the
Fortran source code. On the basis of that syntax tree (where
we still know a lot about the langauge) we issue that warning.
The next step is conversion to an intermediate language, which
gets handed to the main part of gcc for further processing
(known as the "middle end").
It is the middle which is does most of the optimizations, and
which has the tools to do so. In this particular instance, we
would need "range propagation" (where the compiler can infer the
range of variables from previous statements). We don't do that
in the front end, because a) it would be a major piece of work, and
b) it would duplicate a lot of what the middle end already does.
The most elegant solution would be support from the middle and
back end to put in a pseudo statement, like a __bulitin_warning
"function".
Code like
integer :: a(12)
do i=1,10
a(i-1) = 1
could then be annotated like
do i=1,10
if (0 < lbound(a)) call __builtin_warning ("index out of bounds")
if (9 > ubound(a)) call __builtin_warning ("index out of bounds")
a(i-1) = 1
and if the compiler could not prove that these statements get removed
by dead code elimination, it would issue the warning in the final phase of
translation.
This would pretty much eliminate false positives, and would be
far superior than what we currently do.
Unfortunately, this is a part of a compiler with which I am almost
totally unfamiliar, so I cannot help there. Some preliminary work
has been done (see PR 90302), but I don't know how far it has
progressed in the meantime.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302
[Bug 90302] Implement __builtin_warning
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-11-03 7:18 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-07 13:17 [Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block trnka at scm dot com
2020-10-07 13:31 ` [Bug fortran/97320] " dominiq at lps dot ens.fr
2020-11-02 15:56 ` Jacques.Lebourlot at obspm dot fr
2020-11-02 17:03 ` kargl at gcc dot gnu.org
2020-11-02 17:09 ` Jacques.Lebourlot at obspm dot fr
2020-11-02 20:11 ` anlauf at gcc dot gnu.org
2020-11-03 7:18 ` tkoenig 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).