[PATCH, committed] PR fortran/98490 - Unexpected out of bounds in array constructor with implied do loop

[Harald Anlauf via Fortran]

The following patch by Steve was lingering in the PR for some time.

For an implied do loop within an array constructor we would generate an
additional, bogus substring bounds check for the index variable before it
actually became defined.  The check thus depended on the previous value of
the index variable before the implied do loop.  The solution was to omit
that early check.

There is still a remaining check on the index variable, verified by manual
inspection and by counting the substring bounds checks in the dump tree.

Regtested on x86_64-pc-linux-gnu.  Committed after discussion with Steve.
The patch had also previously been approved by Paul.

Thanks,
Harald


Fortran - out of bounds in array constructor with implied do loop

gcc/fortran/ChangeLog:

PR fortran/98490
* trans-expr.c (gfc_conv_substring): Do not generate substring
bounds check for implied do loop index variable before it actually
becomes defined.

gcc/testsuite/ChangeLog:

PR fortran/98490
* gfortran.dg/bounds_check_23.f90: New test.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index c4291cce079..18d665192f0 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2630,7 +2630,9 @@ gfc_conv_substring (gfc_se * se, gfc_ref * ref, int kind,
   if (!CONSTANT_CLASS_P (tmp) && !DECL_P (tmp))
 end.expr = gfc_evaluate_now (end.expr, &se->pre);

-  if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+  if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+  && (ref->u.ss.start->symtree
+	  && !ref->u.ss.start->symtree->n.sym->attr.implied_index))
 {
   tree nonempty = fold_build2_loc (input_location, LE_EXPR,
    logical_type_node, start.expr,
diff --git a/gcc/testsuite/gfortran.dg/bounds_check_23.f90 b/gcc/testsuite/gfortran.dg/bounds_check_23.f90
new file mode 100644
index 000..8de90c77c01
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/bounds_check_23.f90
@@ -0,0 +1,18 @@
+! { dg-do run }
+! { dg-options "-fcheck=bounds -fdump-tree-original" }
+! PR fortran/98490 - out of bounds in array constructor with implied do loop
+
+program test
+  implicit none
+  call sub('Lorem ipsum')
+contains
+  subroutine sub( text )
+character(len=*), intent(in)  :: text
+character(len=1), allocatable :: c(:)
+integer :: i
+c = [ ( text(i:i), i = 1, len(text) ) ]
+if (c(1) /= 'L') stop 1
+  end subroutine sub
+end program test
+
+! { dg-final { scan-tree-dump-times "Substring out of bounds:" 2 "original" } }

gfortran on Apple M1 function address problem

[Alex Lelievre]

Hi there,

I’m a newbie to this list and tried my dearest to search the archives (with the 
scrollbar) to find an answer.

I’m having a problem running a well known ham radio application called WSJT-X 
for the Apple M1 running Monterey with gfortran 11.2.0.  Tthe code compiles 
fine.  The issue is at runtime with one of the submodules which is written in 
fortran (specifically ft8 using jt9 executable).

I’ve tried to distill the problem down to a very small sample by removing all 
the code and just getting it down to two files, but alas, it doesn’t reproduce 
the bug.  The code works fine in this case.

The bug that I’m running into is that the address of a subroutine that is used 
as a callback is not correct.  The exact same code works on Intel but not on 
Apple M1 using the same compiler version.  The subroutine is part of a derived 
class.  The only thing I’ve noticed from looking at the parse tree is that the 
vtable _size parameter is 8 bytes vs 4.  I doubt this matters but figured I’d 
mention it.

What I’ve seen from the disassembly is that the M1 version of gfortran 
correctly stores the address of the callback into a data structure.  The bug is 
that it uses the address of a data structure (that contains the function 
pointer address) instead of the actual function pointer address.  This causes a 
bus error.  What I’ve also noticed is that the data structure address is wrong 
by 8 bytes (aside from the fact that the address isn’t being dereferenced- but 
maybe that’s hidden data)… Is it possible that it’s not deferencing a pointer?  
I’ve tried replacing the address of the data structure with the function 
address and the code successfully makes it into the callback but then crashes 
later inside fortran formatting routines.   Is it likely that the stack is 
corrupt?

I’m looking for any help solving this issue.  If anyone can give me some advice 
or clues on how to submit a bug for this or further debug it, I will do what it 
takes to provide the needed details.   

Thanks for your help!
alex