[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2021-04-16 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2021-01-14 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-11-02 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||trnka at scm dot com

--- Comment #4 from anlauf at gcc dot gnu.org ---
*** Bug 97320 has been marked as a duplicate of this bug. ***

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-07-26 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

Thomas Koenig  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Thomas Koenig  ---
Let's see what can be done about this.(In reply to Thomas Koenig from comment
#2)
> Two ways to fix this: When checking for outer do loops, also check
> if the inner one will be executed at all.
> 
> Or PR 90302, which is looking more attractive than ever.

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-05-18 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Blocks||90302
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-18
 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
Two ways to fix this: When checking for outer do loops, also check
if the inner one will be executed at all.

Or PR 90302, which is looking more attractive than ever.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302
[Bug 90302] Implement __builtin_warning

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-05-07 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
   Keywords||diagnostic

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-05-06 Thread foreese at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

--- Comment #1 from Fritz Reese  ---
The regression is caused by r253156, which introduces the warning in the first
place. The relevant code is in frontend-passes.c (do_subscript). Apparently,
the FE is aware that when there is a conditional it cannot correctly simplify
the subscript bounds. However, in the testcase there is an inner DO-loop which,
when the bounds are reduced to the empty set, prevents the code from becoming
invalid. Therefore no warning should be issued.

The warning can be bypassed by guarding the inner DO-loop with any conditional,
including a vacuously true one:

$ diff -auw pascal.f03 pascal2.f03
--- pascal.f03  2020-05-06 19:14:50.966646632 -0400
+++ pascal2.f03 2020-05-06 19:23:48.209569659 -0400
@@ -9,9 +9,11 @@

 do i = 0, 8
   pascal(i,0) = 1
+  if (.true.) then
   do j = 1, i-1
 pascal(i,j) = pascal(i-1,j) + pascal(i-1,j-1)
   enddo
+  endif
   do j = i, 8
 pascal(i,j) = 0
   enddo
$ gfortran pascal2.f03


Normally the warning can be suppressed with -Wno-do-subscript, but the code in
do_subscript() determines that this is "definitely" an issue and therefore
moves the warning to category 0.

(An interesting note: moving the code in the testcase into a subroutine, rather
than the main program, suppresses the warning for GCC 8, but not GCC 9, 10, or
11.)