Bug 465291 - gcc 4.1 & 4.3 size of passed fortran arrays confused.
gcc 4.1 & 4.3 size of passed fortran arrays confused.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc44 (Show other bugs)
5.3
All Linux
high Severity high
: rc
: ---
Assigned To: Jakub Jelinek
qe-baseos-tools
:
Depends On:
Blocks: 585980
  Show dependency treegraph
 
Reported: 2008-10-02 12:22 EDT by Alan Matsuoka
Modified: 2011-05-13 09:23 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 585980 (view as bug list)
Environment:
Last Closed: 2010-04-29 11:28:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
reproducer 1 (564 bytes, text/plain)
2008-10-02 12:22 EDT, Alan Matsuoka
no flags Details
dwarf-array2.f90 (378 bytes, text/plain)
2008-10-02 12:24 EDT, Alan Matsuoka
no flags Details
dwarf-array3.f90 (362 bytes, text/plain)
2008-10-02 12:27 EDT, Alan Matsuoka
no flags Details
dwarf-array5.f90 (266 bytes, text/plain)
2008-10-02 12:30 EDT, Alan Matsuoka
no flags Details
dwarf-array.f90 using allocatable yzap. (601 bytes, text/plain)
2009-06-02 09:34 EDT, Jan Kratochvil
no flags Details
static-pass-as-dynamic.f90 (198 bytes, text/plain)
2009-06-02 09:39 EDT, Jan Kratochvil
no flags Details

  None (edit)
Description Alan Matsuoka 2008-10-02 12:22:23 EDT
Created attachment 319258 [details]
reproducer 1

Notice when you print the type of the array pzap it has the correct upper bounds of the array. However when that array is passed into a subroutine and you print the type the size doesn't make any sense at all. It is 1211010322,-155.

Furthermore when you try to print the array you get nothing and when you try to print the contents of an element of the array the debugger can't access the memory location of the element. Something is very wrong.

[ben@x61 tmp]$ gfortran43 -g dwarf-array.f90
[ben@x61 tmp]$ gdb a.out
GNU gdb Fedora (6.8-23.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) b 27
Breakpoint 1 at 0x8048a37: file dwarf-array.f90, line 27.
(gdb) b 9
Breakpoint 2 at 0x80487cd: file dwarf-array.f90, line 9. (2 locations)
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, test_pass () at dwarf-array.f90:27
27         call sub_test(yzap,yzap(:,2),2)
Current language:  auto; currently fortran
(gdb) ptype yzap
type = real(kind=4) (2,2)
(gdb) c
Continuing.

Breakpoint 2, sub_test (a_sub=(), c_sub=(<assumed size array> 0), c_size=2) at dwarf-array.f90:9
9          call contained_sub
(gdb) ptype a_sub
type = real(kind=4) (1211010322,-155)
(gdb) ptype b_sub
type = real(kind=4) (1211010322,-155)
(gdb) ptype c_sub
type = real(kind=4) (0:*)
(gdb) p a_sub
$1 = ()
(gdb) p b_sub
$2 = ()
(gdb) p c_sub
$3 = (<assumed size array> 0)
(gdb) p a_sub(1,1)
Cannot access memory at address 0x3f800000
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[ben@x61 tmp]$
Comment 1 Alan Matsuoka 2008-10-02 12:23:59 EDT
I believe that the problem with the specification of the arrays is in fact a compiler error rather than a GDB error. This problem seems to exist in both gcc 4.1 and 4.3

dwarf-array2.f90 is a slightly simplified version of the previous test case. It mostly removes stuff but it does add one line.

diff -u -r1.1 dwarf-array.f90
--- dwarf-array.f90     2008/09/24 23:12:05     1.1
+++ dwarf-array.f90     2008/09/24 23:15:35
@@ -1,19 +1,13 @@
-subroutine sub_test(a_sub,c_sub,c_size)
-   real,target  :: a_sub(:,:)
-   integer      :: c_size
-   real         :: c_sub(c_size,c_size/2)
-
-   real,pointer :: b_sub(:,:)
-
-   b_sub => a_sub
+subroutine sub_test(a_sub)
+   real         :: a_sub(:,:)
+
+   a_sub(1,1)=5.
   call contained_sub

