std::cos produces different results in GCC and MSVC

IEEE 754 / IEC 60559, which apply to most C++ platforms, have a "correctly rounded" (i.e. max of 0.5 ULP error) requirement imposed on the basic operations, but that does not apply to trig functions.

Math functions can have more error and most implementers aim for 1.0 ULP maximum error, meaning that the final bit can differ between implementations and not be considered a bug.

This functions are implemented by the standard library. Since MSVC and gcc are using different standard library their implementation might be different. Both are using some approximation of this functions. In your case expected value most probably is in the middle between values which can be represented by double type and during calculation errors have accumulated in different way leading to minimal divergence between those libraries.

So this is simple rounding issue and result of using different algorithm to calculate cos.

Note there is x86 instruction FCOS, but it has so poor accuracy guaranties and so slow that compilers are using own implementations.

The Difference Between x87 Instructions FSIN, FCOS, FSINCOS, and...

The purpose of this paper is to inform users of many of the implementation details of the x87 trigonometric instructions. If users find that the x87 elementary transcendental instructions are not adequate for their needs, they should consider using the software libraries of transcendental functions available through the Intel® C++ Compiler and Intel® Fortran Compiler, the Intel® Math Kernel Library (Intel® MKL) product, or libraries from other providers. Just as double precision arithmetic is provided to users when single precision floating-point arithmetic is not adequate, so these software library functions provide more accurate approximations when the x87 instructions are not adequate.

The paper explains that FSIN(x), FCOS(x), FSINCOS(x) and FPTAN(x) are approximations of the corresponding mathematical functions of argument (x • π/p), and not of argument (x). Therefore they can only be used to approximate the mathematical functions sin(x), cos(x), and tan(x) on a limited domain, outside of which a more accurate argument reduction technique is necessary in order to contain the errors, or, alternatively, accurate software implementations of these mathematical functions may to be used.

Accuracy of floating point operations is standardized this way: https://eel.is/c++draft/basic.fundamental#12

Except as specified in [basic.extended.fp], the object and value representations and accuracy of operations of floating-point types are implementation-defined.

(emphasis mine).

Unfortunately, I see no way to enforce that different implementations give the same results.

STerliakov link is interesting in this regard, in order to get more insights. And also an academic reference and the most recent version to this day (thanks to Martin Brown).

As commented by Jesper Juhl, when dealing with floating point operations, consider that there are no such thing as strict equality: give you an expected acceptable relative or absolute error, which depend on your exact application.