arm64 build fails with conversion error on Fedora w/ GCC 15.2.1

[hobbes1069]

I get repeated errors of the following:

In file included from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/profiler.hpp:12,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/table.hpp:18,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/ngcore.hpp:9,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/include/../general/../include/mydefs.hpp:14,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/include/../general/myadt.hpp:16,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/include/myadt.hpp:1,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/general/spbita2d.cpp:13:
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/taskmanager.hpp: In member function ‘void ngcore::SharedLoop2::SharedIterator::GetNext2()’:
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/taskmanager.hpp:596:28: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  596 |             if (steal_from == ranges.Size()) steal_from = 0;
      |                 ~~~~~~~~~~~^~~~~~~~~~~~~~~~
In file included from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd.hpp:34,
                 from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/ngcore.hpp:16:
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd_arm64.hpp: In function ‘ngcore::SIMD<ngcore::mask64, 2> ngcore::operator==(SIMD<long int, 2>, SIMD<long int, 2>)’:
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd_arm64.hpp:75:21: note: use ‘-flax-vector-conversions’ to permit conversions between vectors with differing element types or numbers of subparts
   75 |     return vceqq_u64(a.Data(), b.Data());
      |            ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd_arm64.hpp:75:28: error: cannot convert ‘__Int64x2_t’ to ‘uint64x2_t’
   75 |     return vceqq_u64(a.Data(), b.Data());
      |                      ~~~~~~^~
      |                            |
      |                            __Int64x2_t
In file included from /builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd_arm64.hpp:1:
/usr/lib/gcc/aarch64-redhat-linux/15/include/arm_neon.h:7646:23: note: initializing argument 1 of ‘uint64x2_t vceqq_u64(uint64x2_t, uint64x2_t)’
 7646 | vceqq_u64 (uint64x2_t __a, uint64x2_t __b)
      |            ~~~~~~~~~~~^~~
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd_arm64.hpp: In function ‘ngcore::SIMD<ngcore::mask64, 2> ngcore::operator>(SIMD<long int, 2>, SIMD<long int, 2>)’:
/builddir/build/BUILD/netgen-mesher-6.2.2506-build/netgen-6.2.2506/libsrc/core/simd_arm64.hpp:80:21: error: could not convert ‘vcgtq_s64(a.ngcore::SIMD<long int, 2>::Data(), b.ngcore::SIMD<long int, 2>::Data())’ from ‘uint64x2_t’ to ‘ngcore::SIMD<ngcore::mask64, 2>’
   80 |     return vcgtq_s64(a.Data(), b.Data());
      |            ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
      |                     |

https://kojipkgs.fedoraproject.org//work/tasks/5848/137435848/build.log

[qbisi]

Those arm neon code are only tested for clang/darwin platform which has "-flax-vector-conversions" enabled by default.
I suggest the upstream developer intergrate CI build/test/publish with github action and consider testing/merging those patches from downstream packager maintainers of debian/fedora.

[StefanBruens]

The builtins of the ARM intrinsic compare operations return unsigned integer types, even if the operands are signed types or floats - the return values have boolean semantics, not integer.

So the code is syntactically wrong, and should be fixed.