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
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.
Created attachment 114739 [details] lam mpi wrapper fortran compiler
Created attachment 114740 [details] Makefile this is the Makefile used
Created attachment 114741 [details] fortran code in question
Can you please also attach the modules it uses (either source, or incident_field.mod, commona.mod, aitoc.mod, or both)?
Created attachment 114747 [details] incident_field.mod
Created attachment 114748 [details] commona.mod
Created attachment 114749 [details] aitoc.mod
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.
Thanks, I can now reproduce it.
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.
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.
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.
(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.
The ICE has been fixed in gcc-4.0.0-9, which is now in rawhide.
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. >
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).