Bug 158232 - f95 compiler dies compiling fortran 90 code with LAM MPI
f95 compiler dies compiling fortran 90 code with LAM MPI
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc4 (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-19 14:59 EDT by Sam Adams
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 4.0.0-9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-03 12:10:42 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)
lam mpi wrapper fortran compiler (60.89 KB, application/octet-stream)
2005-05-23 15:57 EDT, Sam Adams
no flags Details
Makefile (864 bytes, text/plain)
2005-05-23 15:58 EDT, Sam Adams
no flags Details
fortran code in question (4.24 KB, text/plain)
2005-05-23 15:59 EDT, Sam Adams
no flags Details
incident_field.mod (10.69 KB, application/octet-stream)
2005-05-23 16:55 EDT, Sam Adams
no flags Details
commona.mod (50.69 KB, application/octet-stream)
2005-05-23 16:56 EDT, Sam Adams
no flags Details
aitoc.mod (662 bytes, application/octet-stream)
2005-05-23 16:57 EDT, Sam Adams
no flags Details

  None (edit)
Description Sam Adams 2005-05-19 14:59:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
I was trying to build some of our parallel Fortran 90 code, and it keeps dieing with the following error.  Prior to gcc 4 we had been using the Lahey Fortran 90 compiler without problem.  My goal is to get our Fortran code to work with gcc 4 so we can dump Lahey.  If you need, we can provide some source code.

Note: "mpif77" is just lam-mpi's wraper around f95 to make sure all of the options are there correctly. 

[root@x4 jz]# make
mpif77  -c orig_pw.f90
orig_pw.f90:109: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:624
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
mpif77: No such file or directory
make: *** [orig_pw.o] Error 1
[root@x4 jz]#

Version-Release number of selected component (if applicable):
gcc-gfortran-4.0.0-2

How reproducible:
Always

Steps to Reproduce:
1.mpif77  -c orig_pw.f90
2.
3.
  

Actual Results:  [root@x4 jz]# make
mpif77  -c orig_pw.f90
orig_pw.f90:109: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:624
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
mpif77: No such file or directory
make: *** [orig_pw.o] Error 1
[root@x4 jz]#

Expected Results:  should have complied cleanly

Additional info:

We are using lam-mpi 7.1.1
Comment 1 Jakub Jelinek 2005-05-19 16:41:13 EDT
Please attach orig_pw.f90 and sh -x mpif77  -c orig_pw.f90
output (so that I know what options were actually passed to gfortran.
Comment 2 Sam Adams 2005-05-23 15:57:07 EDT
Created attachment 114739 [details]
lam mpi wrapper fortran compiler
Comment 3 Sam Adams 2005-05-23 15:58:28 EDT
Created attachment 114740 [details]
Makefile

this is the Makefile used
Comment 4 Sam Adams 2005-05-23 15:59:07 EDT
Created attachment 114741 [details]
fortran code in question
Comment 5 Jakub Jelinek 2005-05-23 16:30:24 EDT
Can you please also attach the modules it uses (either source, or
incident_field.mod, commona.mod, aitoc.mod, or both)?
Comment 6 Sam Adams 2005-05-23 16:55:46 EDT
Created attachment 114747 [details]
incident_field.mod
Comment 7 Sam Adams 2005-05-23 16:56:24 EDT
Created attachment 114748 [details]
commona.mod
Comment 8 Sam Adams 2005-05-23 16:57:52 EDT
Created attachment 114749 [details]
aitoc.mod
Comment 9 Sam Adams 2005-05-23 17:00:23 EDT
I am not sure if the AF would be keen if I stuck the rest of the source code on
the web, but I hope the moduals are sufficent.  
Comment 10 Jakub Jelinek 2005-05-23 17:08:47 EDT
Thanks, I can now reproduce it.
Comment 11 Jakub Jelinek 2005-05-23 18:20:47 EDT
module modice
contains
  real function foo ()
  foo = 6
  end function
end module modice
function foo ()
  use modice
  implicit none
end function foo

crashes the same way.
Comment 12 Sam Adams 2005-05-24 10:47:47 EDT
So, does this have to do with ambiguity in the code that needs to be fixed, or
is it a bug in the Fortran compiler.  
Comment 13 Jakub Jelinek 2005-05-24 15:35:12 EDT
Have you ever tried compiling that code with other Fortran90 compiler?
My Fortran knowledge is limited, but I'd say that the code is invalid.
When using implicit none, a type must be given to encode_log_file_name, but
that is missing.  It seems to me that encode_log_file_name_str was just meant
to be called encode_log_file_name in the 2 occurences of encode_log_file_name_str
in that file.
Now, of course gfortran shouldn't issue an internal compiler error about this,
but should issue an error.
Comment 14 Sam Adams 2005-06-03 12:03:44 EDT
(In reply to comment #13)
> Have you ever tried compiling that code with other Fortran90 compiler?

We currently compile this code with Lahey's Fortran 95 compiler without problem.
 It dosn't seem to mind how the code is written, but that is not to say that it
is not invalid.
===using Lahey===
The orignal version has the variable "encode_log_file_name_str" as just
"encode_log_file_name", or in other words, the name of the function.  From what
I have read, that is the correct way to do a return value in fortran.  If you
use the variable "encode_log_file_name_str", this will also work if it is
assinged to "encode_log_file_name" before the function returns.  If the code is
as I have if posted in this bug, it will compile, but with a warning that the
function has no return value.
===using gfortran===
The first two forementioned ways, will produce an error about ambiguity.  The
last produces an internal compiler error. 

> My Fortran knowledge is limited, but I'd say that the code is invalid.
> When using implicit none, a type must be given to encode_log_file_name, but
> that is missing.  It seems to me that encode_log_file_name_str was just meant
> to be called encode_log_file_name in the 2 occurences of encode_log_file_name_str
> in that file.

I would guess that my Fortran knowlage is even more limited than yours, so I am
not really sure what the correct syntax is, but from what I have read from my
Fortran book, it seems that with fortran the return value of a function goes
into a variable of the same name as the function.  Although, I am not certain. 
I guess I need to get more knowlagable of Fortran. I probably need to do a good
scrub of the code, and break it up.  Right now the the program is over 16k lines
of Fortran code.  I would like to just dump fortran all together and use C.

> Now, of course gfortran shouldn't issue an internal compiler error about this,
> but should issue an error.

Comment 15 Jakub Jelinek 2005-06-03 12:10:42 EDT
The ICE has been fixed in gcc-4.0.0-9, which is now in rawhide.
Comment 16 Sam Adams 2005-06-03 14:07:42 EDT
what is ICE, and rawhide?

(In reply to comment #15)
> The ICE has been fixed in gcc-4.0.0-9, which is now in rawhide.
> 

Comment 17 Jakub Jelinek 2005-06-03 14:13:52 EDT
ICE is Internal Compiler Error.
rawhide is Fedora development tree,
http://download.fedora.redhat.com/pub/fedora/linux/core/development/
(or preferrably one of its mirrors).

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