x8664 Linux and x8664 windows are the same, apart that windows uses LLP64 model (so long is 32 bit only, not 64 as on linux).

How is this relevant for floating point arithmetic?

That may be just a bug in compiler gcc or clang vs msvc on windows.

You admit yourself that the relative errors here are below what agents on the market agreed on to be sufficient. So none of the compiler vendors would consider this a bug.

That is not what is the problem here, the problem is reproducability.

What I am trying to tell you: You simply cannot expect this degree of reproducability between different systems.

This was fixed in gcc (maybe in 2020? I do not quite remember): https://stackoverflow.com/questions/13774912/gcc-c-pow-accuracy

I would not call the integer-rounding of int(std::pow(100,2)) to 99 a bug. I would rather call fixing this "adding a feature". From a floating point of view, 100 - 0.5 * ulp(100) would be a perfectly correct result for std::pow(100,2). The issue is solely that the integer cast operator rounds always towards zero. This comes quite unexpected for most of us. So probably the gcc developers decided that it might be nice (and lead to less confusion) if every result that can be expressed exactly by floating point numbers would also be represented correctly. But your example 1/(-1.)^1.2 cannot be represented exacly by a floating point number. So one has no choice to rescue to some approximation. And I doubt that there is any standard that mandates, how 1/(-1.)^1.2 has to be evaluated. The only reasonable thing is to expect is that the relative error is in the order of 1 ulp or half an ulp. So I even wonder why you think the Windows version would be the ground truth. Maybe it was only by chance that it returned a "better" result?

Anyways, if you simply want to file a bug report, then why don't you do it where these are supposed to go? Neither Wolfram Community nor Mathematica.StackExchange.com are the right places for that.

Strictly speaking we are in 2023, so new algorithms were invented to make libm to ideal 0.5 ulp (which exp(), expm1(), exp(), pow() are a part of, as part of language C math.h) and more or less as fast. This: https://gitlab.inria.fr/core-math/core-math/

You simply cannot expect this degree of reproducability between different systems.

Linux and Microsoft are almost the same OS, except for the LLP64 in Windows and modular kernel vs Hybrid kernel and a different default inside default floating point control register (i.e. FPCSR\NPXCW) between Linux and NT: glibc assumes 0x37f but NT uses 0x27f (not a problem outside WSL1, see my comment https://github.com/microsoft/WSL/issues/830#issuecomment-507988489 ). That is all I know of. All other differences come from bugs inside MSVC and wrong use of flags inside gcc.

So none of the compiler vendors would consider this a bug.

You assume a bug like that was not opened and not already fixed in gcc 13. This was fixed in gcc (maybe in 2020? I do not quite remember): https://stackoverflow.com/questions/13774912/gcc-c-pow-accuracy

Well, I just used infinite precision: [...]

So does Windows always find the "right" solution? Or did it find it here just by chance?

What? Why??

Mathematica.StackExchange.com is purely community-driven. It is not an official channel by Wolfram Research. And, although being an outlet by Wolfram Research, Wolfram Community is also not meant as bug tracker. You should better contact Wolfram Support and issue a bug report there. But I am pretty sure that they will tell you the same as I do.