Arch Linux User Repository

@AquilaIrreale Thank for the fix.

In the current version of the package you are running make install, but not the specific install commands for the executables, so the cado-nfs.py file is not ending up in the global path.

@gilcu3 fixed it as you suggested by adding a patch to disable detection of system-installed fmt version.

I did not have Arch's fmt on my system so for me it was already using its own bundled version automatically and I never noticed the incompatibility, so thank you for reporting the issue.

Currently, the package is not building due to an error. A patch like the one mentioned in here It seems to be related to incompatibility with the current version of fmt. Using the bundled one is an option in the original package, so we could take that path

[ 89%] Built target matmul_p_13_zone
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_u64k1.dir/lingen_bigmatpoly_ft.cpp.o
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_u64k1.dir/lingen_qcode_binary.cpp.o
[ 89%] Linking CXX static library libmatmul_p_14_zone.a
[ 89%] Built target matmul_p_14_zone
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_1.dir/lingen_verify_checkpoints.cpp.o
[ 89%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_2.dir/lingen_verify_checkpoints.cpp.o
In file included from /home/rey/.cache/aurutils/sync/cado-nfs-git/src/cado-nfs/linalg/bwc/lingen_tuning.cpp:25:
/usr/include/fmt/core.h: In instantiation of ‘constexpr fmt::v9::detail::value<Context> fmt::v9::detail::make_value(T&&) [with Context = fmt::v9::basic_format_context<fmt::v9::appender, char>; T = const lingen_call_companion::key&]’:
/usr/include/fmt/core.h:1777:29:   required from ‘constexpr fmt::v9::detail::value<Context> fmt::v9::detail::make_arg(T&&) [with bool IS_PACKED = true; Context = fmt::v9::basic_format_context<fmt::v9::appender, char>; type <anonymous> = fmt::v9::detail::type::custom_type; T = const lingen_call_companion::key&; typename std::enable_if<IS_PACKED, int>::type <anonymous> = 0]’
/usr/include/fmt/core.h:1901:77:   required from ‘constexpr fmt::v9::format_arg_store<Context, Args>::format_arg_store(T&& ...) [with T = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&}; Context = fmt::v9::basic_format_context<fmt::v9::appender, char>; Args = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned int, lingen_call_companion::key}]’
/usr/include/fmt/core.h:1918:31:   required from ‘constexpr fmt::v9::format_arg_store<Context, typename std::remove_cv<typename std::remove_reference<Args>::type>::type ...> fmt::v9::make_format_args(Args&& ...) [with Context = basic_format_context<appender, char>; Args = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&}]’
/usr/include/fmt/core.h:3206:44:   required from ‘std::string fmt::v9::format(format_string<T ...>, T&& ...) [with T = {std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&}; std::string = std::__cxx11::basic_string<char>; format_string<T ...> = basic_format_string<char, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const unsigned int&, const lingen_call_companion::key&>]’
/home/rey/.cache/aurutils/sync/cado-nfs-git/src/cado-nfs/linalg/bwc/lingen_tuning.cpp:1281:45:   required from here
/usr/include/fmt/core.h:1757:7: error: static assertion failed: Cannot format an argument. To make type T formattable provide a formatter<T> specialization: https://fmt.dev/latest/api.html#udt
 1757 |       formattable,
      |       ^~~~~~~~~~~
