Bug 743999

Reporter, could you please describe us what you have done to get to this point, and how we can reproduce this issue here? Is there anything special about your system, network, configuration which we need to replicate here in order to reproduce your problem please?

It will be more helpful if you can provide a fortran source file.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Hi Robert,

I'm trying to regenerate the error you reported with your attached file. I'm getting following error with that file.

Fatal Error: Can't open module file 'global_data.mod' for reading at (1): No such file or directory.

I know this is very much N00b thing, I know that I didn't install any gfortran modules. If you can provide all the steps (including installing the modules) to get the same error you mentioned, then It will be helpful to me to reproduce in my test environment and I can conform that the error exists in latest gfortran builds for F16 i386. It will be helpful for maintainer to narrow down the root cause.

Thanks,
Mohan R



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Created attachment 532450 [details]
data block 1

Created attachment 532451 [details]
Data block 2

Created attachment 532452 [details]
Data Block 3

Created attachment 532459 [details]
Data Block 4

Stand alone multiprocessor x86_64 systems.  No network.



System compilation is fine for CENTOS 5.3 and CENTOS 6.0 with versions 4.3.2-7.el5 and 4.4.4-13.el6 of the compilers along with glibc 2.5-34.el5 and 2.12-1.7.el6 respectively.

Looks like there is some change in the expected arguments for the system functions signal and pttyin in the latest compilers.

INTEL fortran uses the statements

      integer(ki4), external :: signal
      k=signal(int(2,ki4),pttyin,int(-1,ki4))

G95 fortran uses the form


      integer(ki4), external :: signal
      k=signal(int(2,ki4),pttyin)

(In reply to comment #7)
> System compilation is fine for CENTOS 5.3 and CENTOS 6.0 with versions
> 4.3.2-7.el5 and 4.4.4-13.el6 of the compilers along with glibc 2.5-34.el5 and
> 2.12-1.7.el6 respectively.

I tried to reproduce the issue and I failed; I couldn't use the full example as the file providing "global_parameters" is not attached, but it is needed by the most examples. I tried to generate a failing test case using only the example of comment 0 (attachment 526757 [details]), but that failed with the GCC 4.5/4.6/4.7 versions I have installed here.


> Looks like there is some change in the expected arguments for the system
> functions signal and pttyin in the latest compilers.
> 
> INTEL fortran uses the statements
>       integer(ki4), external :: signal
>       k=signal(int(2,ki4),pttyin,int(-1,ki4))
> 
> G95 fortran uses the form
>       integer(ki4), external :: signal
>       k=signal(int(2,ki4),pttyin)

I don't think so. The version of gfortran has the same arguments as g95, cf. 
http://gcc.gnu.org/onlinedocs/gfortran/SIGNAL.html


(In reply to comment #0)
> ../../../v270/src/mcnpx/mcnpf/ttyint.F: In function ‘ttyint’:
> ../../../v270/src/mcnpx/mcnpf/ttyint.F:20:0: internal compiler error: in
> gfc_typenode_for_spec, at fortran/trans-types.c:1019

The error message states that the error occurs in line 20 of the file ttyint.F. However, the attachment only has 12 lines. Looking at the source code, the problem is related to some variable or function which did not get (explicitly or implicitly) typed - unfortunately, the error message does not tell the name of that object.

Tobias 
The attachment has the alternate paths for many alternate systems preprocessed out per submission outline while the error number of the output refers to the original code.

Change from a function statement to a subroutine call and all is well for gfortran.
      
      k=signal(int(2,ki4),pttyin)                                      

===>
      call signal(int(2,ki4),pttyin)

Created attachment 537728 [details]
Similar subroutine that works leading to patch of original -- NOTE x86_64

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping