[Bug c/109137] New: [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[Bug c/109137] New: [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

            Bug ID: 109137
           Summary: [12/13 regression] Compiling ffmpeg with -m32 on
                    x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c
                    since r12-9086-g489c81db7d4f75
           Product: gcc
           Version: 13.0
               URL: https://bugs.gentoo.org/900937
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sam at gentoo dot org
                CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Building ffmpeg for multilib (32-bit x86 on amd64, i.e. x86_64-pc-linux-gnu
-m32) hangs when using -O3 -march=znver1 on libavcodec/h264_cabac.c.

Notes:
- Originally reported downstream in Gentoo at https://bugs.gentoo.org/900937.
- 12.2.1 20230121 is good
- 12.2.1 20230304 is bad
- 13.0.1 20230312 is bad
- Seems to bisect to r12-9086-g489c81db7d4f75
- Needs CFLAGS="-O3 -march=znver1" to trigger

The bisect result 489c81db7d4f75894e9d34aa90fe7224cfafb53a
(r12-9086-g489c81db7d4f75) doesn't revert cleanly on tip of releases/gcc-12 so
I haven't been able to confirm that bit yet.

From `ps faux`:
```
sam      3394612  5.1  0.0  23596 19736 pts/11   SN+  00:19   0:02  |       |  
            \_ make -j32 -l32 V=1
sam      3399918  0.0  0.0   8180  3612 pts/11   SN+  00:20   0:00  |       |  
                \_ //usr/bin/x86_64-pc-linux-gnu-gcc -m32 -mfpmath=sse -I.
-Isrc/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DHAVE_AV_CONFIG_H
-DBUILDING_avcodec -march=znver1 -O3 -Werror=implicit-function-declaration
-Werror=implicit-int -Wreturn-type -Wformat -Wint-conversion -Waddress
-Warray-bounds -Wfree-nonheap-object -Wimplicit-function-declaration
-Wimplicit-int -Wincompatible-pointer-types -Wint-conversion
-Wint-to-pointer-cast -Wmain -Wnonnull -Wodr -Wparentheses -Wreturn-type
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstring-compare -Wuninitialized
-Wunused-value -Wvarargs -march=znver1 -std=c11 -fPIC
-Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith
-Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes
-Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses
-Wno-switch -Wno-format-zero-length -Wno-pointer-sign
-Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts
-march=znver1 -O3 -Werror=implicit-function-declaration -Werror=implicit-int
-Wreturn-type -Wformat -Wint-conversion -Waddress -Warray-bounds
-Wfree-nonheap-object -Wimplicit-function-declaration -Wimplicit-int
-Wincompatible-pointer-types -Wint-conversion -Wint-to-pointer-cast -Wmain
-Wnonnull -Wodr -Wparentheses -Wreturn-type -Wsizeof-pointer-memaccess
-Wstrict-aliasing -Wstring-compare -Wuninitialized -Wunused-value -Wvarargs
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=vla -Wformat -Wno-maybe-uninitialized -MMD -MF
libavcodec/h264_cabac.d -MT libavcodec/h264_cabac.o -c -o
libavcodec/h264_cabac.o src/libavcodec/h264_cabac.c
sam      3399921  100  0.1 109632 88364 pts/11   RN+  00:20   0:43  |       |  
                    \_ /usr/libexec/gcc/x86_64-pc-linux-gnu/13/cc1 -quiet -I .
-I src/ -imultilib 32 -MMD libavcodec/h264_cabac.d -MF libavcodec/h264_cabac.d
-MT libavcodec/h264_cabac.o -D _ISOC99_SOURCE -D _FILE_OFFSET_BITS=64 -D
_LARGEFILE_SOURCE -D _POSIX_C_SOURCE=200112 -D _XOPEN_SOURCE=600 -D PIC -D
HAVE_AV_CONFIG_H -D BUILDING_avcodec src/libavcodec/h264_cabac.c -quiet
-dumpdir libavcodec/ -dumpbase h264_cabac.c -dumpbase-ext .c -m32 -mfpmath=sse
-march=znver1 -O3 -O3 -Werror=implicit-function-declaration
-Werror=implicit-int -Wformat=1 -Warray-bounds=1 -Wdeclaration-after-statement
-Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast
-Wstrict-prototypes -Wempty-body -Wno-switch -Wno-format-zero-length
-Wno-pointer-sign -Wunused-const-variable=0 -Wno-bool-operation
-Wno-char-subscripts -Werror=implicit-function-declaration -Werror=implicit-int
-Wformat=1 -Waddress -Warray-bounds=1 -Wfree-nonheap-object
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Wint-conversion -Wint-to-pointer-cast -Wmain -Wnonnull -Wodr -Wparentheses
-Wreturn-type -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstring-compare
-Wuninitialized -Wunused-value -Wvarargs -Werror=format-security
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=vla -Wformat=1 -Wno-maybe-uninitialized -std=c11
-fPIC -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -o
/var/tmp/portage/media-video/ffmpeg-4.4.3/temp/cc7EadEm.s
```

---

Now, if I try to run it by itself, I get:
```
# /usr/bin/x86_64-pc-linux-gnu-gcc-12 -m32 -mfpmath=sse -I. -Isrc/
-D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DHAVE_AV_CONFIG_H
-DBUILDING_avcodec -march=znver1 -O3 -Werror=implicit-function-declaration
-Werror=implicit-int -Wreturn-type -Wformat -Wint-conversion -Waddress
-Warray-bounds -Wfree-nonheap-object -Wimplicit-function-declaration
-Wimplicit-int -Wincompatible-pointer-types -Wint-conversion
-Wint-to-pointer-cast -Wmain -Wnonnull -Wodr -Wparentheses -Wreturn-type
-Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstring-compare -Wuninitialized
-Wunused-value -Wvarargs -march=znver1 -std=c11 -fPIC
-Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith
-Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes
-Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses
-Wno-switch -Wno-format-zero-length -Wno-pointer-sign
-Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts
-march=znver1 -O3 -Werror=implicit-function-declaration -Werror=implicit-int
-Wreturn-type -Wformat -Wint-conversion -Waddress -Warray-bounds
-Wfree-nonheap-object -Wimplicit-function-declaration -Wimplicit-int
-Wincompatible-pointer-types -Wint-conversion -Wint-to-pointer-cast -Wmain
-Wnonnull -Wodr -Wparentheses -Wreturn-type -Wsizeof-pointer-memaccess
-Wstrict-aliasing -Wstring-compare -Wuninitialized -Wunused-value -Wvarargs
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -Werror=vla -Wformat -Wno-maybe-uninitialized -MMD -MF
libavcodec/h264_cabac.d -MT libavcodec/h264_cabac.o -c -o
libavcodec/h264_cabac.o src/libavcodec/h264_cabac.c
In file included from src/libavcodec/cabac_functions.h:47,
                 from src/libavcodec/h264_cabac.c:36:
In function 'get_cabac_inline_x86',
    inlined from 'get_cabac' at src/libavcodec/cabac_functions.h:140:12,
    inlined from 'decode_cabac_mb_intra4x4_pred_mode' at
src/libavcodec/h264_cabac.c:1368:9,
    inlined from 'ff_h264_decode_mb_cabac' at
src/libavcodec/h264_cabac.c:2072:32:
src/libavcodec/x86/cabac.h:194:5: error: 'asm' operand has impossible
constraints
  194 |     __asm__ volatile(
      |     ^~~~~~~
src/libavcodec/x86/cabac.h:194:5: error: 'asm' operand has impossible
constraints
src/libavcodec/x86/cabac.h:194:5: error: 'asm' operand has impossible
constraints
src/libavcodec/x86/cabac.h:194:5: error: 'asm' operand has impossible
constraints
[... hangs here ...]
```

But with GCC 11, it completes very quickly (1s or so, or less) with no errors.

[Bug c/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #1 from Sam James <sam at gentoo dot org> ---
Created attachment 54667
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54667&action=edit
h264_cabac.i

With the attached h264_cebac.i:
- gcc-11 -m32 -c h264_cabac.i -O3 -march=znver1 # works
- gcc-12 -m32 -c h264_cabac.i -O3 -march=znver1 # errors-then-hangs
- gcc-13 -m32 -c h264_cabac.i -O3 -march=znver1 # errors-then-hangs

The .i is generated by GCC 12.

[Bug c/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #2 from Sam James <sam at gentoo dot org> ---
(I suspect ffmpeg's build system does some
buffering/synchronisation/suppression of output until a job is complete which
is why it looks like a hang with no output at all, while running it manually
gets errors-then-hang.)

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=106364

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely just a dup of bug 106364 .

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note I think get_cabac_inline_x86 is just broken inline-asm ...

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The inline-asm inside get_cabac_inline_x86 needs 7 registers (6 + ecx is used
as a clobber). So obviously it will be really bad on 32bit x86.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #6 from Sam James <sam at gentoo dot org> ---
(In reply to Andrew Pinski from comment #5)
> The inline-asm inside get_cabac_inline_x86 needs 7 registers (6 + ecx is
> used as a clobber). So obviously it will be really bad on 32bit x86.

Ah, thanks, I get it. It looks like this actually came up before in
https://trac.ffmpeg.org/ticket/8903 and
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8990c5869e27fcd43b53045f87ba251f42e7d293;hp=c64d56a2f53455f803456811873ff08fce98e122
but they just disabled it for Clang?

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sam James from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > The inline-asm inside get_cabac_inline_x86 needs 7 registers (6 + ecx is
> > used as a clobber). So obviously it will be really bad on 32bit x86.
> 
> Ah, thanks, I get it. It looks like this actually came up before in
> https://trac.ffmpeg.org/ticket/8903

From that one:
"Fixed a while ago for 32-bit clang, although now it's popping up for 32-bit
gcc as well" :)

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.3
      Known to fail|                            |12.2.1
      Known to work|                            |12.2.0
           Priority|P3                          |P1

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Honza, the reporter uses -march=znver1 - why did these backports affect
anything but zen4?

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> Honza, the reporter uses -march=znver1 - why did these backports affect
> anything but zen4?


(X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 15 Mar 2023, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
> 
> --- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #8)
> > Honza, the reporter uses -march=znver1 - why did these backports affect
> > anything but zen4?
> 
> 
> (X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
> (X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.

But Zen1 uses a split AVX pipe so I'm not sure that's the best idea?

Anway, I'd revert this change completely on the branch and only
keep the znver4 effects.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't see any hangs.
With just -O3 -m32 -march=znver1 both latest GCC 12 branch and latest trunk
print the 4
error: ‘asm’ operand has impossible constraints
errors and exits, with -fpie additionally there is an ICE:
during RTL pass: reload
src/libavcodec/h264_cabac.c: In function ‘ff_h264_decode_mb_cabac’:
src/libavcodec/h264_cabac.c:2490:1: internal compiler error: maximum number of
LRA assignment passes is achieved (30)
0x1213bde lra_assign(bool&)
        ../../gcc/lra-assigns.cc:1694
0x120e5b2 lra(_IO_FILE*)
        ../../gcc/lra.cc:2426
0x11bf889 do_reload
        ../../gcc/ira.cc:5963
0x11bf889 execute
        ../../gcc/ira.cc:6149
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

CCing Vlad for possible better error recovery here.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, but
1690      if (flag_checking
1691          && (lra_assignment_iter_after_spill
1692              > LRA_MAX_ASSIGNMENT_ITERATION_NUMBER))
1693        internal_error
1694          ("maximum number of LRA assignment passes is achieved (%d)",
1695           LRA_MAX_ASSIGNMENT_ITERATION_NUMBER);
is guarded with -fchecking.  So it really hangs with -fno-checking.
Now, on the
error: ‘asm’ operand has impossible constraints
errors the problematic insns are removed:
1864                  PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx);
1865                  lra_set_insn_deleted (insn);
or nulified in case of asm goto, so wonder whether some LRA state shouldn't be
reset at that point as well or what is the reason for the > 30 iterations.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 16 Mar 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
> 
> --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Ah, but
> 1690      if (flag_checking
> 1691          && (lra_assignment_iter_after_spill
> 1692              > LRA_MAX_ASSIGNMENT_ITERATION_NUMBER))
> 1693        internal_error
> 1694          ("maximum number of LRA assignment passes is achieved (%d)",
> 1695           LRA_MAX_ASSIGNMENT_ITERATION_NUMBER);
> is guarded with -fchecking.  So it really hangs with -fno-checking.
> Now, on the
> error: ‘asm’ operand has impossible constraints
> errors the problematic insns are removed:
> 1864                  PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx);
> 1865                  lra_set_insn_deleted (insn);
> or nulified in case of asm goto, so wonder whether some LRA state shouldn't be
> reset at that point as well or what is the reason for the > 30 iterations.

"easy" out would be to do flag_checking || error_count?

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #13)
> "easy" out would be to do flag_checking || error_count?

Then for release checking we'd emit the ICE replacement message, but yes.
Another possibility would be to do some early exit from later LRA stages if
seen_error (), just make sure we destroy/free everything we need and then in
pass_postreload also
don't process stuff further if seen_error () (similarly to how
pass_rest_of_compilation
returns false from its gate if seen_error ()).

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I've reproduced hanging up but for the particular commit. I also reproduced
internal compiler error on the current master.

I'll try to fix the both problems on this week.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Vladimir Makarov <vmakarov@gcc.gnu.org>:

https://gcc.gnu.org/g:81d762cbec9685c2f2571da21d48f42c42eff33b

commit r13-6804-g81d762cbec9685c2f2571da21d48f42c42eff33b
Author: Vladimir N. Makarov <vmakarov@redhat.com>
Date:   Wed Mar 22 12:33:11 2023 -0400

    LRA: Do not repeat inheritance and live range splitting in case of asm
error

    LRA was trying to do live range splitting again and again as there were
    no enough regs for asm.  This patch solves the problem.

            PR target/109137

    gcc/ChangeLog:

            * lra.cc (lra): Do not repeat inheritance and live range splitting
            when asm error is found.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr109137.c: New.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Jakub Jelinek <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> ---
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.

[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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce

commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce
Author: Jakub Jelinek <jakub@redhat.com>
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 <string.h> for a RA test seems unnecessary,
__builtin_memset
       handles it without the header

    2023-03-24  Jakub Jelinek  <jakub@redhat.com>

            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 <string.h>, 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

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #20 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce
> 
> commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce
> Author: Jakub Jelinek <jakub@redhat.com>
> 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 <string.h> 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

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #21 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #23 from rguenther at suse dot de <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 <hubicka at gcc dot gnu.org> ---
> 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

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #24 from Sam James <sjames at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jan Hubicka
<hubicka@gcc.gnu.org>:

https://gcc.gnu.org/g:9075b0f19eece7d5ddf948204507b5dae9d292c4

commit r12-9400-g9075b0f19eece7d5ddf948204507b5dae9d292c4
Author: Jan Hubicka <jh@suse.cz>
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  <hubicka@ucw.cz>

            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

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

--- Comment #26 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.3                        |12.4

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.