/usr/include/fmt/core.h:1757:7: note: ‘formattable’ evaluates to false
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_3.dir/lingen_verify_checkpoints.cpp.o
make[2]: *** [linalg/bwc/CMakeFiles/lingen_u64k1.dir/build.make:104: linalg/bwc/CMakeFiles/lingen_u64k1.dir/lingen_tuning.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_4.dir/lingen_verify_checkpoints.cpp.o
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_5.dir/lingen_verify_checkpoints.cpp.o
[ 90%] Linking CXX executable lingen_verify_checkpoints_u64k1
[ 90%] Built target lingen_verify_checkpoints_u64k1
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_6.dir/lingen_verify_checkpoints.cpp.o
[ 90%] Building CXX object linalg/bwc/CMakeFiles/lingen_verify_checkpoints_p_7.dir/lingen_verify_checkpoints.cpp.o
make[1]: *** [CMakeFiles/Makefile2:5980: linalg/bwc/CMakeFiles/lingen_u64k1.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_2
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_1
[ 90%] Built target lingen_verify_checkpoints_p_2
[ 90%] Built target lingen_verify_checkpoints_p_1
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_3
[ 90%] Built target lingen_verify_checkpoints_p_3
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_4
[ 90%] Built target lingen_verify_checkpoints_p_4
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_5
[ 90%] Built target lingen_verify_checkpoints_p_5
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_6
[ 90%] Linking CXX executable lingen_verify_checkpoints_p_7
[ 90%] Built target lingen_verify_checkpoints_p_6
[ 90%] Built target lingen_verify_checkpoints_p_7
make: *** [Makefile:146: all] Error 2
make: *** [Makefile:7: all] Error 2

From what I get to see of CMake files like avx2.cmake, the configuration goes as follows:

1. Try to compile code for specific SIMD datatypes like avx2.c without adding own compiler flags.
2. If compilation fails, check for -march.
3. If no -march is specified, try adding flags like -mavx2.
4. If compilation succeeds, try running the program on the build machine.
5. If compilation or running fails, clear/unset the associated configuration variable like HAVE_AVX2.
6. If running succeeds, set the associated configuration variable.

Thus, Haswell users should find HAVE_AVX2 defined in their cado_config.h, but Sandybridge users not.

To conclude, both the specified -march and the capabilities of the build system limit the available SIMD features: You cannot activate code paths meant for a target architecture more recent than that of your build system.

Worse, if you specify an architecture that is incompatible with your build system, then those incompatibilities may lead to failure of the autodetection of even those SIMD features that your build machine actually supports.

Thus, the only safe choices are

• A minimum architecture that both build and target system can be expected to support, e.g. -march=sandybridge,
• -march=native for the feature set of the build machine,
• equivalently, no -march at all. Compared to -march=native, this adds more detailed compiler flags, but the HAVE_* definitions are identical.

I wonder why _march=haswell does not result in the definition of HAVE_AVX2 in (my) cado_config.h. Does anyone achieve HAVE_AVX2 with _march=native?

Anyhow, this is the resulting cado_config.h, looking about right I think

Yes, that matches mine. Interestingly, setting _march=haswell on my sandybridge produces the same cado_config.h (except for the C*FLAGS strings of course), but results in incompatible binaries.

Ok, so... x86-64-v4 is clearly too high a target to run on sandybridge CPUs, but on the other hand when I tried to compile it with the lower x86-64-v2 and x86-64-v3 it just wouldn't build... neither would it if I set the various -msse4.2, -mavx etc. manually with the basic -march=x86-64. From what I read v2 is very similar in terms of capabilities to sandybridge, and v3 is to haswell.

About SIMD instructions, -march=x86-64 does have -msse2 but it seems cado wants the higher stuff. In my trials, it always failed trying to compile intrinsics that relate to the AVX instruction set. Of course as I said, manually enabling -msse4.2 and -mavx proved no solution.

It does compile (and work) with -march=sandybridge on my i7 4790K which should be a haswell, being the next major architecture right after sandybridge it would be strange otherwise... but still... it may be that sandybridge is the baseline architecture for this package, being the lowest "phisical" architecture to have AVX and x86-64-v2 not working for some reason.

Anyhow, this is the resulting cado_config.h, looking about right I think

In the patch for issue #30019, if -march is detected during configuration, HAVE_* feature flags are not set at all

They are set somewhere, though the patch superficially suggests otherwise. The configuration produces a file $srcdir/cado-nfs/build/$USER/cado_config.h. If you inspect that, you will find that the HAVE_* macros are set according to your -march spec. Which is why building with -march=x86-64-v4 can be done on my sandybridge platform, except that the produced binaries cannot be run there. However, CADO-NFS seems to require some form of SIMD datatype, and the makepkg default -march=x86-64 apparently provides none, which causes build attempts to fail.

Out of curiosity, I'd like to know whether anyone of you can build with -march=sandybridge, and how this would change your cado_config.h.