Approximatrix Forums — GNU Fortran Compiler documentation version

Re: GNU Fortran Compiler documentation version

2017-06-15T16:50:14Z

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

Re: GNU Fortran Compiler documentation version

2017-06-10T17:23:11Z

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

Re: GNU Fortran Compiler documentation version

2017-06-09T02:32:34Z

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

Re: GNU Fortran Compiler documentation version

2017-05-31T12:24:19Z

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...

Re: GNU Fortran Compiler documentation version

2017-05-30T05:53:01Z

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.

Re: GNU Fortran Compiler documentation version

2017-05-18T11:32:34Z

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.

Re: GNU Fortran Compiler documentation version

2017-05-18T03:53:48Z

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

2017-05-17T16:45:06Z

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!

Re: GNU Fortran Compiler documentation version

2017-05-17T10:50:33Z

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

2017-05-16T21:23:18Z

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

2017-05-16T20:43:06Z

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

2017-05-16T12:15:07Z

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?

Re: GNU Fortran Compiler documentation version

2017-05-15T06:56:55Z

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

2017-05-14T14:11:04Z

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

GNU Fortran Compiler documentation version

2017-05-14T05:22:42Z

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.