* [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
2023-03-15 0:30 [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
@ 2023-03-15 0:31 ` sam at gentoo dot org
2023-03-15 0:33 ` sam at gentoo dot org
` (27 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: sam at gentoo dot org @ 2023-03-15 0:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
2023-03-15 0:31 ` [Bug c/109137] " sam at gentoo dot org
@ 2023-03-15 0:33 ` sam at gentoo dot org
2023-03-15 0:38 ` [Bug target/109137] " pinskia at gcc dot gnu.org
` (26 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: sam at gentoo dot org @ 2023-03-15 0:33 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
2023-03-15 0:31 ` [Bug c/109137] " sam at gentoo dot org
2023-03-15 0:33 ` sam at gentoo dot org
@ 2023-03-15 0:38 ` pinskia at gcc dot gnu.org
2023-03-15 0:40 ` pinskia at gcc dot gnu.org
` (25 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-15 0:38 UTC (permalink / raw)
To: gcc-bugs
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 .
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (2 preceding siblings ...)
2023-03-15 0:38 ` [Bug target/109137] " pinskia at gcc dot gnu.org
@ 2023-03-15 0:40 ` pinskia at gcc dot gnu.org
2023-03-15 0:44 ` pinskia at gcc dot gnu.org
` (24 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-15 0:40 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (3 preceding siblings ...)
2023-03-15 0:40 ` pinskia at gcc dot gnu.org
@ 2023-03-15 0:44 ` pinskia at gcc dot gnu.org
2023-03-15 0:58 ` sam at gentoo dot org
` (23 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-15 0:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (4 preceding siblings ...)
2023-03-15 0:44 ` pinskia at gcc dot gnu.org
@ 2023-03-15 0:58 ` sam at gentoo dot org
2023-03-15 1:06 ` pinskia at gcc dot gnu.org
` (22 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: sam at gentoo dot org @ 2023-03-15 0:58 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (5 preceding siblings ...)
2023-03-15 0:58 ` sam at gentoo dot org
@ 2023-03-15 1:06 ` pinskia at gcc dot gnu.org
2023-03-15 8:38 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-15 1:06 UTC (permalink / raw)
To: gcc-bugs
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" :)
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (6 preceding siblings ...)
2023-03-15 1:06 ` pinskia at gcc dot gnu.org
@ 2023-03-15 8:38 ` rguenth at gcc dot gnu.org
2023-03-15 8:42 ` pinskia at gcc dot gnu.org
` (20 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-15 8:38 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (7 preceding siblings ...)
2023-03-15 8:38 ` rguenth at gcc dot gnu.org
@ 2023-03-15 8:42 ` pinskia at gcc dot gnu.org
2023-03-15 9:00 ` rguenther at suse dot de
` (19 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-15 8:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (8 preceding siblings ...)
2023-03-15 8:42 ` pinskia at gcc dot gnu.org
@ 2023-03-15 9:00 ` rguenther at suse dot de
2023-03-16 10:03 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2023-03-15 9:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (9 preceding siblings ...)
2023-03-15 9:00 ` rguenther at suse dot de
@ 2023-03-16 10:03 ` jakub at gcc dot gnu.org
2023-03-16 10:22 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-16 10:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (10 preceding siblings ...)
2023-03-16 10:03 ` jakub at gcc dot gnu.org
@ 2023-03-16 10:22 ` jakub at gcc dot gnu.org
2023-03-16 10:41 ` rguenther at suse dot de
` (16 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-16 10:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (11 preceding siblings ...)
2023-03-16 10:22 ` jakub at gcc dot gnu.org
@ 2023-03-16 10:41 ` rguenther at suse dot de
2023-03-16 10:58 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2023-03-16 10:41 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (12 preceding siblings ...)
2023-03-16 10:41 ` rguenther at suse dot de
@ 2023-03-16 10:58 ` jakub at gcc dot gnu.org
2023-03-21 14:56 ` vmakarov at gcc dot gnu.org
` (14 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-16 10:58 UTC (permalink / raw)
To: gcc-bugs
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 ()).
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (13 preceding siblings ...)
2023-03-16 10:58 ` jakub at gcc dot gnu.org
@ 2023-03-21 14:56 ` vmakarov at gcc dot gnu.org
2023-03-22 17:36 ` cvs-commit at gcc dot gnu.org
` (13 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2023-03-21 14:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (14 preceding siblings ...)
2023-03-21 14:56 ` vmakarov at gcc dot gnu.org
@ 2023-03-22 17:36 ` cvs-commit at gcc dot gnu.org
2023-03-23 16:25 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-03-22 17:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (15 preceding siblings ...)
2023-03-22 17:36 ` cvs-commit at gcc dot gnu.org
@ 2023-03-23 16:25 ` jakub at gcc dot gnu.org
2023-03-23 18:15 ` [Bug target/109137] [12 " jakub at gcc dot gnu.org
` (11 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-23 16:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (16 preceding siblings ...)
2023-03-23 16:25 ` jakub at gcc dot gnu.org
@ 2023-03-23 18:15 ` jakub at gcc dot gnu.org
2023-03-24 8:45 ` cvs-commit at gcc dot gnu.org
` (10 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-23 18:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (17 preceding siblings ...)
2023-03-23 18:15 ` [Bug target/109137] [12 " jakub at gcc dot gnu.org
@ 2023-03-24 8:45 ` cvs-commit at gcc dot gnu.org
2023-03-24 13:10 ` vmakarov at gcc dot gnu.org
` (9 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-03-24 8:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (18 preceding siblings ...)
2023-03-24 8:45 ` cvs-commit at gcc dot gnu.org
@ 2023-03-24 13:10 ` vmakarov at gcc dot gnu.org
2023-03-30 15:16 ` hubicka at gcc dot gnu.org
` (8 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2023-03-24 13:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (19 preceding siblings ...)
2023-03-24 13:10 ` vmakarov at gcc dot gnu.org
@ 2023-03-30 15:16 ` hubicka at gcc dot gnu.org
2023-03-30 15:32 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2023-03-30 15:16 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (20 preceding siblings ...)
2023-03-30 15:16 ` hubicka at gcc dot gnu.org
@ 2023-03-30 15:32 ` jakub at gcc dot gnu.org
2023-03-31 7:21 ` rguenther at suse dot de
` (6 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-30 15:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (21 preceding siblings ...)
2023-03-30 15:32 ` jakub at gcc dot gnu.org
@ 2023-03-31 7:21 ` rguenther at suse dot de
2023-04-05 1:06 ` sjames at gcc dot gnu.org
` (5 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2023-03-31 7:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (22 preceding siblings ...)
2023-03-31 7:21 ` rguenther at suse dot de
@ 2023-04-05 1:06 ` sjames at gcc dot gnu.org
2023-04-14 17:20 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: sjames at gcc dot gnu.org @ 2023-04-05 1:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (23 preceding siblings ...)
2023-04-05 1:06 ` sjames at gcc dot gnu.org
@ 2023-04-14 17:20 ` cvs-commit at gcc dot gnu.org
2023-04-14 17:23 ` hubicka at gcc dot gnu.org
` (3 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-04-14 17:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (24 preceding siblings ...)
2023-04-14 17:20 ` cvs-commit at gcc dot gnu.org
@ 2023-04-14 17:23 ` hubicka at gcc dot gnu.org
2023-04-17 10:56 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hubicka at gcc dot gnu.org @ 2023-04-14 17:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (25 preceding siblings ...)
2023-04-14 17:23 ` hubicka at gcc dot gnu.org
@ 2023-04-17 10:56 ` rguenth at gcc dot gnu.org
2023-05-08 12:26 ` rguenth at gcc dot gnu.org
2024-06-12 11:36 ` [Bug target/109137] " rguenth at gcc dot gnu.org
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-17 10:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [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
2023-03-15 0:30 [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
` (26 preceding siblings ...)
2023-04-17 10:56 ` rguenth at gcc dot gnu.org
@ 2023-05-08 12:26 ` rguenth at gcc dot gnu.org
2024-06-12 11:36 ` [Bug target/109137] " rguenth at gcc dot gnu.org
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-08 12:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 30+ messages in thread* [Bug target/109137] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
2023-03-15 0:30 [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
` (27 preceding siblings ...)
2023-05-08 12:26 ` rguenth at gcc dot gnu.org
@ 2024-06-12 11:36 ` rguenth at gcc dot gnu.org
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-06-12 11:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[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
Target Milestone|12.4 |---
^ permalink raw reply [flat|nested] 30+ messages in thread