[Bug fortran/109157] New: -fbound-check: false positive

[Bug fortran/109157] New: -fbound-check: false positive

[philippe.wautelet at aero dot obs-mip.fr]

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

            Bug ID: 109157
           Summary: -fbound-check: false positive
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: philippe.wautelet at aero dot obs-mip.fr
  Target Milestone: ---

Hello,

The following code triggers a wrong out of bound detection:
> cat ndimlist.f90
program ndimlistbug
  implicit none

  integer, parameter :: FIELDSIZE=5
  type :: tfieldmetadata_base
    integer, dimension(10) :: ndimlist = -2
  end type tfieldmetadata_base

  type(tfieldmetadata_base), dimension(FIELDSIZE) :: tzfields

  call write_diachro_lfi( tzfields )

contains
subroutine write_diachro_lfi( tpfields )
  class(tfieldmetadata_base), dimension(:), intent(in) :: tpfields

  print *,tpfields(1)%ndimlist
  print *,tpfields(1)%ndimlist(8)
end subroutine write_diachro_lfi
end program ndimlistbug

If compiled with gfortran 12.2.0 (but also 11.1.0, 11.2.0, 11.3.0 and 12.1.0),
it gives:
> gfortran -g -fbounds-check ndimlist.f90
> ./a.out 
          -2          -2          -2          -2          -2          -2       
  -2          -2          -2          -2
At line 18 of file ndimlist.f90
Fortran runtime error: Index '8' of dimension 1 of array
'tpfields%_data%ndimlist' above upper bound of 5

Error termination. Backtrace:
#0  0x400aec in write_diachro_lfi
        at /home/waup/F90/bug_gcc/ndimlist/ndimlist.f90:18
#1  0x4008ee in ndimlistbug
        at /home/waup/F90/bug_gcc/ndimlist/ndimlist.f90:11
#2  0x400b8f in main
        at /home/waup/F90/bug_gcc/ndimlist/ndimlist.f90:11

It seems there is a confusion between the size of tpfields and the size of
tpfields()%ndimlist. This can be seen if FIELDSIZE is set to at least the size
of ndimlist.

The bug is not present with versions of gfortran below 11.

[Bug fortran/109157] -fbound-check: false positive

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-03-16
           Priority|P3                          |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
If you change

   class(tfieldmetadata_base), dimension(:), intent(in) :: tpfields

to
   type(tfieldmetadata_base), dimension(:), intent(in) :: tpfields

the code executes without the runtime error.  Likely, gfortran is not using the
correct dimension from the vtab created for a class entity.

[Bug fortran/109157] -fbound-check: false positive

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=104908

--- Comment #2 from anlauf at gcc dot gnu.org ---
Might be related to pr104908.

[Bug fortran/109157] -fbound-check: false positive

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Indeed a dup and fixed by the commit for pr104908.

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