For discussions of all Approximatrix products and related software
You are not logged in. Please login or register.
Approximatrix Forums → Bug Reports → 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.
Ah yes, it appears the build system is pulling quite an old version for some reason. I'll see that it's fixed.
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
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 rowprintI don't seem to be getting a runtime error. Is there a possibility you're overrunning array bounds?
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
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
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
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!
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.
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.
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. 
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...
Just a note that the latest release still has the very old documentation
I am aware. Producing a CHM file from GNU documentation is not a trivial task, and we're working on the problem.
Version 2.38 should include proper documentation versions. Sorry for the trouble!
Approximatrix Forums → Bug Reports → GNU Fortran Compiler documentation version
Powered by PunBB, supported by Informer Technologies, Inc.