Possible fix for srep64 v393a data corruption - need more testing

[elit]

Here is a recompiled srep64 with latest gcc/msys2 and eased compiler flags that *maybe* solved data corruption during compression when computer is under heavy load. To understand the issue better start reading from here:
https://encode.ru/threads/231-FreeArc-compression-suite-(4x4-Tornado-REP-Delta-Dict-)?p=56416&viewfull=1#post56416

If you had same(exactly same not other) issue with latest srep393a through exe/stdio(dont know about cls), and whether this solved the problem or not please let me know.

[oltjon]

what is the difference between (srep64_generic_sse2) and (srep64_haswell)??

[kassane]

what is the difference between (srep64_generic_sse2) and (srep64_haswell)??

Processors:
AMD = Generic,
Intel = Haswell;

[elit]

haswell = -march=native (I have 4690k) (this will not work on lower cpu than haswell series and maybe even higher not - like amd perhaps)
generic = -mtune=native -msse2 (this will work on any x64 cpu with sse2)

[elit]

Unfortunately, issue still remain, albeit it does seems to me occurrence is less frequent. This night I packed another 17g data, one with srep+xnlz and another with srep+lolz. First one tested without error but on another one I got srep error again. Therefore, I consider this issue NOT fixed. Please ignore this thread/links for now unlit real 100% solution is found. I read elsewhere that increasing srep's block size may help so I will try that for some period and see.

[elit]

Just a quick note, last night I tried to pack ~30gb again, I used standard shipped exe not the one self-recompiled I posted here. However this time I tried with acceleration disabled: a0. And it did packed properly. I will post again after some time and more data tests on whether this option really solved the problem or not.(Btw increasing block size did not.)