szaghi
Build failure with gfortran-14: `Error: Type mismatch in argument 'mem_free' at (1); passed INTEGER(4) to INTEGER(8)`
:info:build [ 1%] Building Fortran object src/lib/CMakeFiles/PENF.dir/penf_allocatable_memory.F90.o
:info:build cd /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/build/src/lib && /opt/local/bin/gfortran-mp-14 -D_ASCII_SUPPORTED -D_UCS4_SUPPORTED -pipe -Os -m32 -mmacosx-version-min=10.6 -J../../modules -c /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90 -o CMakeFiles/PENF.dir/penf_allocatable_memory.F90.o
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1941:47:
:info:build 1941 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_free' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1941:47:
:info:build 1941 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_total' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1947:47:
:info:build 1947 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_free' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1947:47:
:info:build 1947 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_total' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1901:47:
:info:build 1901 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_free' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1901:47:
:info:build 1901 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_total' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1906:47:
:info:build 1906 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_free' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1906:47:
:info:build 1906 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_total' at (1); passed INTEGER(4) to INTEGER(8)
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/PENF-1.2.3/src/lib/penf_allocatable_memory.F90:1862:47:
:info:build 1862 | call get_memory_info(mem_total, mem_free)
:info:build | 1
:info:build Error: Type mismatch in argument 'mem_free' at (1); passed INTEGER(4) to INTEGER(8)
. . .
:info:build Error: Type mismatch in argument 'mem_total' at (1); passed INTEGER(4) to INTEGER(8)
:info:build make[2]: *** [src/lib/CMakeFiles/PENF.dir/penf_allocatable_memory.F90.o] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_PENF/PENF/work/build'
:info:build make[1]: *** [src/lib/CMakeFiles/PENF.dir/all] Error 2
Hi @barracuda156
I am sorry for the delay; I have been very busy.
I am trying to reproduce your error, but I think it is strictly related to the cmake building, because with FoBiS I cannot reproduce it.
┌╼ stefano@adam(06:19 PM Wed May 14) on master
├───╼ ~/fortran/PENF 18 files, 228Kb
└──────╼ FoBiS.py build -mode static-gnu
Builder options
Directories
Building directory: "static"
Compiled-objects .o directory: "static/obj"
Compiled-objects .mod directory: "static/mod"
Compiler options
Vendor: "gnu"
Compiler command: "gfortran"
Module directory switch: "-J"
Compiling flags: "-c -frealloc-lhs -O2"
Linking flags: "-O2"
Preprocessing flags: ""
Coverage: False
Profile: False
Preprocessor used: None
Preprocessor output directory: None
Preprocessor extensions processed: []
Building src/lib/penf.F90
Compiling src/lib/penf_global_parameters_variables.F90 serially
Compiling src/lib/penf_b_size.F90 serially
Compiling src/lib/penf_stringify.F90 serially
Compiling src/lib/penf_allocatable_memory.F90 serially
Compiling src/lib/penf.F90 serially
Linking static/penf.a
Target src/lib/penf.F90 has been successfully built
As you can see, the build is successful with FoBiS.
I am using gfortran 14.2.0
Can you share the command you are using to build PENF with cmake?
Stefano
(Sorry for a duplicate comment, network issue.)
I will try to build on a home PowerMac now.
@szaghi Thank you for responding!
I wanted to reproduce the error in a VM, since I am away from the PowerMac, and to my surprise it worked fine – also for 32-bit powerpc with gcc 14.2.0. However it failed at least twice on the native machine, and while I switched to somewhat different as and ld recently, in January I used my earlier ones.
The only thing out of my head which I can think of as a meaningful difference between Rosetta VM and G5 PowerMac is that on the latter my gcc is optimized for the CPU, while in VM I use a generic one. Also G5 is a 64-bit CPU, running in 32-bit mode, while Rosetta emulates G4, which is strictly 32-bit.
Both compilers are in fact built on G5 machine (it is way faster), the difference is --mtune-cpu=G5 vs no opt setting.
If it is not this, I am out of ideas, but I can verify gcc hypothesis at least. I will update on this.
Just for the record, configure (but given successful VM build, perhaps irrelevant):
---> Configuring PENF
Executing: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_PENF/PENF/work/build" && /opt/local/bin/cmake -G "CodeBlocks - Unix Makefiles" -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_INSTALL_PREFIX="/opt/local" -DCMAKE_INSTALL_NAME_DIR="/opt/local/lib" -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_C_COMPILER="$CC" -DCMAKE_CXX_COMPILER="$CXX" -DCMAKE_OBJC_COMPILER="$CC" -DCMAKE_OBJCXX_COMPILER="$CXX" -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_POLICY_DEFAULT_CMP0060=NEW -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_MODULE_PATH="/opt/local/share/cmake/Modules" -DCMAKE_PREFIX_PATH="/opt/local/share/cmake/Modules" -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH="/opt/local/lib" -Wno-dev -DBUILD_TESTING=ON -DCMAKE_OSX_ARCHITECTURES="ppc" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6" -DCMAKE_OSX_SYSROOT="/" /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_PENF/PENF/work/PENF-1.2.3
-- The Fortran compiler identification is GNU 14.2.0
-- Checking whether Fortran compiler has -isysroot
-- Checking whether Fortran compiler has -isysroot - yes
-- Checking whether Fortran compiler supports OSX deployment target flag
-- Checking whether Fortran compiler supports OSX deployment target flag - yes
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /opt/local/bin/gfortran-mp-14 - skipped
-- Performing Test ASCII_SUPPORTED
-- Performing Test ASCII_SUPPORTED - Success
-- Performing Test ASCII_NEQ_DEFAULT
-- Performing Test ASCII_NEQ_DEFAULT - Failed
-- Performing Test UCS4_SUPPORTED
-- Performing Test UCS4_SUPPORTED - Success
-- Configuring done (12.8s)
-- Generating done (4.3s)
@szaghi Ok, it is not optimizations, I get the same error with two gcc14 on G5. I return to a thought this is a subtle bug in the code. Build fails on this: https://github.com/szaghi/PENF/blob/d51f6827fc30144bf35a8e20aab1df63356c6ba5/src/lib/penf_allocatable_memory.F90#L1947C12-L1947C27 Can it behave wrong, given we have a 64-bit physical CPU, but 32-bit code running on it? (This is not an emulation, G5 supports both natively.)
@szaghi This could be a bug in gfortran too. By the way, I remembered this issue (may be unrelated, but the error is ERROR STOP scalar cast int32 => int64, so might be): https://github.com/geospace-code/h5fortran/issues/41
If this is a compiler bug, it would really nice to track it and fix in upstream.
@szaghi Ok, it is not optimizations, I get the same error with two gcc14 on G5. I return to a thought this is a subtle bug in the code. Build fails on this: https://github.com/szaghi/PENF/blob/d51f6827fc30144bf35a8e20aab1df63356c6ba5/src/lib/penf_allocatable_memory.F90#L1947C12-L1947C27 Can it behave wrong, given we have a 64-bit physical CPU, but 32-bit code running on it? (This is not an emulation, G5 supports both natively.)
It is not simple for me to help you with this issue because I do not have access to a G5 machine. Indeed, I am quite confident that until the compiler is ISO compliant, there should not be any type mismatch between integers of different kinds: all the kind definitions in PENF are portable parameters defined by the ISO standard built-in select kind routines, exactly intending to be portable. Using 64bit integers with 32bit ones is safe.
Anyhow, bugs are always possible, thus I would really like to reproduce this issue in order to catch/fix this possible bug, but, as I said, is not easy for me with a your setup.
Moreover, I do not understand what you mean with
given we have a 64-bit physical CPU, but 32-bit code running on it
Are you performing a cross-compiling? Namely, are you building a 32bit program on a 64bit architecture?
G5 is a 64-bit cpu, but it can execute both 64- and 32-bit code natively. MacOS kernel on PowerPC is always 32-bit. Userland supports ppc64 in 10.5 (only). Since I use 10.6, only ppc (32-bit) code is supported. However there are certain specifics with G5, even when it is used in 32-bit mode (it does not behave strictly identical to 32-bit cpu like G4).
The issue remains puzzling. As a matter of fact, somehow PENF built in 2023 on 10.6 ppc on a G5. It does not now, on the same system, same machine. I thought maybe it is a bug introduced in recent gcc, but going back to 12.3.0 and the earliest CMake I still had installed (3.21.x) did not fix the error. I have no way to know exactly which libgcc and gcc I used back then when the build was successful, so it is still possible that some specific version worked, and I may not have it anymore, but this is quite strange…
P. S. Well, it is not impossible that I built PENF back then in Rosetta and transferred pre-built port onto G5, and just forgot about the issue, but usually in such cases I leave a comment in a portfile and report it to upstream.
Hi, it could be helpful to know which version of PENF works: assuming that the issue is not related to the OS/compiler rather it is related to the new version of PENF, doing a diff of the two versions can provide some insight.
Ok, 1.2.1 builds fine on G5. I can try bisecting then.
Update. May not be of great help though. This 65061235982495b158412b70c05b228af4320d94 commit builds normally, next 364fe5526a477d92ffdf32bd66a3fe678a71b81a one fails due to missing module, which was apparently fixed in the last commit, but that one fails (it is identical to 1.2.3).
Upd2. Build of 1.2.3 with FPM fails identically to CMake one.
Between these two commits, the most relevant difference is the introduction of some auxiliaries for allocatable arrays
I can try to emulate your architecture using qemu. Please let me know the hardware and software setup with which the issue arises.
I can try to emulate your architecture using qemu. Please let me know the hardware and software setup with which the issue arises.
I wanted to write that Qemu does not support G5 emulation, but apparently some support may exist, judging from this: https://lists.gnu.org/archive/html/qemu-ppc/2023-01/msg00360.html It is not clear if macOS can boot that way though, or whether the issue can be reproduced outside of macOS.
It will probably be easier if I give access to my machine. If that works for you, let’s coordinate that over e-mail.
I can try to emulate your architecture using qemu. Please let me know the hardware and software setup with which the issue arises.
I wanted to write that Qemu does not support G5 emulation, but apparently some support may exist, judging from this: https://lists.gnu.org/archive/html/qemu-ppc/2023-01/msg00360.html It is not clear if macOS can boot that way though, or whether the issue can be reproduced outside of macOS.
It will probably be easier if I give access to my machine. If that works for you, let’s coordinate that over e-mail.
Hi, I tried to emulate your architecture, but I failed, as openbios-ppc is currently not available pre-compiled. Because I have no time to compile from source all the necessary packages for emulating a G5, I think we can try with a remote access if you want. Feel free to write to [email protected]
Cheers.
@barracuda156
Thank you very much for pointing out this bug, and let me play with your G5 to fix it.
Tomorrow I'll push the fix.
Cheers
@barracuda156
Hi, I have pushed the fix, which is also included in the assets of the latest release.
I am going to close this issue. Let me know if it works for you now.
Cheers,
Stefano