https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #6 from mateuszb at poczta dot onet.pl --- W dniu 17.12.2018 o 10:20, rguenth at gcc dot gnu.org pisze: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521 > > --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- > Since the patch changes the ABI can it be you have library dependences with > the > old ABI around? I have 2 GCC binaries compiled from sources -- r266354 and r266355. If I compile x265 by old GCC (266354), next delete x265.exe, replace compiler by new GCC (266355) and execute 'make' -- it will be x265.exe that is compiled by old GCC and linked by new GCC (x265o-n.exe). x265n-o.exe is x265 compiled by new GCC and linked by old GCC, x265o.exe -- x265 compiled and linked by old GCC, x265n.exe -- x265 compiled and linked by new GCC. Encoding results (--crf 20 --no-asm): x265o.exe -- encoded 600 frames in 104.10s (5.76 fps), 4187.99 kb/s, Avg QP:25.15 x265n.exe -- encoded 600 frames in 94.14s (6.37 fps), 4670.69 kb/s, Avg QP:43.14 x265o-n.exe -- encoded 600 frames in 58.90s (10.19 fps), 112.00 kb/s, Avg QP:51.00 x265n-o.exe -- encoded 600 frames in 241.80s (2.48 fps), 238059.27 kb/s, Avg QP:0.00 It is quite possible that the problem is in mingw-w64 code that uses ASM or inline ASM and assume old GCC behavior. The movie produced by x265n-o.exe is not lossless but the quality is really OK (almost impossible with wrong compiler). I will try to dig deeper...