contains

   subroutine contained_sub
     print*,'a_sub',a_sub(:,:)
-     print*,'b_sub',b_sub(:,:)
-     print*,'c_sub',c_sub(:,:)
   end subroutine contained_sub

end subroutine sub_test
@@ -24,7 +18,7 @@
   yzap(2,1)=2.
   yzap(1,2)=3.
   yzap(2,2)=4.
-   call sub_test(yzap,yzap(:,2),2)
+   call sub_test(yzap)
end program test_pass

Notice the addition of the line that says:
a_sub(1,1)=5.

When run under a debugger, that line causes a segv as if when trying to access the array it uses the bizarre 1211010322,-155 bounds to try to find the element that is to be modified. Therefore, I believe that it is a compiler issue rather than a debugger issue. Something about passing a 2D array as a parameter to a subroutine is not working right in gfortran 4.1 and 4.3.
[ben@x61 tmp]$ gfortran43 -g dwarf-array.f90
[ben@x61 tmp]$ gdb a.out
GNU gdb Fedora (6.8-23.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) b 21
Breakpoint 1 at 0x8048769: file dwarf-array.f90, line 21.
(gdb) b 5
Breakpoint 2 at 0x804864b: file dwarf-array.f90, line 5. (2 locations)
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, test_pass () at dwarf-array.f90:21
21         call sub_test(yzap)
Current language:  auto; currently fortran
(gdb) p yzap
$1 = (( 1, 2) ( 3, 4) )
(gdb) ptype yzap
type = real(kind=4) (2,2)
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x08048648 in sub_test (a_sub=()) at dwarf-array.f90:4
4          a_sub(1,1)=5.
(gdb) p a_sub
$2 = ()
(gdb) ptype a_sub
type = real(kind=4) (1215536674,-155)
(gdb) p a_sub(1,1)
Cannot access memory at address 0x3f800000
(gdb) quit
The program is running.  Exit anyway? (y or n) y
Comment 2 Alan Matsuoka 2008-10-02 12:24:56 EDT
Created attachment 319259 [details]
dwarf-array2.f90
Comment 3 Alan Matsuoka 2008-10-02 12:27:05 EDT
Reducing the order of the array doesn't seem to help

[ben@x61 tmp]$ diff -u dwarf-array2.f90 dwarf-array3.f90
--- dwarf-array2.f90    2008-09-24 16:22:26.000000000 -0700
+++ dwarf-array3.f90    2008-09-24 16:50:06.000000000 -0700
@@ -1,23 +1,23 @@
subroutine sub_test(a_sub)
-   real         :: a_sub(:,:)
+   real         :: a_sub(:)
 
-   a_sub(1,1)=5.
+   a_sub(1)=5.
   call contained_sub

contains

   subroutine contained_sub
-     print*,'a_sub',a_sub(:,:)
+     print*,'a_sub',a_sub(:)
   end subroutine contained_sub

end subroutine sub_test

program test_pass
-   real :: yzap(2,2)
-   yzap(1,1)=1.
-   yzap(2,1)=2.
-   yzap(1,2)=3.
-   yzap(2,2)=4.
+   real :: yzap(5)
+   yzap(1)=1.
+   yzap(2)=2.
+   yzap(3)=3.
+   yzap(4)=4.
   call sub_test(yzap)
end program test_pass

[ben@x61 tmp]$ gfortran43 -g dwarf-array.f90
[ben@x61 tmp]$ gdb a.out
GNU gdb Fedora (6.8-23.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) b 21
Breakpoint 1 at 0x8048723: file dwarf-array.f90, line 21.
(gdb) b 5
Breakpoint 2 at 0x804861a: file dwarf-array.f90, line 5. (2 locations)
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, test_pass () at dwarf-array.f90:21
21         call sub_test(yzap)
Current language:  auto; currently fortran
(gdb) p yzap
$1 = (1, 2, 3, 4, 8.05204875e-39)
(gdb) ptype yzap
type = real(kind=4) (5)
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x08048617 in sub_test (a_sub=()) at dwarf-array.f90:4
4          a_sub(1)=5.
(gdb) ptype a_sub
type = real(kind=4) (-1083544877)
(gdb)
Comment 4 Alan Matsuoka 2008-10-02 12:27:56 EDT
Created attachment 319261 [details]
dwarf-array3.f90
Comment 5 Alan Matsuoka 2008-10-02 12:28:38 EDT
The problem appears with implied size arrays when passed as parameters:

