Approximatrix Forums — GNU Fortran Compiler documentation version

Re: GNU Fortran Compiler documentation version

null@example.com (jeff) — Thu, 15 Jun 2017 16:50:14 +0000

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

Re: GNU Fortran Compiler documentation version

null@example.com (jeff) — Sat, 10 Jun 2017 17:23:11 +0000

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

null@example.com (baf1) — Fri, 09 Jun 2017 02:32:34 +0000

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

Re: GNU Fortran Compiler documentation version

null@example.com (jeff) — Wed, 31 May 2017 12:24:19 +0000

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

null@example.com (davidb) — Tue, 30 May 2017 05:53:01 +0000

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

null@example.com (jeff) — Thu, 18 May 2017 11:32:34 +0000

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

null@example.com (baf1) — Thu, 18 May 2017 03:53:48 +0000

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

null@example.com (jeff) — Wed, 17 May 2017 16:45:06 +0000

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

null@example.com (Klaus Asmus) — Wed, 17 May 2017 10:50:33 +0000

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

null@example.com (drfrank) — Tue, 16 May 2017 21:23:18 +0000

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

null@example.com (Klaus Asmus) — Tue, 16 May 2017 20:43:06 +0000

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

null@example.com (jeff) — Tue, 16 May 2017 12:15:07 +0000

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

null@example.com (Klaus Asmus) — Mon, 15 May 2017 06:56:55 +0000

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

null@example.com (jeff) — Sun, 14 May 2017 14:11:04 +0000

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

null@example.com (baf1) — Sun, 14 May 2017 05:22:42 +0000

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.