Open cponder opened 1 year ago
Hi @cponder thank you very much for pointing out this bug.
This line in the source file
src/lib/flap_command_line_interface_t.F90
1540 pos = index(basename, '\', back=.true.)
gives an error about a mis-matched single-quote from the NVHPC compiler. I can make the problem go away by replacing the line with
1540 pos = index(basename, '\\', back=.true.)
I'm not sure what the best source-code fix would really be, though. I assume the Intel & GNU compilers didn't have this issue.
I do not know NVHPC compiler, can you give me more details? I am currently using the Nvidia HPC framework with CUDA fortran (essentially e derivation of PGI compiler), but I almost hate it (NVHPC resounds Nvidia HPC, maybe we are using the same compiler). I have not tried to use FLAP on the cluster where I am using NV CUDA fortran, but if the bug you pointed out arises with it there is a good chance that I can debug it more quickly.
And yes, with Intel and GNU compilers I have never had such an issue, thus I have to check it with your compiler, possibly.
Thank you for the help.
Kind regards, Stefano
Yeah -- by NVHPC I mean the nvfortran
compiler.
I'm using these settings
ENV CC "nvc"
ENV CXX "nvc++"
ENV F90 "nvfortran"
ENV FC "nvfortran"
and these build-instructions (using Docker):
ARG FLAP_VERSION=1.2.5
RUN cd /usr/local/src && \
curl --retry 5 -fSsL "https://github.com/szaghi/FLAP/releases/download/v${FLAP_VERSION}/FLAP.tar.gz" | tar xz && \
sed '1540 d' -i FLAP/src/lib/flap_command_line_interface_t.F90 && \
sed "1540 i \ \ pos = index(basename, '\\\\\\\', back=.true.)" -i FLAP/src/lib/flap_command_line_interface_t.F90 && \
cd FLAP && \
mkdir -p build && \
cd build && \
cmake -D CMAKE_INSTALL_PREFIX=/usr/local -D EXTRA_FLAGS=-noswitcherror .. && \
make
I can provide more information if you need.
I really want to get rid of the sed
substitution-hack, it's likely to break at some point.
Yeah -- by NVHPC I mean the
nvfortran
compiler. I'm using these settings
Great, I am using it.
I can provide more information if you need. I really want to get rid of the
sed
substitution-hack, it's likely to break at some point.
I'll try to do my best, but please be patient, I am quite busy now.
I had to adjust the line-numbers with the 1.2.5 tag:
sed '1542 d' -i FLAP/src/lib/flap_command_line_interface_t.F90 && \
sed "1542 i \ \ pos = index(basename, '\\\\\\\', back=.true.)" -i FLAP/src/lib/flap_command_line_interface_t.F90 && \
BTW, it looks like you'd overwritten the 1.2.5 tag with this file and maybe others. This caused my build to fail.
The best workaround for me is to use this flag in the setup:
cmake -D CMAKE_Fortran_FLAGS="-noswitcherror -Mbackslash" ...
Evidently it doesn't cause problems with any of the other source lines.
Hi, I am sorry for my delay.
I have tested FLAP with NVFortran 23.1 (SDK 12.0) and you are right, the backslash is not well interpreted by the compiler with the default settings. Reading the man page of the compiler I have found the meaning of your last workaround:
-Mbackslash -Mnobackslash (default) Treat (don't treat) backslash as a normal (non-escape) character in strings. -Mnobackslash causes the standard C backslash escape sequences to be recognized in quoted strings; -Mbackslash causes the backslash to be treated like any other character.
Using this flag FLAP is correctly compiled by NVFortran. I think that this is the best patch, I prefer it instead of directly escaping the backslash into the code. I am now modifying the fobos config in order to add a mode for compiling the library with NVFortran exploiting the switch you found. I'll try to modify the cmake config, but I am not familiar with CMake...
Thank you very much for pointing it out.
Kind regards, Stefano
@cponder
I have just uploaded a new master commit with your workaround clearly (I hope) stated into the readme and with an amended fobos file containing an example of NVFortran compilation.
Thank you again.
This line in the source file
src/lib/flap_command_line_interface_t.F90
gives an error about a mis-matched single-quote from the NVHPC compiler. I can make the problem go away by replacing the line with
I'm not sure what the best source-code fix would really be, though. I assume the Intel & GNU compilers didn't have this issue.