Created attachment 53296 [details] Main program (to be compiled with latest release, e.g. 11.2.0) Fortran subroutine using INQUIRE(UNIT=..., OPENED=...) compiled with gfortran 4.9.2 fails with bus error when linked by gfortran 11.2.0 to main program. Works OK if subroutine recompiled with gfortran 11.2.0; clearly a run-time library version skew; possibly a library versioning bug. If not a bug, and instead a fact of life of libfortran evolution, there should be better user-level documentation of when library incompatibilities happen, ideally in the gfortran/news wiki. Then those who provide subroutine packages for general use can alert their users of runtime library compatibility issues. The only gfortran documentation I've seen discussing library version incompatibilities is in https://gcc.gnu.org/wiki/LibgfortranAbiCleanup which mentions the ABI being broken in version 7 and again in version 8; I wouldn't quite call this user-level information. Target: x86_64-apple-darwin18.7.0 Debug output: #/usr/local/bin/gfortran -g -c -o /tmp/inqtest.o /tmp/inqtest.f # gfortran 4.9.2 #gfortran -g -o /tmp/inqmain /tmp/inqmain.o /tmp/inqtest.o # gfortran 11.2.0 #gdb /tmp/inqmain GNU gdb (GDB) 9.2-macos-20220204 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin18.7.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /tmp/inqmain... (gdb) run Starting program: /private/tmp/inqmain [New Thread 0x2603 of process 92337] [New Thread 0x1803 of process 92337] [New Thread 0x2303 of process 92337] Thread 3 received signal SIGBUS, Bus error. 0x00000001002e6fe5 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib (gdb) where #0 0x00000001002e6fe5 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib #1 0x00000001002e7f35 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib #2 0x0000000100000d55 in zgtfun (nfun=19, nerr=0) at /tmp/inqtest.f:10 #3 0x0000000100000c83 in MAIN__ () at /tmp/inqmain.f:6 (gdb) up #1 0x00000001002e7f35 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib (gdb) up #2 0x0000000100000d55 in zgtfun (nfun=19, nerr=0) at /tmp/inqtest.f:10 10 inquire(unit=nfun,opened=lopen) (gdb) q A debugging session is active. Inferior 1 [process 92337] will be killed. Quit anyway? (y or n) y #
Created attachment 53297 [details] main program (to be compiled with latest release, e.g. 11.2.0)
Created attachment 53298 [details] subroutine (to be compiled with older libfortran)
That first attachment contains both parts of the code (main, subroutine). The later ones are the individual pieces.
I think the fix for PR83036 (INQUIRE specifier NEXTREC is a 4-byte integer, should be 8), which changed the layout of struct st_parameter_inquire, could explain what you observe. I have no solution to your problem other than recommending not doing what you did: mix vastly different compiler versions with legacy code. You would have been warned if you used modern Fortran with modules. I bet that most other compilers require (recommend or advise) recompilation of legacy code without explaining in detail which intrinsic might be affected.
I think this should be closed. Dont mix libraries.
One last comment about this issue. I maintain and distribute a Fortran subroutine package to users. In my experience, most of them are unaware that Fortran compilers evolve over time, and that the compiler used to build the subroutine package might not be the same version that they have installed. It seems that simple form of link-time version control might alert them to the problem, and avoid spurious problem reports. Would not a reference to a symbol in the run-time library dropped into compiled code when a library routine is used solve the problem? If the symbol definition changes when the library changes, then it would be impossible to link old code with an incompatible run-time library.
I don't think that is a bad idea. I realize that this comes up often enough to consider some solution.