[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 Richard Biener changed: What|Removed |Added Target Milestone|12.3|12.4 --- Comment #28 from Richard Biener --- GCC 12.3 is being released, retargeting bugs to GCC 12.4.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 Richard Biener changed: What|Removed |Added Priority|P1 |P2 --- Comment #27 from Richard Biener --- The actual regression is fixed, the latent issue remains, I'm at least removing P1 now.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #26 from Jan Hubicka --- reverted the znver1-3 change on gcc-12 branch. We still may want to fix IRA to avoid the problem on core_avx512 targets.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #25 from CVS Commits --- The releases/gcc-12 branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:9075b0f19eece7d5ddf948204507b5dae9d292c4 commit r12-9400-g9075b0f19eece7d5ddf948204507b5dae9d292c4 Author: Jan Hubicka Date: Fri Apr 14 19:18:24 2023 +0200 Disable X86_TUNE_AVX256_MOVE_BY_PIECES and STORE_BY_PIECES for znver1-3 I have enabled SSE moves for znver1-3 since they are performance win on this machine too (we avoid using loops or string operations which are more costy). However as discussed in the PR log, this triggers bug in IRA and it was decided it is better to not backport the fix. gcc/ChangeLog: 2023-04-14 Jan Hubicka PR target/109137 * config/i386/x86-tune.def (X86_TUNE_AVX256_MOVE_BY_PIECES): Remove znver1-3. (X86_TUNE_AVX256_STORE_BY_PIECES): Remove znver1-3.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #24 from Sam James --- As a heavy consumer of the branch for our distribution, I'd say it was a (nice) surprise, but then I wasn't expecting it to end up exposing a latent bug (or making it worse). At the end of the day, not much harm done in this case, as we noticed it pretty quickly. glibc also tends to backport tuning improvements (often more invasive than this) which is also sometimes a bit controversial.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #23 from rguenther at suse dot de --- On Thu, 30 Mar 2023, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 > > --- Comment #21 from Jan Hubicka --- > Zen 1-3 changes were intentional in the original tuning patch (it is also > briefly mentioned in the commit message). By allowing 256 bit AVX moves > instead of 64bit integer moves (or 128bit) we can move bigger blocks of memory > without loops and it was faster in micro-benchmarks I made on all zens, even > on > znver1. > We also automatically go for 128bit moves when ISA allows that. Sure, but this change is IMHO surprising for people on the branch so I'd rather not do this.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #22 from Jakub Jelinek --- Sure. The point was to avoid regressions on the release branch because of so big changes for the tunings which were supported before already. So we might want both the LRA changes and perhaps zen1-3 reversion.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #21 from Jan Hubicka --- Zen 1-3 changes were intentional in the original tuning patch (it is also briefly mentioned in the commit message). By allowing 256 bit AVX moves instead of 64bit integer moves (or 128bit) we can move bigger blocks of memory without loops and it was faster in micro-benchmarks I made on all zens, even on znver1. We also automatically go for 128bit moves when ISA allows that. We could revert that part of backport, but won't we get same hangs with -march=znver4 or core512 which also enables avx512 moves? (I am rebuilding gcc12 to see what happens)
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #20 from Vladimir Makarov --- (In reply to CVS Commits from comment #19) > The master branch has been updated by Jakub Jelinek : > > https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce > > commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce > Author: Jakub Jelinek > Date: Fri Mar 24 09:42:18 2023 +0100 > > testsuite: Fix up gcc.target/i386/pr109137.c testcase [PR109137] > > The testcase has a couple of small problems: > 1) had -m32 in dg-options, that should never be done, instead the test >should be guarded on ia32 > 2) adds -fPIC unconditionally (that should be guarded on fpic effective >target) > 3) using #include for a RA test seems unnecessary, > __builtin_memset >handles it without the header Thank you for the test correction, Jakub.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #19 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce Author: Jakub Jelinek Date: Fri Mar 24 09:42:18 2023 +0100 testsuite: Fix up gcc.target/i386/pr109137.c testcase [PR109137] The testcase has a couple of small problems: 1) had -m32 in dg-options, that should never be done, instead the test should be guarded on ia32 2) adds -fPIC unconditionally (that should be guarded on fpic effective target) 3) using #include for a RA test seems unnecessary, __builtin_memset handles it without the header 2023-03-24 Jakub Jelinek PR target/109137 * gcc.target/i386/pr109137.c: Remove -m32 from dg-options, instead require ia32 effective target. Only add -fPIC for fpic effective target. Remove #include , use __builtin_memset instead of memset.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2023-03-23 Summary|[12/13 regression] |[12 regression] Compiling |Compiling ffmpeg with -m32 |ffmpeg with -m32 on |on x86_64-pc-linux-gnu |x86_64-pc-linux-gnu hangs |hangs on|on libavcodec/h264_cabac.c |libavcodec/h264_cabac.c |since |since |r12-9086-g489c81db7d4f75 |r12-9086-g489c81db7d4f75| Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #18 from Jakub Jelinek --- Actually, only fixed on the trunk so far. But on 12 branch as discussed I think we should instead revert the zen1-3 changes and only keep zen4.
