[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[kevinecahill at gmail dot com]

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

--- Comment #2 from Kevin Cahill <kevinecahill at gmail dot com> ---
Nonsense.
I included the linpack subroutines explicitly.
Look at my fortan code.
Best wishes,
Kevin

Kevin Cahill
Professor of Physics & Astronomy
Physics Dept. 1919 Lomas NE, MSC 07 4220 
University of New Mexico 
Albuquerque, NM 87131-0001

kevinecahill@gmail.com   cahill@unm.edu   505 205 5448  



On Jul 27, 2014, at 1:39 PM, pinskia at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61928
> 
> Andrew Pinski <pinskia at gcc dot gnu.org> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Version|unknown                     |4.9.0
> 
> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> You are not linking with the linpack library.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
With you attachment, I am getting this:

/tmp/ccBACux5.o: In function `dgefa.2334':
pr61928.f90:(.text+0x1282): undefined reference to `idamax_'
/tmp/ccBACux5.o: In function `dgedi.2345':
pr61928.f90:(.text+0x19fa): undefined reference to `dscal_'
pr61928.f90:(.text+0x1aba): undefined reference to `daxpy_'
pr61928.f90:(.text+0x1c2d): undefined reference to `daxpy_'
pr61928.f90:(.text+0x1cbd): undefined reference to `dswap_'
collect2: error: ld returned 1 exit status

I did not link this with anything. The four last listed procedures listed are
not defined in the attachment, although used.

In subroutine dgefa, idamax is defined as an integer. If I delete that line,
the undefined reference to idamax_ goes away.  The last four references I
suspect are in the BLAS library that I am not linked to at the moment.

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[kevinecahill at gmail dot com]

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

--- Comment #4 from Kevin Cahill <kevinecahill at gmail dot com> ---
Thanks.
That sounds sensible.
I will check it.

Best wishes,
Kevin

Kevin Cahill
Professor of Physics & Astronomy
Physics Dept. 1919 Lomas NE, MSC 07 4220 
University of New Mexico 
Albuquerque, NM 87131-0001

kevinecahill@gmail.com   cahill@unm.edu   505 205 5448  



On Jul 27, 2014, at 3:10 PM, jvdelisle at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61928
> 
> Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |jvdelisle at gcc dot gnu.org
> 
> --- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> With you attachment, I am getting this:
> 
> /tmp/ccBACux5.o: In function `dgefa.2334':
> pr61928.f90:(.text+0x1282): undefined reference to `idamax_'
> /tmp/ccBACux5.o: In function `dgedi.2345':
> pr61928.f90:(.text+0x19fa): undefined reference to `dscal_'
> pr61928.f90:(.text+0x1aba): undefined reference to `daxpy_'
> pr61928.f90:(.text+0x1c2d): undefined reference to `daxpy_'
> pr61928.f90:(.text+0x1cbd): undefined reference to `dswap_'
> collect2: error: ld returned 1 exit status
> 
> I did not link this with anything. The four last listed procedures listed are
> not defined in the attachment, although used.
> 
> In subroutine dgefa, idamax is defined as an integer. If I delete that line,
> the undefined reference to idamax_ goes away.  The last four references I
> suspect are in the BLAS library that I am not linked to at the moment.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-08-02
                 CC|                            |kargl at troutmask dot apl.washing
                   |                            |ton.edu
     Ever confirmed|0                           |1

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Reduced test

program Z0linpack ! with LINPACK's dgedi and dgefa, and SLATEC's idamax
  implicit none
  integer( kind = 4 )::n
  integer( kind = 4 )::info,lda
  integer( kind = 4 ),allocatable:: IPVT(:)
  integer( kind = 4 ),parameter::ns=10,job=10
  doubleprecision,dimension(:,:),allocatable::A
  call dgefa ( A, lda, n, ipvt, info )
contains

  subroutine dgefa ( a, lda, n, ipvt, info )

    implicit none

    integer ( kind = 4 ) lda
    integer ( kind = 4 ) n

    real ( kind = 8 ) a(lda,n)
    integer ( kind = 4 ) info
    integer ( kind = 4 ) ipvt(n)
    integer ( kind = 4 ) idamax
    integer ( kind = 4 ) k
    integer ( kind = 4 ) l

    k = 1
       l = idamax ( n-k+1, a(k,k), 1 ) + k - 1

    return
  end 

function idamax ( n, dx, incx )

  implicit none

  real ( kind = 8 ) dx(*)
  integer ( kind = 4 ) idamax
  integer ( kind = 4 ) incx
  integer ( kind = 4 ) n

  idamax = 0

  return
end 

end program Z0linpack

[Book15] f90/bug% gfc pr61928_red.f90
Undefined symbols for architecture x86_64:
  "_idamax_", referenced from:
      _dgefa.2338 in cc23XSKJ.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

However if I comment the line

    integer ( kind = 4 ) idamax

in the subroutine dgefa, the code compiles and links without error. AFAIK the
subroutine dgefa and the function idamax are not designed to be internal
procedures.
It seems that with the above line gfortran assumes that idamax is an external
function and not the internal one; however I don't know where to find it in the
standard.

I suspect that this PR should be closed as invalid, but I let someone else to
make the call!

Note that compiling the code with gfortran 4.5 gives a lot of errors, starting
with

pr61928_red.f90:29.2:

  end 
  1
Error: END SUBROUTINE statement expected at (1)
pr61928_red.f90:31:

function idamax ( n, dx, incx )
1
Error: Unclassifiable statement at (1)
...

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
My thinking, right or wrong, is that the code is invalid because idamax is
defined as an integer which conflicts with the subroutine name.

Ifort gives the exact same error. (Ifort also insists that the end statements
for the function and subroutine state "end function" and "end subroutine" but
that is a separate issue.)

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #7 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #6)
> My thinking, right or wrong, is that the code is invalid because idamax is
> defined as an integer which conflicts with the subroutine name.
                                                 ^^^^^^^^^^ internal procedure

> Ifort gives the exact same error. (Ifort also insists that the end
> statements for the function and subroutine state "end function" and "end
> subroutine" but that is a separate issue.)

Also NAG agrees with you.  And NAG is almost always right ;-)

I tend do believe that F2008 section 12.2.2 applies here:

- The declaration in subroutine dgefa makes it an *external* procedure,

- The subprogram in the scope of main makes it a *internal* procedure.

Note that:

"... Internal subprograms are the same as external subprograms except
that the name of the internal procedure is not a global identifier,
an internal subprogram shall not contain an ENTRY statement, and the
internal subprogram has access to host entities by host association."

So gfortran, Ifort and NAG are right and the original code is invalid.
>From gcc-bugs-return-457623-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 02 18:27:22 2014
Return-Path: <gcc-bugs-return-457623-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1562 invoked by alias); 2 Aug 2014 18:27:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1510 invoked by uid 48); 2 Aug 2014 18:27:18 -0000
From: "latlon90180+gcc_bugzilla at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61999] New: `gfc_simplify_dot_product` causes ICE for constant arguments
Date: Sat, 02 Aug 2014 18:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: latlon90180+gcc_bugzilla at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61999-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg00120.txt.bz2
Content-length: 989

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida999

            Bug ID: 61999
           Summary: `gfc_simplify_dot_product` causes ICE for constant
                    arguments
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: latlon90180+gcc_bugzilla at gmail dot com

Following code leads `gcc-mp-4.8 (MacPorts gcc48 4.8.2_2) 4.8.2` and `GNU
Fortran (MacPorts gcc47 4.7.3_5) 4.7.3` to ICE.


```fortran
program main
   use, intrinsic:: iso_fortran_env, only: output_unit

   implicit none

   write(output_unit, *) dot_product([1, 2], [2.0, 3.0])

   stop
end program main
```

```
f951: internal compiler error: in gfc_simplify_dot_product, at
fortran/simplify.c:1886

f951: internal compiler error: Abort trap: 6
gfortran-mp-4.8: internal compiler error: Abort trap: 6 (program f951)
Abort trap: 6
```

[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>From comment 7 (posted more than four months ago) closing as INVALID.