Error: Ambiguous interfaces in generic interface 'string_type' for 'new_string_from_logical_lk' at (1) and 'new_string_from_logical_c_bool' at (2)

[barracuda156]

Description

/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_fortran-stdlib/fortran-stdlib/work/build/src/stdlib_string_type.f90:74:8:

   74 |         elemental module function new_string_from_logical_lk(val) result(new)
      |        1
......
   78 |         elemental module function new_string_from_logical_c_bool(val) result(new)
      |        2
Error: Ambiguous interfaces in generic interface 'string_type' for 'new_string_from_logical_lk' at (1) and 'new_string_from_logical_c_bool' at (2)
make[2]: *** [src/CMakeFiles/fortran_stdlib.dir/stdlib_string_type.f90.o] Error 1
make[2]: *** Waiting for unfinished jobs....

Expected Behaviour

Types should be consistent or at least not lead to build failure :)

Version of stdlib

0.2.1

Platform and Architecture

macOS 10.6.8/ppc

Additional Information

gcc 12.2.0
cmake 3.25.2
python 3.11.1
py311-fypp 3.1

[barracuda156]

Same error when building from current master:

[ 11%] Building Fortran object src/CMakeFiles/fortran_stdlib.dir/stdlib_string_type.f90.o
cd /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_fortran-stdlib/fortran-stdlib/work/build/src && /opt/local/bin/gfortran-mp-12  -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_fortran-stdlib/fortran-stdlib/work/build/src/mod_files -pipe -Os -m32 -fimplicit-none -ffree-line-length-132 -mmacosx-version-min=10.6 -Jmod_files/ -fPIC -c /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_fortran-stdlib/fortran-stdlib/work/build/src/stdlib_string_type.f90 -o CMakeFiles/fortran_stdlib.dir/stdlib_string_type.f90.o
/opt/local/bin/cmake -E cmake_copy_f90_mod src/mod_files//stdlib_bitsets.mod src/CMakeFiles/fortran_stdlib.dir/stdlib_bitsets.mod.stamp GNU
/opt/local/bin/cmake -E touch src/CMakeFiles/fortran_stdlib.dir/stdlib_error.f90.o.provides.build
/opt/local/bin/cmake -E cmake_copy_f90_mod src/mod_files//stdlib_hash_32bit@stdlib_hash_32bit_fnv.smod src/CMakeFiles/fortran_stdlib.dir/stdlib_hash_32bit@stdlib_hash_32bit_fnv.smod.stamp GNU
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_fortran-stdlib/fortran-stdlib/work/build/src/stdlib_string_type.f90:74:8:

   74 |         elemental module function new_string_from_logical_lk(val) result(new)
      |        1
......
   78 |         elemental module function new_string_from_logical_c_bool(val) result(new)
      |        2
Error: Ambiguous interfaces in generic interface 'string_type' for 'new_string_from_logical_lk' at (1) and 'new_string_from_logical_c_bool' at (2)

[jvdp1]

Thank you @barracuda156 for this report.
I have no issue with GFortran 12.2.1 and Intel OneAPI 2023 on Fedora 36. Could this depend on the OS too?
The CMakefiles and fypp could be adapted to check for this case (like for real(qp))

[barracuda156]

@jvdp1 I cannot say anything about Linux, no idea, but we probably don’t want this to be broken on macOS? :)

[awvwgk]

This issue seems very specific for PowerPC, I haven't tried building stdlib on Linux/ppc64le yet, so I can't comment whether it only affect MacOS in this particular combination (x86_64 and arm64 seem to be fine).

The issue for MacOS/ppc seems to be the choice of the default logical kind being one byte rather than the more common four bytes (as the default int). So we would need to check whether the c_bool kind parameter is identical to the default logical kind and omit the interface if that is the case. We already have similar checks for extended double and quadruple precision reals implemented.

[barracuda156]

This issue seems very specific for PowerPC, I haven't tried building stdlib on Linux/ppc64le yet, so I can't comment whether it only affect MacOS in this particular combination (x86_64 and arm64 seem to be fine).

The issue for MacOS/ppc seems to be the choice of the default logical kind being one byte rather than the more common four bytes (as the default int). So we would need to check whether the c_bool kind parameter is identical to the default logical kind and omit the interface if that is the case. We already have similar checks for extended double and quadruple precision reals implemented.

Bool is 4 byte on MacOS ppc32: http://personal.denison.edu/~bressoud/cs281-s07/MacOSXLowLevelABI.pdf
This is specific to ppc32; on ppc64 bool in 1 byte.

[awvwgk]

Thanks for the clarification, the same strategy for fixing this issue still applies.

[jvdp1]

Thanks for the clarification, the same strategy for fixing this issue still applies.

I had this strategy in mind too. @barracuda156 Would you like to give it a try? If not, I will try to look at it ASAP.

[barracuda156]

Thanks for the clarification, the same strategy for fixing this issue still applies.

I had this strategy in mind too. @barracuda156 Would you like to give it a try? If not, I will try to look at it ASAP.

@jvdp1 If you could help with this, it would be great. I can do testing on my end for whatever fixes are suggested.