my rant against MS-Windows

[abulmo2]

Not a compiler-issue. In your use-case you would have to wait for magaia 10 I suppose.

Thanks for the information. (Meanwhile someone said to me the same thing on a Mageia forum.)

I made some changes in versions 3.0/3.1. It should compile on Linux distribution with old libraries.

[jdart]

PGO works with the MSVC compiler and with clang-cl. You do need to set it up/execute it properly.
I have a NMAKE Makefile that supports PGO compilation for my engine: https://raw.githubusercontent.com/jdart ... kefile.win.

[mar]

Well, some people consider the C library part of the OS, not of the compiler. All the C compilers I know (clang, mingw gcc, msvc, intel, pelles, etc.) do not bring their own library but use the libraries (yes they are several of them, none working well) provided by Microsoft.

you're probably talking about msvcrt.dll - that's used internally by some windows OS programs (also used by mingw)
- for a small subset of the C runtime functions (and in fact microsoft discourages to link against it, recent msvc-compiled programs don't link against a single msvcrt.dll, you can check yourself)

you definitely want to inline intrinsics/atomics, so they wouldn't be linked dynamically either way

some programs require to install the so called "redistributables" before they can work - installing a specific CRT for that specific version of the compiler since it doesn't come as part of the OS - honestly I don't know how many runtimes they actually bundle along with the OS these days, but the days where there was only one C runtime dll for everything are gone, now it's split to many smaller dll files and also depend on the compiler version (eg vcruntime140.dll, api-ms-blah....dll and so on)

that being said - dynamic crt on windows became an insane mess so these days I prefer single-executable binaries and link against the crt statically, it's a bit bigger but it runs with zero dependencies (also the linker removes unused functions).

[Roland Chastain]

I made some changes in versions 3.0/3.1. It should compile on Linux distribution with old libraries.

Thank you, but unfortunately I get the following error:

Code: Select all

clang -std=c2x -Wall -W -pedantic -O3 -flto -DNDEBUG -march=native -fprofile-instr-generate mperft.c -o ./mperft -lm
mperft.c:464:9: error: use of undeclared identifier 'stdc_trailing_zeros_ull'
        return stdc_trailing_zeros_ull(b);
               ^
mperft.c:898:24: error: use of undeclared identifier 'stdc_count_zeros_ull'
                mask->bishop.shift = stdc_count_zeros_ull(mask->bishop.mask);
                                     ^
mperft.c:900:66: error: use of undeclared identifier 'stdc_count_ones_ull'
                if (x) mask->bishop.attack = mask[-1].bishop.attack + (1ull << stdc_count_ones_ull(mask[-1].bishop.mask));

And the Linux binary available on Releases page doesn't work here:

Code: Select all

$ ./mperft-3.2-x86-64
./mperft-3.2-x86-64: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./mperft-3.2-x86-64)

[abulmo2]

I made some changes in versions 3.0/3.1. It should compile on Linux distribution with old libraries.

Thank you, but unfortunately I get the following error:

Code: Select all

clang -std=c2x -Wall -W -pedantic -O3 -flto -DNDEBUG -march=native -fprofile-instr-generate mperft.c -o ./mperft -lm
mperft.c:464:9: error: use of undeclared identifier 'stdc_trailing_zeros_ull'
        return stdc_trailing_zeros_ull(b);
               ^
mperft.c:898:24: error: use of undeclared identifier 'stdc_count_zeros_ull'
                mask->bishop.shift = stdc_count_zeros_ull(mask->bishop.mask);
                                     ^
mperft.c:900:66: error: use of undeclared identifier 'stdc_count_ones_ull'
                if (x) mask->bishop.attack = mask[-1].bishop.attack + (1ull << stdc_count_ones_ull(mask[-1].bishop.mask));

And the Linux binary available on Releases page doesn't work here:

Code: Select all

$ ./mperft-3.2-x86-64
./mperft-3.2-x86-64: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./mperft-3.2-x86-64)

Yes, I mispelled __GNUC__ at line 39 of my code and my tests did not show it. As I am far away from home, I will made a release next week, maybe with a static executable that do not depend on libc. You can try to compile the file on github's main branch that contains the fix.