fix #2017

[quantresearch1]

@galabovaa The issue mentions a SIGILL when running on older x86_64 CPUs such as a Core 2 Duo. I will defer to your expertise but I am wondering if we can get away with checking compiler support only for the POPCNT instruction ? While this doesn't do runtime CPU detection, in practice modern compilers are pretty good at handling CPU compatibility issues. If the flag is supported but the CPU doesn't support the instruction, most compilers will generate appropriate fallback code.

If you think this is not sufficient, I am happy to add something like this to detect cpu support:

    if(COMPILER_SUPPORTS_POPCNT)
        check_cxx_source_runs("
            #include <stdint.h>
            #if defined(_MSC_VER)
                #include <intrin.h>
                #define popcnt64 __popcnt64
            #else
                #include <x86intrin.h>
                #define popcnt64 _mm_popcnt_u64
            #endif
            int main() {
                uint64_t x = 0xAAAAAAAA55555555ULL;
                return popcnt64(x) == 32;
            }"
            CPU_SUPPORTS_POPCNT)
    endif()

Also, I think this message is slightly misleading for two reasons:

if (WIN32)
    message("FLAG_MPOPCNT_SUPPORTED is not available on this architecture")

1. The -mpopcnt flag is specific to GCC/Clang compilers, on Windows, MSVC doesn't use these kinds of flags. However, the check would wrongly skip the -mpopcnt flag even when using MinGW or Clang on Windows, which do support it.
2. check_cxx_compiler_flag() will automatically return false for MSVC when checking -mpopcnt

[galabovaa]

At a first glance it looks good to me! I need to look at it a bit further next week, to see why the PDLP solve of one test problem gives a different output after this change.

[jajhall]

At a first glance it looks good to me! I need to look at it a bit further next week, to see why the PDLP solve of one test problem gives a different output after this change.

These occasional failures (for 25fv47) resulted in me dropping (in latest) the last "8" in its objective function used in the test for WIN32 (as it had been for APPLE) in the pdlpInstances for CI. However, this "8" is still in master, so the CI tests will fail for PRs built from branches of master. Once merged into latest, they will pass. I saw this with #2067: once I'd merged into a local branch, and then merged latest into it, the CI tests passed.

Another way of putting it is that master wouldn't pass our CI tests, now that they include instances solved by PDLP