Topic: GNU Fortran Compiler documentation version

The gfortran compiler reference manual provided by the SF install under Windows is out of date compared to the version of the compiler installed.  Copyright on the installed manual is 2014, so I suspect it is for Version 5.x of gfortran.

Re: GNU Fortran Compiler documentation version

Ah yes, it appears the build system is pulling quite an old version for some reason.  I'll see that it's fixed.

Jeff Armstrong
Approximatrix, LLC

Re: GNU Fortran Compiler documentation version

after installation of the newest version I got the following  run time error:
At line 86 of file .\Ins_del.f90
Internal Error: get_unit(): Bad internal unit KIND

Error termination.
.....
This is caused by an internal write as follows:

DO i =  maxrow, cel%r+1, -1 ! move rows by one up first untill new maxrow
    row(i+scroll)= row(i+scroll-1)
    Write(row(i+scroll)(:3),'(I3)') i+scroll!+1
end do

Row() is declared in a module used by ins_del:
Character(len=maxcols) row(maxrows)   

Is this a bug??
regards, Klaus

Re: GNU Fortran Compiler documentation version

Klaus,

I can't replicate this error in a simple program like you've described.  My code is:

program rowprint
implicit none

    character(len=30) row(30)
    integer::i
    
    do i = 1, 30
        write(row(i)(:3), '(I3)') i
    end do
    
    do i=1,10
        print *, trim(row(i))
    end do
    
end program rowprint

I don't seem to be getting a runtime error.  Is there a possibility you're overrunning array bounds?

Jeff Armstrong
Approximatrix, LLC

Re: GNU Fortran Compiler documentation version

Hello Jeff,
I looked to the array bounds and cannot find any error.
Next I installed SF2.36 again and every thing was OK.
May be the problem is that I did compile the main program with 2.37 and did not compile the library again!?!?
Because also the GNU version is updated, I can imagine that all source should be recompiled ....
I'll try to compile both tomorrow or in the next day's with 2.37
Regards, Klaus

Re: GNU Fortran Compiler documentation version

For whatever it's worth, I received a WRITE() error in a previously compile SF 2.36 program when trying to run it under SF 2.37.
However, once the project was 'cleaned' and recompiled, it ran just fine.

Frank

Re: GNU Fortran Compiler documentation version

Thanks for that info!
After installing SF 2.37 again and compilation of all files including the library the program was OK!
Remark for every body: Recompile all your source again after installing SF 2.37 containing also The actual GNU Fortran version!

Regards Klaus

Re: GNU Fortran Compiler documentation version

Interesting discussion...  It seems that an incompatible change within the runtime library led to this problem.  These issues can occur when we update the compiler.  I'm glad the problem seems resolved!

Jeff Armstrong
Approximatrix, LLC

Re: GNU Fortran Compiler documentation version

The situation you describe is almost always true with gfortran when updating to a new version (for example version 6.x to 7.x in this case).  The .mod files are also subject to a change in format with version changes, so best practice is to completely rebuild a project when gfortran releases a new point release version.

Re: GNU Fortran Compiler documentation version

The module versioning hasn't changed in a few releases, thankfully. For a while, GNU Fortran module versions would increment every minor release, which is very frustrating when attempting to provide package manager support.

Jeff Armstrong
Approximatrix, LLC

11 (edited by davidb 2017-05-30 05:58:16)

Re: GNU Fortran Compiler documentation version

jeff wrote:

Interesting discussion...  It seems that an incompatible change within the runtime library led to this problem.  These issues can occur when we update the compiler.  I'm glad the problem seems resolved!

Object/module files can become incompatible when the version changes. You could add the compiler version to the dependency tree. Then when the version changes a build would force a rebuild of all source files.

Similarly, when the option string changes a rebuild should be forced.

And could we have a rebuild menu item (and function key), instead of having to click clean/build. smile

--
David

Re: GNU Fortran Compiler documentation version

Object/module files can become incompatible when the version changes. You could add the compiler version to the dependency tree. Then when the version changes a build would force a rebuild of all source files.

Module versions actually haven't changed in a while, thankfully.  The issue is just changes to the runtime library.  I'll look into possibly storing a compiler version, but the compiler upgrades aren't particularly frequent.

Similarly, when the option string changes a rebuild should be forced.

I think the user should be asked, but it isn't a bad idea.  There are many projects when a rebuild is not a trivial amount of time, and users may not wish to do this.

And could we have a rebuild menu item (and function key), instead of having to click clean/build.

Finding function keys that are available is always a bit hard, but I'll see...

Jeff Armstrong
Approximatrix, LLC

13 (edited by baf1 2017-06-09 02:32:49)

Re: GNU Fortran Compiler documentation version

Just a note that the latest release still has the very old documentation

Re: GNU Fortran Compiler documentation version

I am aware.  Producing a CHM file from GNU documentation is not a trivial task, and we're working on the problem.

Jeff Armstrong
Approximatrix, LLC

Re: GNU Fortran Compiler documentation version

Version 2.38 should include proper documentation versions.  Sorry for the trouble!

Jeff Armstrong
Approximatrix, LLC