[ben@x61 tmp]$ rcsdiff -u dwarf-array.f90
===================================================================
RCS file: dwarf-array.f90,v
retrieving revision 1.4
diff -u -r1.4 dwarf-array.f90
--- dwarf-array.f90     2008/09/24 23:57:13     1.4
+++ dwarf-array.f90     2008/09/25 00:13:02
@@ -1,12 +1,12 @@
subroutine sub_test(a_sub)
-   real         :: a_sub(:)
+   real         :: a_sub(4)
 
   a_sub(1)=5.
   print*,'a_sub',a_sub(:)
end subroutine sub_test

program test_pass
-   real :: yzap(5)
+   real :: yzap(4)
   yzap(1)=1.
   yzap(2)=2.
   yzap(3)=3.

Whenever I change the parameter passed from being implied to being fixed, then the problem goes away with both debugging and accessing the members.

[ben@x61 tmp]$ gfortran43 -g dwarf-array.f90
[ben@x61 tmp]$ gdb a.out
GNU gdb Fedora (6.8-23.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) b 4
Breakpoint 1 at 0x80485bd: file dwarf-array.f90, line 4.
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, sub_test (a_sub=(1, 2, 3, 4)) at dwarf-array.f90:4
4          a_sub(1)=5.
Current language:  auto; currently fortran
(gdb) p a_sub
$1 = (1, 2, 3, 4)
(gdb) n
5          print*,'a_sub',a_sub(:)
(gdb) ptype a_sub
type = real(kind=4) (4)
(gdb) quit
The program is running.  Exit anyway? (y or n) y
Comment 6 Alan Matsuoka 2008-10-02 12:30:45 EDT
Created attachment 319262 [details]
dwarf-array5.f90
Comment 7 Jakub Jelinek 2008-10-02 14:13:15 EDT
Just looked at the first testcase, the problem is that it is buggy.
The existence of sub_test subroutine at toplevel doesn't bring in the prototype of the function into the MAIN__ scope (sorry if this is C/C++-ish nomenclature only), so MAIN__ and sub_test disagree about how the parameters are passed.  The callee
expects the first argument being passed through an array descriptor, the second just as a pointer to the first element and third one by reference to the integer.
The caller expects both arguments to be passed as pointers to first member.
You want
   interface
     subroutine sub_test(a_sub,c_sub,c_size)
       real,target  :: a_sub(:,:)
       integer      :: c_size
       real         :: c_sub(c_size,c_size/2)
     end subroutine sub_test
   end interface
after program test, then the testcase doesn't segfault.  I'll look at the generated debuginfo soon.
Comment 8 Jakub Jelinek 2008-10-03 07:36:13 EDT
E.g. 97-007r2.pdf says this in 12.3.1.1:
A procedure other than a statement function shall have an explicit interface if
...
  (2) The procedure has
...
       A dummy argument that is an assumed-shape array, a pointer, or a target,

Even after fixing the testcase, there are some debuginfo generation issues for the testcase, caused by variables referenced from contained function, I'm looking into it right now.
Comment 14 Eric Bachalo 2008-11-11 02:07:04 EST
A partial fix will be included in RHEL 5.3

The remainder of the work will take too long to be included in RHEL 5.3,  I am suggesting the remainder be looked at for RHEL 5.4
Comment 16 RHEL Product and Program Management 2009-03-26 13:26:54 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 17 Issue Tracker 2009-05-26 10:54:59 EDT
Here's what I've got with gcc44, gdb-6.8-35, and the original
dwarf-array.f90 program:

# rpm -q gcc44-gfortran
gcc44-gfortran-4.4.0-5.el5
# gfortran44 -g -o dwarf-array dwarf-array.f90 
# rpm -q gdb
gdb-6.8-35.el5

