Compiling with the IBM compiler fails #763
Comments
|
Thanks for the report, I don't have an IBM XL installation ready at the moment to check. Could you run fpm on the full source version? I compiled a Linux/ppc64le version for conda-forge already so you don't have to bootstrap. From the output it looks like M_CLI2 is producing the error. Maybe John @urbanjost has an idea. |
|
On an IBM (which I no longer have access to; and could not find an online compiler to try some tests) the default is the non-standard treatment of backslash as a C-like escape character. You have to add -qnoescape to get standard behavior. That could easily be coded around by using achar() as well; but the compiler does not yet seem to support the G0 edit descriptor for both input and output, which could be resolved by creating a lot of individual formats and adding some conditional prints or inspecting the arguments to the I/O statements; but it would be a much more extensive change. Are there any newer versions of the compiler that support features past f2003? The error in the LOWER function is either a compiler bug or a feature added after f2003, I do not remember which; but it would be easy to code around. The errors reporting function values are not set is a compiler bug (the value is set, but via a call to a subroutine not an assignment statement) that I remember seeing before; it just takes a few lines to create an allocatable string and pass it and then assign the the function name to the value; I think something like setting the attributes in the called procedure to intent(out) or something else fixed that; and maybe using result (NAME) instead of the function name worked around it, but the assignment statement lets the compiler know it really is set. Without an IBM compiler maybe compiling with the Intel or GNU compiler and using std=f2003 would be enough to make a version compile with that compiler. The format statement changes are mostly just busy work but the most extensive problem. Since they are standard-conforming in post f2003 I am uncertain whether that is worth doing or not, if IBM XL has newer releases. From the sounds of it you have a newer gfortran or ifort/ifx that it does build with? If this is impacting distribution of fpm I can see if building an f2003-compliant version resolves it; and turn on the option to treat \ as a C escape on those compilers. It is a little less clear to say A=ACHAR(92) instead of A='' but it would avoid that switch. Most compilers default to standard-conforming; and most had added a switch to all the C-like usage where "\n" is a newline, etc. nvfortran is the only other one I know of that needs a switch to have default behavior. You have to use -Mbackslash; which is the default for the nvfortran compiler called from fpm; but inconsistently I do not think -qnoescape is the fpm default for xlf; which we should think about changing. |
|
Do you have the xlf2008 command on your system? What version of the compiler do you have? Not sure about allocating scalars, and G0 is not supported yet at least up to February of 2022; but it looks like several of the required f2008 features are supported. |
Description
I'm reporting the errors generated by compiling
fpm-0.6.0.F90with the IBM XL Fortran compiler just for informational purposes. I think most or all of the errors are false positives, but I'm not very familiar with edit descriptors so I'm hoping someone else can confirm whether these are bugs in the code or bugs in the compiler. My guess is that these are post-2003 features that the compiler doesn't support. Could someone who recognizes what's going on at the cited lines confirm that the lines are standard-conforming and close this issue?Expected Behaviour
I expected
fpm-0.6.0.F90to compile.Version of fpm
0.6.0
Platform and Architecture
AIX
Additional Information
The compilation command and output are below:
The text was updated successfully, but these errors were encountered: