Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158232 - f95 compiler dies compiling fortran 90 code with LAM MPI
Summary: f95 compiler dies compiling fortran 90 code with LAM MPI
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc4
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-19 18:59 UTC by Sam Adams
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 4.0.0-9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-03 16:10:42 UTC


Attachments (Terms of Use)
lam mpi wrapper fortran compiler (deleted)
2005-05-23 19:57 UTC, Sam Adams
no flags Details
Makefile (deleted)
2005-05-23 19:58 UTC, Sam Adams
no flags Details
fortran code in question (deleted)
2005-05-23 19:59 UTC, Sam Adams
no flags Details
incident_field.mod (deleted)
2005-05-23 20:55 UTC, Sam Adams
no flags Details
commona.mod (deleted)
2005-05-23 20:56 UTC, Sam Adams
no flags Details
aitoc.mod (deleted)
2005-05-23 20:57 UTC, Sam Adams
no flags Details

Description Sam Adams 2005-05-19 18:59:24 UTC
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 20:41:13 UTC
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 19:57:07 UTC
Created attachment 114739 [details]
lam mpi wrapper fortran compiler

Comment 3 Sam Adams 2005-05-23 19:58:28 UTC
Created attachment 114740 [details]
Makefile

this is the Makefile used

Comment 4 Sam Adams 2005-05-23 19:59:07 UTC
Created attachment 114741 [details]
fortran code in question

Comment 5 Jakub Jelinek 2005-05-23 20:30:24 UTC
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 20:55:46 UTC
Created attachment 114747 [details]
incident_field.mod

Comment 7 Sam Adams 2005-05-23 20:56:24 UTC
Created attachment 114748 [details]
commona.mod

Comment 8 Sam Adams 2005-05-23 20:57:52 UTC
Created attachment 114749 [details]
aitoc.mod

Comment 9 Sam Adams 2005-05-23 21:00:23 UTC
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 21:08:47 UTC
Thanks, I can now reproduce it.

Comment 11 Jakub Jelinek 2005-05-23 22:20:47 UTC
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 14:47:47 UTC
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 19:35:12 UTC
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 16:03:44 UTC
(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 16:10:42 UTC
The ICE has been fixed in gcc-4.0.0-9, which is now in rawhide.


Comment 16 Sam Adams 2005-06-03 18:07:42 UTC
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 18:13:52 UTC
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.