Closed TyBalduf closed 3 months ago
This behavior is quite surprising, it seems that ifx is deviating in behavior from most of the common Fortran compilers, not sure whether this behavior is still compliant with the Fortran standard and could be considered a bug in ifx. One option would be to check the getline
implementation in stdlib whether there is any update we can port back to xtb.
I believe his was a false alarm. I was somehow compiling with ifx 2024, but also linking against parts of ifort 2022. I have to imagine this could cause all sorts of strange behavior, including this iostat issue.
Describe the bug There is another issue saying that ifx compilation doesn't succeed. But, on Linux (Centos7), I am able to compile xTB-v6.7.0 with ifx 2024.0.2 using meson. However, once it is built, it fails immediately for any job while trying to read the input file:
It seems that
getline
isn't properly returningiostat
and is just failing outright.If I add
eor
to the read ingetline
to force, it gets stuck in an infinite loop because the "end of file" error code returned is 24, which is not recognized byis_iostat_end
.If I add a check for 24, it correctly finishes trying to read the input file, but then fails again with the "severe (268): end of record" during
readmolecule
.To Reproduce
meson setup xtb build --buildtype=release
with Fortran compiler set to ifx.xtb -h
should work fine, butxtb any_input.xyz
should fail immediately with an end of record error.Additional context Compiling v6.7.0 with ifort-2022.0.2 runs just fine with all the same settings.
I also made a small test program that just opens a file and applies
getline
to it repeatedly. Compiling with ifx, this seems to correctly handleiostat
. So it seems like there is an issue with ifx misinterpreting something about how xTB opens files.