[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #12 from Andrew Pinski --- *** Bug 109696 has been marked as a duplicate of this bug. ***
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Aldy Hernandez --- fixed
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:2b8a27634f5d28e3e7c4a08bf065f2daada7aed2 commit r14-458-g2b8a27634f5d28e3e7c4a08bf065f2daada7aed2 Author: Aldy Hernandez Date: Wed May 3 17:29:24 2023 +0200 Allow varying ranges of unknown types in irange::verify_range [PR109711] The old legacy code allowed building ranges of unknown types so passes like IPA could build and propagate VARYING. For now it's easiest to allow the old behavior, it's not like you can do anything with these ranges except build them and copy them. Eventually we should convert all users of set_varying() to use supported types. I will address this in my upcoming IPA work. PR tree-optimization/109711 gcc/ChangeLog: * value-range.cc (irange::verify_range): Allow types of error_mark_node.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Aldy Hernandez changed: What|Removed |Added Attachment #54980|0 |1 is obsolete|| --- Comment #9 from Aldy Hernandez --- Created attachment 54982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54982=edit patch in testing I think it's easiest to restore the legacy behavior for now. A proper conversion of IPA should follow.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 --- Comment #8 from Aldy Hernandez --- Created attachment 54980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54980=edit untested This may fix it.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #7 from Aldy Hernandez --- It looks like IPA is trying to set a range for a float even though value_range does not support floats. This worked before because legacy silently set a range of error_mark_node.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 --- Comment #6 from Tamar Christina --- my own bisect does indeed end up at r14-377-gc92b8be9b52b7e and cannot reproduce it on GCC 13.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |14.0
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #5 from Tamar Christina ---
(In reply to Martin Liška from comment #3)
> Hm, on x86_64-linux-gnu, it started with r13-6616-g2246d576f922ba.
$ cat prtest2.c
void lspf2lpc();
int interpolate_lpc_q_0;
void
interpolate_lpc(int subframe_num) {
float weight;
if (interpolate_lpc_q_0)
weight = subframe_num;
else
weight = 1.0;
if (weight != 1.0)
lspf2lpc();
}
void
qcelp_decode_frame() {
int i;
for (;; i++)
interpolate_lpc(i);
}
$ ./install/bin/gcc --version
gcc (GCC) 13.0.1 20230312 (experimental)
$ git log -1
commit 2246d576f922bae3629da0fe1dbfcc6ff06769ad (HEAD)
Author: Tamar Christina
Date: Sun Mar 12 18:39:33 2023 +
middle-end: Revert can_special_div_by_const changes [PR108583]
This reverts the changes for the CAN_SPECIAL_DIV_BY_CONST hook.
gcc/ChangeLog:
PR target/108583
* doc/tm.texi (TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST): Remove.
* doc/tm.texi.in: Likewise.
* explow.cc (round_push, align_dynamic_address): Revert previous
patch.
* expmed.cc (expand_divmod): Likewise.
* expmed.h (expand_divmod): Likewise.
* expr.cc (force_operand, expand_expr_divmod): Likewise.
* optabs.cc (expand_doubleword_mod, expand_doubleword_divmod):
Likewise.
* target.def (can_special_div_by_const): Remove.
* target.h: Remove tree-core.h include
* targhooks.cc (default_can_special_div_by_const): Remove.
* targhooks.h (default_can_special_div_by_const): Remove.
* tree-vect-generic.cc (expand_vector_operation): Remove hook.
* tree-vect-patterns.cc (vect_recog_divmod_pattern): Remove hook.
* tree-vect-stmts.cc (vectorizable_operation): Remove hook.
$ ./install/bin/gcc -O2 -S -o - prtest2.c
.file "prtest2.c"
.text
.p2align 4
.globl interpolate_lpc
.type interpolate_lpc, @function
interpolate_lpc:
.LFB0:
.cfi_startproc
movlinterpolate_lpc_q_0(%rip), %eax
testl %eax, %eax
je .L1
pxor%xmm0, %xmm0
cvtsi2ssl %edi, %xmm0
ucomiss .LC0(%rip), %xmm0
jp .L4
jne .L4
.L1:
ret
.p2align 4,,10
.p2align 3
...
Also that commit doesn't build because I forgot to cp tm.texi to the source
directory after the revert.
So I think the bisect probably didn't find it in that range.
https://godbolt.org/z/r44xGzarY indicates GCC 13.1 is fine. So I don't think
this one is mine.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711
--- Comment #4 from Sam James ---
Slightly smaller:
```
void lspf2lpc();
void interpolate_lpc(int subframe_num) {
float weight = 0.25 * subframe_num + 1;
if (weight)
lspf2lpc();
}
void qcelp_decode_frame() {
int i;
for (;; i++)
interpolate_lpc(i);
}
```
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Martin Liška changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #3 from Martin Liška --- Hm, on x86_64-linux-gnu, it started with r13-6616-g2246d576f922ba.
[Bug ipa/109711] [14 regression] ICE (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in verify_range, at value-range.cc:1060) when building ffmpeg-4.4.4 since r14-377-gc92b8be9b52b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109711 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Summary|[14 regression] ICE (tree |[14 regression] ICE (tree |check: expected class |check: expected class |‘type’, have ‘exceptional’ |‘type’, have ‘exceptional’ |(error_mark) in |(error_mark) in |verify_range, at|verify_range, at |value-range.cc:1060) when |value-range.cc:1060) when |building ffmpeg-4.4.4 |building ffmpeg-4.4.4 since ||r14-377-gc92b8be9b52b7e --- Comment #2 from Martin Liška --- Started with r14-377-gc92b8be9b52b7e and it's not related to aarch64, can reproduce on x86_64-linux-gnu as well.