# gdb -q dwarf-array
(gdb) b 27
Breakpoint 1 at 0x400ccc: file dwarf-array.f90, line 27.
(gdb) b 9
Breakpoint 2 at 0x40084c: file dwarf-array.f90, line 9. (2 locations)
(gdb) r
Starting program: /root/dwarf-array 

Breakpoint 1, test_pass () at dwarf-array.f90:27
27	   call sub_test(yzap,yzap(:,2),2)
Current language:  auto; currently fortran
(gdb) ptype yzap
type = real(kind=4) (2,2)
(gdb) c
Continuing.

Breakpoint 2, sub_test (a_sub=warning: Range for type (null) has invalid
bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
(), c_sub=(), c_size=2) at dwarf-array.f90:9
9	   call contained_sub
(gdb) ptype a_sub
warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
type = warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
real(kind=4) (-279,-429861313)
(gdb) ptype b_sub
warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
type = warning: Range for type (null) has invalid bounds 1..-279
warning: Range for type array2_real(kind=4) has invalid bounds
1..-429861313
real(kind=4) (-279,-429861313)
(gdb) ptype c_sub
type = real(kind=4) (*,*)
(gdb) 




This event sent from IssueTracker by kbaxley 
 issue 224097
Comment 19 Jan Kratochvil 2009-06-02 09:34:00 EDT
Created attachment 346248 [details]
dwarf-array.f90 using allocatable yzap.

Currently I am not aware of GDB problems but rather see gfortran problems with both execution (and tus currently even with the debug info).
The original attachment dwarf-array.f90 should IMO print:
 a_sub   1.0000000       2.0000000       3.0000000       4.0000000    
but currently it prints only:
 a_sub
If I replace static yzap with allocatable yzap (this attachment) the program compiles OK but later SEGVs during its execution.
Comment 20 Jan Kratochvil 2009-06-02 09:39:28 EDT
Created attachment 346249 [details]
static-pass-as-dynamic.f90

Minimal reproducer which passes a(2) as p(:) but SEGVs.
It creates the raw data and its address passes as an array descriptor.

   integer :: a(2)
   a(1) = 1
  4008a3:       c7 45 f0 01 00 00 00    movl   $0x1,0xfffffffffffffff0(%rbp)
   a(2) = 2
  4008aa:       c7 45 f4 02 00 00 00    movl   $0x2,0xfffffffffffffff4(%rbp)
   call f(a)
  4008b1:       48 8d 45 f0             lea    0xfffffffffffffff0(%rbp),%rax
  4008b5:       48 89 c7                mov    %rax,%rdi
  4008b8:       b8 00 00 00 00          mov    $0x0,%eax
  4008bd:       e8 9a fe ff ff          callq  40075c <f_>

000000000040075c <f_>:
  40076a:       48 89 bd c8 fd ff ff    mov    %rdi,0xfffffffffffffdc8(%rbp) = %rbp - 568 = %rbp + 16 - 584

 <2><52>: Abbrev Number: 4 (DW_TAG_formal_parameter)
     DW_AT_name        : p      
     DW_AT_type        : <7c>   
     DW_AT_artificial  : 1      
     DW_AT_location    : 4 byte block: 91 b8 7b 6       (DW_OP_fbreg: -584; DW_OP_deref) = %rbp + 16 - 584

    Offset   Begin    End      Expression
    00000000 0040075c 0040088c (DW_OP_breg6: 16)        = %rbp + 16
    00000000 <End of list>

 <1><7c>: Abbrev Number: 7 (DW_TAG_array_type)
     DW_AT_name        : (indirect string, offset: 0x8e): array1_integer(kind=4)        
     DW_AT_data_location: 2 byte block: 97 6    (DW_OP_push_object_address; DW_OP_deref)
     DW_AT_type        : <a1>   
     DW_AT_sibling     : <a1>   
 <2><8c>: Abbrev Number: 8 (DW_TAG_subrange_type)
     DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22  (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus)
     DW_AT_stride      : 6 byte block: 97 23 18 6 34 1e         (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul)


