Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Hmm...
https://docs.microsoft.com/en-us/cpp/build/x64-calling-conve...
> Return values
> A scalar return value that can fit into 64 bits, including the __m64 type, is returned through RAX. Non-scalar types including floats, doubles, and vector types such as __m128, __m128i, __m128d are returned in XMM0. The state of unused bits in the value returned in RAX or XMM0 is undefined.
> User-defined types can be returned by value from global functions and static member functions. To return a user-defined type by value in RAX, it must have a length of 1, 2, 4, 8, 16, 32, or 64 bits. It must also have no user-defined constructor, destructor, or copy assignment operator. It can have no private or protected non-static data members, and no non-static data members of reference type. It can't have base classes or virtual functions. And, it can only have data members that also meet these requirements. (This definition is essentially the same as a C++03 POD type. Because the definition has changed in the C++11 standard, we don't recommend using std::is_pod for this test.) Otherwise, the caller must allocate memory for the return value and pass a pointer to it as the first argument. The remaining arguments are then shifted one argument to the right. The same pointer must be returned by the callee in RAX.
Isn't this what https://github.com/ziglang/zig/issues/9998#issuecomment-9970... claims to be undocumented?
-
A couple more details:
> The pseudo reloc code does not output any errors when the address overflows; would probably be worth a pull request
I actually did this, to make it error out cleanly instead of having to debug this very non-obvious issue, quite recently: https://github.com/mingw-w64/mingw-w64/commit/ca35236d9799af...
(It's not in any stable release yet, but MSYS2 might be packaging recent git snapshots that could contain it.)
> Check to see if your MinGW program has unexpected imports to kernel32.VirtualProtect!
The runtime pseudo relocation fixing code ends up linked into your executables even if the executable doesn't use any runtime pseudo relocations - so essentially all MinGW programs will end up importing this function. That doesn't mean it does get called though.
I actually did look into fixing it, to make it only be pulled in when something needs it. It would need changes both to the linkers (binutils ld.bfd and lld) and mingw-w64-crt. I do have WIP patches for this for lld and mingw-w64-crt, but I'm not familiar with with the ld.bfd internals to take on fixing that. Plus that changing it would break older versions of the linker, so it would require quite a bit of a transition phase.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
My last experience with MinGW-w64 was when I was trying to compile my C++ simulation code in Windows and finding out that AVX instructions were not working because the compiler had misalignment-related bugs. (The issue is still open in https://github.com/msys2/MSYS2-packages/issues/1209)
MinGW/MSYS certainly had appeal to former Linux devs who didn't want to touch the horrors of MSVC, but Zig (with its included Clang compiler/runtime) might end up being a better solution for people trying to compile C/C++ code on Windows in a stable manner.
-
Clang (and lld) do support native TLS, and mingw-w64 does have the things that are needed. I think binutils also might have what's needed too, but AFAIK the thing that's missing is support for it in GCC.
Actually, (upstream) Clang defaults to native TLS instead of emulated TLS. In MSYS2, Clang is overridden to use emulated TLS by deafult to interoperate better with GCC built code and libstdc++ though.
The toolchain I maintain, https://github.com/mstorsjo/llvm-mingw, defaults to native TLS throughout.
-
Hi JB! Funny to cross paths with you in this context. I don't know if you remember me but I was a rookie programmer who got the pleasure of joining the VideoLan Conference in Dublin back in 2014, and then Paris the next year, and you were very kind to me.
The GitHub issue title here is unfortunately misleading. I have renamed it to "ideas to improve windows header files and libc". Also, I hope it is clear that I rebutted the points made by the OP, because I completely agree with your summary that the mingw-w64 people are skilled, nice and very clever and think about all use cases.
If any drive-by HN readers work at Microsoft, please help us with this issue: https://github.com/microsoft/win32metadata/issues/766
-
glibc-abi-tool
A repository that collects glibc .abilist files for every version and a tool to combine them into one dataset.
