urbanjost / M_strings

Fortran string manipulations
The Unlicense
24 stars 3 forks source link

Build error: Error: Invalid type-spec (./src/M_strings.f90:9602:34) #2

Open wiremoons opened 3 years ago

wiremoons commented 3 years ago

UPDATED: Found a couple of other similar issues and it appears this is a gfortran and Apple Silicon M1 CPU (arm64) problem - so nothing directly / specifically to do with the M_strings.f90. For reference see:

If you wan to close this issue that is fine - hopefully it will be useful anyway in case another person finds the same problem.

ORGINAL REPORT BELOW:

Hi

I am new to Fortran - so apologies in advance if this is some newbie error!

I was trying to build fpm-search that depends on M_strings. It was failing to build due to a problem with M_strings.

I have re-downloaded M_strings by cloning the repo directly, and following the instructions in the 'Readme.md' for the gfortran complier.

In the src sub-directory, I run make clean and then make F90=gfortran gfortran. Below is a copy of the output:

% make F90=gfortran gfortran

gfortran -g -O -Wall -std=f2018 -Wextra -Wno-maybe-uninitialized -Wno-uninitialized -finit-local-zero -c M_strings.f90
M_strings.f90:9602:34:

 9602 |       type is (real(kind=real128));     write(line(istart:),'(1pg0)') generic
      |                                  1
Error: Invalid type-spec at (1)
M_strings.f90:9659:34:

 9659 |       type is (real(kind=real128));     write(line(istart:),'("[",*(1pg0,1x))') generic
      |                                  1
Error: Invalid type-spec at (1)
M_strings.f90:3601:49:

 3601 |    forall(i=1:len(string)) array(i) = string(i:i)
      |                                                 1
Warning: Fortran 2018 obsolescent feature: FORALL construct at (1)
M_strings.f90:3587:52:

 3587 |    forall( i = 1:size(array)) string(i:i) = array(i)
      |                                                    1
Warning: Fortran 2018 obsolescent feature: FORALL construct at (1)
make: *** [M_strings.o] Error 1

I also tried to build with fpm build (after running make clean first - if that makes any difference!). The output then is as below:

% fpm build

 + mkdir -p build/dependencies
Initialized empty Git repository in /Users/simon/scratch/fortran/fpm-search/build/dependencies/M_strings/build/dependencies/M_msg/.git/
remote: Enumerating objects: 102, done.
remote: Counting objects: 100% (102/102), done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 102 (delta 41), reused 55 (delta 23), pack-reused 0
Receiving objects: 100% (102/102), 270.10 KiB | 1.73 MiB/s, done.
Resolving deltas: 100% (41/41), done.
From https://github.com/urbanjost/M_msg
 * branch            HEAD       -> FETCH_HEAD
 + mkdir -p build/gfortran_2A42023B310FA28D/M_strings
 + gfortran -c ././src/M_strings.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fcheck=bounds -fcheck=array-temps -fbacktrace -fcoarray=single -J build/gfortran_2A42023B310FA28D/M_strings -I build/gfortran_2A42023B310FA28D/M_strings  -o build/gfortran_2A42023B310FA28D/M_strings/src_M_strings.f90.o
././src/M_strings.f90:9602:34:

 9602 |       type is (real(kind=real128));     write(line(istart:),'(1pg0)') generic
      |                                  1
Error: Invalid type-spec at (1)
compilation terminated due to -fmax-errors=1.
 <ERROR> Compilation failed for object "src_M_strings.f90.o"
STOP 1

The error using both approaches look like the same issue, but that's is about as far as my wisdom on the matter goes!

Is it a source code problem - or user error?

The build is being done on a Apple Mac mini (Apple Silicon M1 - arm64) version 11.5.2 (Big Sur) using gfortran installed from brew - version info below:

% gfortran -v

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/11.2.0/libexec/gcc/aarch64-apple-darwin20/11.1.0/lto-wrapper
Target: aarch64-apple-darwin20
Configured with: ../configure --prefix=/opt/homebrew/Cellar/gcc/11.2.0 --libdir=/opt/homebrew/Cellar/gcc/11.2.0/lib/gcc/11 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-11 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --build=aarch64-apple-darwin20 --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Homebrew GCC 11.2.0)

Thanks

Simon

urbanjost commented 3 years ago

Unfortunately not all Programming Environments support all the standard-defined types. In this case it looks like your does not support 128-bit types. To handle this properly requires using a preprocessor in Fortran currently, which fpm(1) has not selected. I commented out the 128-bit code as it is (hopefully) vary rarely used. The tests also use real128 so they will not run properly yet, as they use M_msg and M_verify which also support REAL128. fpm-search may pull a specific version in which case you might have to remove the version from the fpm.toml file so it pulls the latest. I am going to ponder how to best handle that, as many environments support REAL128. I might have to resort to trusting fpp/cpp is available for the Fortran compiler, which is very often true but not guaranteed. So the new one should work for you; but until fpm(1) had some way of doing conditional compilation I cannot think of a way to have my cake and eat it too.

wiremoons commented 3 years ago

Thank you for making the changes. I can confirm M_strings it now builds successfully!

I am still working on the original goal of building fpm-search as a similar error with REAL is also presenting itself in Fortran stdlib as well - so I guess this is going to be a general problem with the new Apple M1 CPU until it becomes more common. I hope a suitable code solution is found, and it is not arduous to have to add it.

Thanks again for your help :)