Other (unrelated) seen minor issues:
* The `p' parameter should not be DW_AT_artificial.
* The `p' parameter should have a location list for its prologue, it is passed 
  in %rdi, not at the DWARF `DW_OP_fbreg: -536' on the very first instruction.
Comment 21 Jakub Jelinek 2009-06-08 09:24:04 EDT
The original testcase is just invalid and so are your testcases.
See e.g. 12.3.1.1 in J3/97-007R2:
"A procedure other than a statement function shall have an explicit interface if
        (1)  A reference to the procedure appears
             (a) With an argument keyword (12.4.1),
             (b) As a reference by its generic name (12.3.2.1),
             (c) As a defined assignment (subroutines only),
             (d) In an expression as a defined operator (functions only), or
             (e) In a context that requires it to be pure,
        (2)  The procedure has
             (a) An optional dummy argument,
             (b) A dummy argument that is an assumed-shape array, a pointer, or a target,
             (c) An array-valued result (functions only),
             (d) A result that is a pointer (functions only), or
             (e) A result whose character length parameter value is not assumed and not constant (character functions only), or
        (3)  The procedure is elemental.
"
In this case sub_test has implicit interface in MAIN__ and 2b) applies, sub_test has an assumed-shape dummy argument a_sub.  Just add:
@@ -19,6 +19,13 @@ contains
 end subroutine sub_test
 
 program test_pass
+   interface
+   subroutine sub_test(a_sub,c_sub,c_size)
+     real,target :: a_sub(:,:)
+     integer :: c_size
+     real :: c_sub(c_size,c_size/2)
+   end subroutine
+   end interface
    real :: yzap(2,2)
    yzap(1,1)=1.
    yzap(2,1)=2.
and it will work just fine.  Regarding your minor notes, both are known issues,
and the latter I've even mentioned in #c18.
Comment 22 Jan Kratochvil 2009-06-08 12:30:07 EDT
Comment on attachment 346249 [details]
static-pass-as-dynamic.f90

Thanks for the explanation.
This testcase of mine is therefore invalid according to Comment 21.

Original reproducer now works with the Comment 21 fix on:
gdb-6.8-36.el5.x86_64
gcc44-gfortran-4.4.0-5.el5.x86_64
(gdb) b sub_test
Breakpoint 1 at 0x400ac8: file dwarf-array-interfaced.f90, line 1.
(gdb) r
Starting program: /root/jkratoch/redhat/dwarf-array-interfaced 
Breakpoint 1, sub_test (a_sub=(( 1, 2) ( 3, 4) ), c_sub=(), c_size=2) at dwarf-array-interfaced.f90:1
1	subroutine sub_test(a_sub,c_sub,c_size)
Current language:  auto; currently fortran
(gdb) ptype a_sub
type = real(kind=4) (2,2)
(gdb) ptype c_sub
type = real(kind=4) (*,*)
(gdb) p a_sub
$1 = (( 1, 2) ( 3, 4) )
(gdb) p c_sub
$2 = ()
(gdb) p c_sub(1,1)
$3 = 3
(gdb) p c_sub(2,1)
$4 = 4
Comment 23 Ben Woodard 2009-06-08 14:27:27 EDT
So should the compiler emit an error with the bad test case rather than allowing the generation of bogus code.
Comment 24 Issue Tracker 2009-08-19 11:44:48 EDT
Event posted on 2009-08-19 08:44 PDT by woodard

see: IT#330319 BZ#517574 and IT#330327 BZ#517578 

Evidently the fact that the compiler is failing to even WARN when the
required interface specification is passed is causing problems for the
LLNL developers transitioning their code from F77 to F90. Therefore, I
believe that we need to make the compiler more strict in enforcing the
requirement layed out in: 12.3.1.1 in J3/97-007R2.


This event sent from IssueTracker by woodard 
 issue 224097
Comment 25 Jakub Jelinek 2009-08-19 11:47:53 EDT
GCC 4.5 -fwhole-file mode allows such kinds of warnings, but the changes are so huge and risky that they aren't really backportable to 4.4.  So I'm afraid this is an item for RHEL7.
Comment 27 RHEL Product and Program Management 2009-11-06 14:28:08 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 34 RHEL Product and Program Management 2010-04-29 11:28:03 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.