[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
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.
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
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
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
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 identiļ¬er, 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.
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
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.
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
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 kevinecah...@gmail.com cah...@unm.edu 505 205 5448 On Jul 27, 2014, at 1:39 PM, pinskia at gcc dot gnu.org gcc-bugzi...@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
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
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 kevinecah...@gmail.com cah...@unm.edu 505 205 5448 On Jul 27, 2014, at 3:10 PM, jvdelisle at gcc dot gnu.org gcc-bugzi...@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.
