Fixing MSVC Compiler Errors

[eessmann]

Fixes #538

Summary

This PR resolves compiler errors on MSVC by replacing non-standard usage of designated initializers combined with C-style casts. Previously, the code used:

return (CompMatr1) {
    .numQubits = 1,
    .numRows = 2,
    .elems = {
        {in[0][0], in[0][1]},
        {in[1][0], in[1][1]}
    }
};

which is incompatible with MSVC. The updated implementation ensures standard compliance by using:

CompMatr1 out = {
    .numQubits = 1,
    .numRows = 2,
    .elems = {
        {in[0][0], in[0][1]},
        {in[1][0], in[1][1]}
    }
};
return out;

Additionally, functions relying on GCC-specific intrinsics have been refactored to improve cross-compiler compatibility.

Background

Attempting to build the v4 branch on Windows with MSVC resulted in the following errors:

E:\projects\QuEST\quest\include\matrices.h(220,9): error C7555: use of designated initializers requires at least '/std:c++20'

and

E:\projects\QuEST\quest\include\matrices.h(219,12): error C4576: a parenthesized type followed by an initializer list is a non-standard explicit type conversion syntax

These errors occurred due to a combination of designated initializers and a C-style cast, which MSVC does not support, even with C++20 enabled. Removing the cast resolves this issue.

Testing & Known Issues

• Static Library Mode: Successfully builds and passes all tests.
• Shared Library Mode: The build fails and requires further investigation.

Cheers,
Erich

[TysonRayJones]

Brilliant, excellent stuff!! Good catch on de-mangling invalidQuESTInputError too. I've confirmed this is all compiling fine on MacOS and Ubuntu, in C++20 and C11.

A shame to have to disable multithreading altogether on Windows. Should we try to address it? It results from eight OpenMP reductions in cpu_subroutines making use of the qcomp custom reduction. I was so far ideologically recoiling from the simple workaround of reducing each component:

    qreal prodRe = 0;
    qreal prodIm = 0;

    #pragma omp parallel for reduction(+:prodRe,prodIm)
    for (qindex n=0; n<numIts; n++) {
        qcomp term += conj(quregA.cpuAmps[n]) * quregB.cpuAmps[n];

        // reduce components separately because MSVC OpenMP is stanky
        prodRe += real(term);
        prodIm += imag(term);
    }

    return qcomp(prodRe,prodIm);

I could be persuaded to this evil if it has no performance effect on the other compilers. Could it possibly interfere with auto-vectorisation or something?

(ignore the irrelevant/outdated v3 workflows, I was just curious as to why I was prompted to run them).

[eessmann]

I’ve tracked down and fixed the root cause of the shared library build failures on Windows. By default, Windows doesn’t export any symbols in DLLs, unlike GCC/Clang on Linux. Fortunately, CMake provides a simple option to force symbol exports:

# Windows-specific options
if(WIN32)
    set(ENABLE_MULTITHREADING OFF)
    # Force MSVC to export all symbols when building a shared library
    set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
    if (ENABLE_TESTING)
        # Catch2 has issues being built as a shared library on Windows,
        # so use static libraries when building tests
        set(BUILD_SHARED_LIBS OFF)
    endif()
endif()

This resolves the shared library build issues. However, because Catch2 doesn’t play nicely as a DLL on Windows, I switched to static libraries for the testing build as a temporary workaround.

Regarding OpenMP, I spent some time trying to get it working under MSVC (including trying the new LLVM-based backend). Unfortunately, none of these attempts solved our existing compatibility problems. There doesn’t seem to be a quick or cost-free solution here, so we may need to accept that OpenMP support on Windows remains disabled for the time being.

[TysonRayJones]

Sure, making Catch2 static on Windows is inoffensive enough.

Ahh I see. Are there issues with OpenMP on Windows beyond the custom reduction? If so, then I agree with disabling for the moment. In any case, we should add a warning during the CMake build to alert multithreading has been forcefully disabled, so Windows users aren't astonished by poor performance.