gcc 9 bug about stockfish HOT 11 CLOSED

It’s part of the other pr. This is currently not an issue in stockfish. It’s only an issue in your pr, where you should propose a solution

from stockfish.

Tbh I'm with maxim here. If a compiler bug can cause PRs to get false CI results, that is a problem for the project as a whole, not merely any such PR.

from stockfish.

@dubslow The proposed PR introduces such a gcc bug, it currently doesnt exist to my understanding in master.
So I dont see why there should be an issue for a compiler bug for code that currently doesnt exist in master.
It's the PR's job to come up with a solution.

And simply removing the used version aint it, as vondele said.

from stockfish.

This shouldn’t be issue since it’s only an issue of your other pr imo.

from stockfish.

This intrinsic makes Elo gain. Should I put IFDEF GCC? Or abandon the PR? But it makes Elo gain and speedup.

from stockfish.

This intrinsic allows to make one 512-bit memory load and then split to four 128-bit registers instead of four 128-bit memory loads and vice versa - combine four 128-bit registers to one 512-bit registers and make one 512-bit memory store. This approach is faster on AMD with 256 memory load/store units, and even faster on Intel with 512-bit memory load/store units.

If we can avoid this gcc 9 bug either by IFDEF GCC (to make this approach work only under GCC 10+ or clang) we can make further speedups on different places of Stockfish.

from stockfish.

There are probably many more compiler bugs out there, should we create an issue for all possible ones and fix what we don’t have currently ?

from stockfish.

Maybe update CI to not use an ancient version of gcc?

from stockfish.

any compiler has plenty of code generation bugs. gcc 9 is still pretty widely used, it is good to have it part of the CI. It would be an issue if we run into the bug with the master version of SF. If there is a bug in a widely used compiler we can have a workaround for that in the code, there are other examples in SF that have such workarounds. Of course, the fewer such workarounds needed, the better.

see types.h near line 60.

from stockfish.

@Disservin come now dont be silly, only compiler bugs which are directly proven to cause issues, such as this case.

vondele has the right of it. Do a standard cost-benefit analysis. In this case, the PR's purported claim of few-or-several-percent speedup on certain arches may well be worth the cost of either adding a workaround or removing the version from the CI.

from stockfish.

@dubslow The proposed PR introduces such a gcc bug, it currently doesnt exist to my understanding in master. So I dont see why there should be an issue for a compiler bug for code that currently doesnt exist in master. It's the PR's job to come up with a solution.

And simply removing the used version aint it, as vondele said.

With Disservin here. The PR should include the solution. It can edit CIs as well. ;)

from stockfish.