[Bug tree-optimization/112369] [14 regression] ICE when building webkit-gtk with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Richard Biener --- I will have a look.
[Bug tree-optimization/110223] Missed optimization vectorizing booleans comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110223 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=49 --- Comment #2 from Andrew Pinski --- I ran into boolean vectorizer issues too when making ^ be used instead of != for boolean types. I wonder how much is related to what is here.
[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Keywords|documentation |
CC||jakub at gcc dot gnu.org
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #15 from Richard Biener ---
I clarified the documentation. While in the particular case 'span.size ()'
doesn't have side-effects (well, I'm not 100% sure) in general function calls
are difficult to handle "delayed" while still allowing to discard side-effects.
Maybe the infrastructure we put in place for [[assume]] could help here by
treating __builtin_constant_p (expr) as
[["assume" (guard)]]
{
tem = expr;
guard = __builtin_constant_p (tem);
}
guard;
and lower it to
.ASSUME (&artificial_fn, args...);
but now with a return value that would become zero at the point we elide
.ASSUME unless we end up with a [1,1] range for the result?
That said, it's best to avoid relying on the side-effect removal, that is,
avoid having arguments with possible side-effects in __builtin_constant_p.
[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296 --- Comment #14 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:442715708911ed6cc6f3785e3996a62f5ee7f21f commit r14-5143-g442715708911ed6cc6f3785e3996a62f5ee7f21f Author: Richard Biener Date: Fri Nov 3 08:11:05 2023 +0100 middle-end/112296 - __builtin_constant_p and side-effects The following tries to clarify the __builtin_constant_p documentation, stating that the argument expression is not evaluated and side-effects are discarded. I'm struggling to find the correct terms matching what the C language standard would call things so I'd appreciate some help here. OK for trunk? Shall we diagnose arguments with side-effects? It seems to me such use is usually unintended? I think rather than dropping side-effects as a side-effect of folding the frontend should discard them at parsing time instead, no? Thanks, Richard. PR middle-end/112296 * doc/extend.texi (__builtin_constant_p): Clarify that side-effects are discarded.
[Bug target/112387] RISC-V: failed to SLP INT64 gather load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112387 --- Comment #1 from JuzheZhong --- Oh. I see. with -fno-vect-cost-model, it can SLP now: https://godbolt.org/z/q5se4sd9x foo: beq a3,zero,.L8 csrra6,vlenb srlia4,a6,3 sllia3,a3,1 neg t1,a4 vsetvli a5,zero,e64,m1,ta,ma vmv.v.i v2,1 vid.v v0 vand.vi v0,v0,1 vmseq.viv0,v0,1 vmerge.vim v2,v2,2,v0 .L3: minua5,a3,a4 vsetvli zero,a5,e64,m1,ta,ma mv a7,a3 vle64.v v1,0(a2) vsll.vi v1,v1,3 vluxei64.v v1,(a1),v1 vadd.vv v1,v1,v2 vse64.v v1,0(a0) add a2,a2,a6 add a0,a0,a6 add a3,a3,t1 bgtua7,a4,.L3 .L8: ret It's odd I think SLP should always preferrable choice.
[Bug middle-end/112403] New: `s+ (a?-1:1)` and `a?s-1:s+1` produce two different code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112403
Bug ID: 112403
Summary: `s+ (a?-1:1)` and `a?s-1:s+1` produce two different
code generation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 94274
Target Milestone: ---
Target: aarch64
Take:
```
int
foo(int t1, int s)
{
int t;
if (t1 >= 0)
t=1;
else
t=-1;
s+=t;
return s;
}
int
foo1(int t1, int s)
{
if (t1 >= 0)
s++;
else
s--;
return s;
}
```
This current produces:
```
foo:
cmp w0, 0
mov w2, 1
csneg w2, w2, w2, ge
add w0, w2, w1
ret
foo1:
cmp w0, 0
sub w0, w1, #1
csinc w0, w0, w1, lt
ret
```
But we should be able to even just produce:
```
asr w8, w0, #31 // a >= 0 ? -1 : 0
orr w8, w8, #0x1 // |1 (or a >= ? -1 : 1)
add w0, w8, w1 // s+=that
```
Note on x86, the foo is optimal even:
```
sarl$31, %edi
orl $1, %edi
leal(%rdi,%rsi), %eax
```
I should note this blocks PR 94274 work.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
[Bug 94274] fold phi whose incoming args are defined from binary operations
[Bug tree-optimization/112402] [11/12/13/14 Regression] Path splitting causes if-conversion miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112402 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5
[Bug tree-optimization/112402] New: [11/12/13/14 Regression] Path splitting causes if-conversion miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112402
Bug ID: 112402
Summary: [11/12/13/14 Regression] Path splitting causes
if-conversion miss
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 94274
Target Milestone: ---
Similar to PR 68541 except instead of having a diamond, we just have a
triangle.
Testcase:
```
int
foo(signed char *p, int n)
{
int s = 0;
int i;
for (i = 0; i < n; i++) {
int t;
if (p[i] >= 0)
t=1;
else
t=-1;
s+=t;
}
return s;
}
```
I noticed this while working on fixing PR 94274.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
[Bug 94274] fold phi whose incoming args are defined from binary operations
[Bug target/111889] [14 Regression] 128/256 intrins could not be used with only specifying "no-evex512, avx512vl" in function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889 Haochen Jiang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Haochen Jiang --- Should be fixed after patches
[Bug target/111828] rs6000: Parse inline asm string to figure out it requires HTM feature or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828 --- Comment #10 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:b2075291af8810794c7184fd125b991c2341cb1e commit r14-5142-gb2075291af8810794c7184fd125b991c2341cb1e Author: Kewen Lin Date: Mon Nov 6 00:14:43 2023 -0600 rs6000: Consider inline asm as safe if no assembler complains [PR111828] As discussed in PR111828, rs6000_update_ipa_fn_target_info is much conservative, currently for any non-empty inline asm, without any parsing, it would take inline asm could have HTM insns. It means for one function attributed with power8 having inline asm, even if it has no HTM insns, we don't make a function attributed with power10 inline it. Peter pointed out an inline asm parser can be a slippery slope, and noticed that the current gnu assembler still allows HTM insns even with power10 machine type, so he suggested that we can aggressively ignore the handling on inline asm, this patch goes for this suggestion. Considering that there are a few assembler alternatives and assembler can update its behaviors (complaining HTM insns at power10 and later cpus sounds reasonable from a certain point of view), this patch also checks assembler complains on HTM insns at power10 or not. For a case that a caller attributed power10 calls a callee attributed power8 having inline asm with HTM insn, without inlining at least the compilation succeeds, but if assembler complains HTM insns at power10, after inlining the compilation would fail. The two associated test cases are fine without and with this patch (effective target takes effect or not). PR target/111828 gcc/ChangeLog: * config.in: Regenerate. * config/rs6000/rs6000.cc (rs6000_update_ipa_fn_target_info): Guard inline asm handling under !HAVE_AS_POWER10_HTM. * configure: Regenerate. * configure.ac: Detect assembler support for HTM insns at power10. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_powerpc_as_p10_htm): New proc. * g++.target/powerpc/pr111828-1.C: New test. * g++.target/powerpc/pr111828-2.C: New test.
[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subword data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Component|target |rtl-optimization Ever confirmed|1 |0 --- Comment #4 from Andrew Pinski --- Expand does: ;; _1 = *src_5(D); (insn 7 6 0 (set (reg:SI 134 [ _1 ]) (zero_extend:SI (mem:QI (reg/v/f:SI 138 [ srcD.2336 ]) [0 MEM[(const uint8_tD.2311 *)src_5(D) clique 1 base 1]+0 S1 A8]))) "/app/example.cpp":5:21 -1 (nil)) ;; work_6 = ~_1; (insn 8 7 9 (set (reg:SI 139) (not:SI (reg:SI 134 [ _1 ]))) "/app/example.cpp":5:13 -1 (nil)) (insn 9 8 0 (set (reg/v:SI 136 [ workD.2339 ]) (zero_extend:SI (subreg:QI (reg:SI 139) 0))) "/app/example.cpp":5:13 -1 (nil)) The bigger issue we don't take into track of nonzerobits as much as we could. Though the other issue when combine does the combining here: Trying 7, 8 -> 9: 7: r134:SI=zero_extend([r148:SI]) REG_DEAD r148:SI 8: r139:SI=~r134:SI REG_DEAD r134:SI 9: r136:SI=zero_extend(r139:SI#0) REG_DEAD r139:SI Failed to match this instruction: (set (reg/v:SI 136 [ workD.2339 ]) (zero_extend:SI (subreg:QI (not:SI (subreg:SI (mem:QI (reg:SI 148) [0 MEM[(const uint8_tD.2311 *)src_5(D) clique 1 base 1]+0 S1 A8]) 0)) 0))) that could be just (xor (zero_extend:SI (mem:QI (reg:SI 148) [0 MEM[(const uint8_tD.2311 *)src_5(D) clique 1 base 1]+0 S1 A8]) 0))) 255) But I am not so sure combine knows how to simplify that ...
[Bug target/112398] Suboptimal code generation for xor pattern on subword data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398
--- Comment #3 from Siarhei Volkau ---
Well, let's rewrite it in that way:
void neg8 (uint8_t *restrict dst, const uint8_t *restrict src)
{
uint8_t work = ~*src; // or *src ^ 0xff;
dst[0] = (work >> 4) | (work << 4);
}
Wherever upper bits have to be in zero state it is cheaper to use xor,
otherwise we're relying on techniques for eliminating redundant zero_extend and
at least on MIPS (prior to R2) and RISC-V GCC emits the zero_extend
instruction.
MIPS, neg8:
neg8:
lbu $2,0($5)
nop
nor $2,$0,$2
andi$3,$2,0x00ff
srl $3,$3,4
sll $2,$2,4
or $2,$2,$3
jr $31
sb $2,0($4)
RISC-V, neg8:
lbu a5,0(a1)
not a5,a5
andia4,a5,0xff
srlia4,a4,4
sllia5,a5,4
or a4,a4,a5
sb a4,0(a0)
ret
Some other RISCs also emit zero_extend but I'm not sure about having cheaper
xor alternative on them (S390, SH, Xtensa).
[Bug c/112401] RISC-V: So many redundant move instructions due to subreg handling on vector mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112401 --- Comment #1 from JuzheZhong --- GCC ASM: subreg_to_reg_1: li a5,32 vsetvli zero,a5,e32,m8,ta,ma vle32.v v16,0(a0) vmv1r.v v8,v16 vmv1r.v v7,v17 vmv1r.v v6,v18 vmv1r.v v5,v19 vmv1r.v v4,v20 vmv1r.v v3,v21 vmv1r.v v2,v22 vmv1r.v v1,v23 beq a2,zero,.L2 li a5,0 vsetivlizero,4,e32,m1,ta,ma .L3: addia5,a5,1 vadd.vv v8,v8,v8 vadd.vv v7,v7,v7 vadd.vv v6,v6,v6 vadd.vv v5,v5,v5 vadd.vv v4,v4,v4 vadd.vv v3,v3,v3 vadd.vv v2,v2,v2 vadd.vv v1,v1,v1 bne a2,a5,.L3 .L2: vs1r.v v8,0(a1) addia5,a1,16 vs1r.v v7,0(a5) addia5,a1,32 vs1r.v v6,0(a5) addia5,a1,48 vs1r.v v5,0(a5) addia5,a1,64 vs1r.v v4,0(a5) addia5,a1,80 vs1r.v v3,0(a5) addia5,a1,96 vs1r.v v2,0(a5) addia1,a1,112 vs1r.v v1,0(a1) ret LLVM ASM: subreg_to_reg_1:# @subreg_to_reg_1 li a3, 32 vsetvli zero, a3, e32, m8, ta, ma vle32.v v8, (a0) addia0, a1, 16 beqza2, .LBB0_2 .LBB0_1:# =>This Inner Loop Header: Depth=1 vsetivlizero, 4, e32, m1, ta, ma vadd.vv v8, v8, v8 vadd.vv v9, v9, v9 vadd.vv v10, v10, v10 vadd.vv v11, v11, v11 vadd.vv v12, v12, v12 vadd.vv v13, v13, v13 vadd.vv v14, v14, v14 addia2, a2, -1 vadd.vv v15, v15, v15 bneza2, .LBB0_1 .LBB0_2: vs1r.v v8, (a1) vs1r.v v9, (a0) addia1, a0, 16 vs1r.v v10, (a1) addia1, a0, 32 vs1r.v v11, (a1) addia1, a0, 48 vs1r.v v12, (a1) addia1, a0, 64 vs1r.v v13, (a1) addia1, a0, 80 vs1r.v v14, (a1) addia0, a0, 96 vs1r.v v15, (a0) ret
[Bug c/112401] New: RISC-V: So many redundant move instructions due to subreg handling on vector mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112401
Bug ID: 112401
Summary: RISC-V: So many redundant move instructions due to
subreg handling on vector mode
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
Consider this following case:
https://godbolt.org/z/8nc6r4joc
Compare with LLVM, we have so many redundant move instruction "vmv1r"
#include
void
subreg_to_reg_1 (int32_t *in, int32_t *out, size_t m)
{
vint32m8_t result = __riscv_vle32_v_i32m8 (in, 32);
vint32m1_t v0 = __riscv_vget_v_i32m8_i32m1 (result, 0);
vint32m1_t v1 = __riscv_vget_v_i32m8_i32m1 (result, 1);
vint32m1_t v2 = __riscv_vget_v_i32m8_i32m1 (result, 2);
vint32m1_t v3 = __riscv_vget_v_i32m8_i32m1 (result, 3);
vint32m1_t v4 = __riscv_vget_v_i32m8_i32m1 (result, 4);
vint32m1_t v5 = __riscv_vget_v_i32m8_i32m1 (result, 5);
vint32m1_t v6 = __riscv_vget_v_i32m8_i32m1 (result, 6);
vint32m1_t v7 = __riscv_vget_v_i32m8_i32m1 (result, 7);
for (size_t i = 0; i < m; i++)
{
v0 = __riscv_vadd_vv_i32m1(v0, v0, 4);
v1 = __riscv_vadd_vv_i32m1(v1, v1, 4);
v2 = __riscv_vadd_vv_i32m1(v2, v2, 4);
v3 = __riscv_vadd_vv_i32m1(v3, v3, 4);
v4 = __riscv_vadd_vv_i32m1(v4, v4, 4);
v5 = __riscv_vadd_vv_i32m1(v5, v5, 4);
v6 = __riscv_vadd_vv_i32m1(v6, v6, 4);
v7 = __riscv_vadd_vv_i32m1(v7, v7, 4);
}
*(vint32m1_t*)(out+4*0) = v0;
*(vint32m1_t*)(out+4*1) = v1;
*(vint32m1_t*)(out+4*2) = v2;
*(vint32m1_t*)(out+4*3) = v3;
*(vint32m1_t*)(out+4*4) = v4;
*(vint32m1_t*)(out+4*5) = v5;
*(vint32m1_t*)(out+4*6) = v6;
*(vint32m1_t*)(out+4*7) = v7;
}
Such issue not only happens on RISC-V but also in all other targets.
Lehua will send a patch to support subreg liveness tracking on GCC soon.
[Bug target/112400] VAX: ICE in fixup_reorder_chain, at cfgrtl.cc:4025, whilst building gimple_match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112400 --- Comment #3 from Andrew Pinski --- Looks like it was introduced with r0-63993-g05dde071b32f .
[Bug target/112400] VAX: ICE in fixup_reorder_chain, at cfgrtl.cc:4025, whilst building gimple_match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112400 --- Comment #2 from Andrew Pinski --- Patches should be posted to gcc-patches@ after reading https://gcc.gnu.org/contribute.html .
[Bug target/112400] VAX: ICE in fixup_reorder_chain, at cfgrtl.cc:4025, whilst building gimple_match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112400 --- Comment #1 from Kalvis Duckmanton --- Created attachment 56512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56512&action=edit patch proposed as solution
[Bug target/112400] New: VAX: ICE in fixup_reorder_chain, at cfgrtl.cc:4025, whilst building gimple_match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112400
Bug ID: 112400
Summary: VAX: ICE in fixup_reorder_chain, at cfgrtl.cc:4025,
whilst building gimple_match.cc
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kalvisd at gmail dot com
Target Milestone: ---
Created attachment 56511
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56511&action=edit
Reduced test case
GCC was built as below, on amd64 targeting vax:
$ /mnt/gcc/x86_64/bin/vax--netbsdelf-g++ -v
Using built-in specs.
COLLECT_GCC=/mnt/gcc/x86_64/bin/vax--netbsdelf-g++
COLLECT_LTO_WRAPPER=/mnt/gcc/x86_64/bin/../libexec/gcc/vax--netbsdelf/12.2.0/lto-wrapper
Target: vax--netbsdelf
Configured with: ../gcc-12.2.0/configure --prefix=/mnt/gcc/12/../x86_64
--target=vax--netbsdelf --enable-long-long --enable-threads --with-system-zlib
--without-isl --enable-__cxa_atexit --enable-libstdcxx-time=rt
--enable-libstdcxx-threads --with-diagnostics-color=auto-if-env
--with-default-libstdcxx-abi=new
--with-sysroot=/srv/nfs/netbsd-git/build/obj.vax/srv/nfs/netbsd-git/src/destdir.vax
--disable-nls --disable-multilib
--program-transform-name=''\''s,^,vax--netbsdelf-,'\'''
--with-mpc=/mnt/gcc/12/../x86_64 --with-mpfr=/mnt/gcc/12/../x86_64
--with-gmp=/mnt/gcc/12/../x86_64 --with-isl=/mnt/gcc/12/../x86_64
--srcdir=/mnt/gcc/12/gcc-12.2.0-x86_64-vax--netbsdelf/../gcc-12.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)
Output from GCC when it generated the ICE:
/mnt/gcc/x86_64/bin/vax--netbsdelf-g++ -O2 -fpic -fPIC -o gimple-match.s -S
gimple-match.i
gimple-match.i: In function 'bool ah(x*, b*, a (*)(a), a, a*, k)':
gimple-match.i:22:44: warning: no return statement in function returning
non-void [-Wreturn-type]
22 | static bool ah(x *, b *, a(a), a, a *, k) {}
|^
gimple-match.i: In function 'bool ai(x*, a (*)(a))':
gimple-match.i:92:1: warning: control reaches end of non-void function
[-Wreturn-type]
92 | }
| ^
during RTL pass: bbro
gimple-match.i:92:1: internal compiler error: in fixup_reorder_chain, at
cfgrtl.cc:4025
0x5bc784 fixup_reorder_chain
/mnt/gcc/12/gcc-12.2.0-x86_64-vax--netbsdelf/../gcc-12.2.0/gcc/cfgrtl.cc:4025
0x5bc784 cfg_layout_finalize()
/mnt/gcc/12/gcc-12.2.0-x86_64-vax--netbsdelf/../gcc-12.2.0/gcc/cfgrtl.cc:4538
0x1276008 execute
/mnt/gcc/12/gcc-12.2.0-x86_64-vax--netbsdelf/../gcc-12.2.0/gcc/bb-reorder.cc:2663
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907 --- Comment #5 from Haochen Jiang --- BTW, it should be disabled since it will use zmm previously. foo(_Float128, _Float128): pushrbp mov rbp, rsp vmovdqa XMMWORD PTR [rbp-16], xmm0 vmovdqa XMMWORD PTR [rbp-32], xmm1 vmovdqa xmm1, XMMWORD PTR [rbp-16] vmovdqa xmm2, XMMWORD PTR [rbp-32] vmovdqa xmm0, XMMWORD PTR .LC0[rip] vpandnq zmm1, zmm0, zmm1 vpand xmm0, xmm0, xmm2 vporxmm0, xmm1, xmm0 pop rbp ret A straightforward solution might be trying to use its xmm version here.
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907 --- Comment #4 from Haochen Jiang --- I guess it is caused by "*andnot3", not confirmed yet. The isa for the last constraint changed to avx512f_512, which will make the pattern disabled under -mavx512f -mno-evex512. Let me find a solution on that.
[Bug tree-optimization/110755] [13 Regression] Wrong optimization of fabs on ppc64el at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755 Hans-Peter Nilsson changed: What|Removed |Added Target|powerpc64le |powerpc64le, aarch64 CC||hp at gcc dot gnu.org --- Comment #16 from Hans-Peter Nilsson --- As alluded already in comment #3, this bug is generic: I built gcc-13.2 and verified that it also exists (or perhaps more correctly put, existed) for aarch64, for that version.
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 --- Comment #3 from Hongtao.liu --- Yes, should return true if d->testing_p instead of generate rtl code.
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63734 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734#c1
[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63734 --- Comment #7 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734#c1
[Bug libbacktrace/112396] "make check" should not error out, even when some checks failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #3 from Ian Lance Taylor --- libbacktrace is just using automake and its testsuite support. Anybody know if there is a way to tell automake not to exit 1 on test failure?
[Bug c/112399] New: RISC-V: Missed AVL propagation for complicate reduction case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399
Bug ID: 112399
Summary: RISC-V: Missed AVL propagation for complicate
reduction case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
double foo (double *__restrict a,
double *__restrict b,
double *__restrict c,
int n)
{
double result = 0;
for (int i = 0; i < n; i++)
result += a[i] * b[i] * c[i];
return result;
}
https://godbolt.org/z/znqcf7ehz
vsetvli a5,a3,e8,mf8,ta,ma -> should be change into e64m1 Tuma
sllia4,a5,3
vle64.v v4,0(a0)
vle64.v v1,0(a1)
vle64.v v3,0(a2)
sub a3,a3,a5
vsetvli a6,zero,e64,m1,ta,ma ---> redundant
add a0,a0,a4
vfmul.vvv1,v1,v4
add a1,a1,a4
vsetvli zero,a5,e64,m1,tu,ma ---> redundant
add a2,a2,a4
vfmacc.vv v2,v3,v1
bne a3,zero,.L3
fmv.d.x fa5,zero
vsetvli a6,zero,e64,m1,ta,ma
vfmv.s.fv1,fa5
vfredusum.vsv2,v2,v1
vfmv.f.sfa0,v2
ret
[Bug target/111889] [14 Regression] 128/256 intrins could not be used with only specifying "no-evex512, avx512vl" in function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111889 --- Comment #6 from CVS Commits --- The master branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:fd5147177b9fa04943a3a55512b81f8f46ab4ac5 commit r14-5140-gfd5147177b9fa04943a3a55512b81f8f46ab4ac5 Author: Haochen Jiang Date: Mon Nov 6 09:38:31 2023 +0800 Push no-evex512 target for 128/256 bit intrins gcc/ChangeLog: PR target/111889 * config/i386/avx512bf16intrin.h: Push no-evex512 target. * config/i386/avx512bf16vlintrin.h: Ditto. * config/i386/avx512bitalgvlintrin.h: Ditto. * config/i386/avx512bwintrin.h: Ditto. * config/i386/avx512dqintrin.h: Ditto. * config/i386/avx512fintrin.h: Ditto. * config/i386/avx512fp16intrin.h: Ditto. * config/i386/avx512fp16vlintrin.h: Ditto. * config/i386/avx512ifmavlintrin.h: Ditto. * config/i386/avx512vbmi2vlintrin.h: Ditto. * config/i386/avx512vbmivlintrin.h: Ditto. * config/i386/avx512vlbwintrin.h: Ditto. * config/i386/avx512vldqintrin.h: Ditto. * config/i386/avx512vlintrin.h: Ditto. * config/i386/avx512vnnivlintrin.h: Ditto. * config/i386/avx512vp2intersectvlintrin.h: Ditto. * config/i386/avx512vpopcntdqvlintrin.h: Ditto. gcc/testsuite/ChangeLog: PR target/111889 * gcc.target/i386/pr111889.c: New test.
[Bug debug/109676] [13/14 regression] ICE in simplify_subreg, at simplify-rtx.cc:7426 when building firefox with -O2 -march=alderlake -g since r13-3378-gf6c168f8c06047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109676 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|13.3|13.2 Resolution|--- |FIXED --- Comment #17 from Andrew Pinski --- Fixed.
[Bug libbacktrace/112396] "make check" should not error out, even when some checks failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Andrew Pinski from comment #1) > https://gcc.gnu.org/install/test.html > > Even mentions -k option for a long time. Still, it's kind of inconvenient having to do it that way, though. I think this is an aspect of the testsuite worth changing.
[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112393 --- Comment #6 from Andrew Pinski --- Similar to PR 112393 but this is a s390 issue where TARGET_VECTORIZE_VEC_PERM_CONST should NOT be causing RTL to be generated.
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #1 from Andrew Pinski --- ix86_expand_vec_perm_const_1 should not cause RTL to be generated ...
[Bug tree-optimization/111792] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-3414-g0cfc9c953d0221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111792 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- I can no longer reproduce this on the trunk.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754 --- Comment #10 from Richard Sandiford --- Yeah, the problem went latent after the fix for PR111648, but the underlying problem is still there. Prathamesh is working on a fix for that. See the thread starting at https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633784.html for discussion.
[Bug target/112398] Suboptimal code generation for xor pattern on subword data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-11-05 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Also it depends on the ABI since the return value on many targets' ABI don't care about the upper bits. For an example on aarch64 we get: neg8: ldrbw0, [x0] mvn w0, w0 ret neg16: ldrhw0, [x0] mvn w0, w0 ret
[Bug target/112398] Suboptimal code generation for xor pattern on subword data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 Andrew Pinski changed: What|Removed |Added Component|middle-end |target --- Comment #1 from Andrew Pinski --- Which target is this for? Because not is normally cheaper than xor in many sense.
[Bug tree-optimization/105834] [13/14 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105834 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109695 Keywords|needs-bisection | --- Comment #6 from Thomas Koenig --- On trunk, this was fixed by r14-1163-gd8b058d3ca4ebb, one of the patchset which fixed PR 109695: d8b058d3ca4ebbef5575105164417f125696f5ce is the first new commit commit d8b058d3ca4ebbef5575105164417f125696f5ce Author: Andrew MacLeod Date: Tue May 23 15:11:44 2023 -0400 Choose better initial values for ranger. Instead of defaulting to VARYING, fold the stmt using just global ranges. PR tree-optimization/109695 * gimple-range-cache.cc (ranger_cache::get_global_range): Call fold_range with global query to choose an initial value. gcc/gimple-range-cache.cc | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) Would this patch be something that could reasonably be backported?
[Bug middle-end/112398] New: Suboptimal code generation for xor pattern on subword data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398
Bug ID: 112398
Summary: Suboptimal code generation for xor pattern on subword
data
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: lis8215 at gmail dot com
Target Milestone: ---
These minimal examples showcase the issue:
uint8_t neg8 (const uint8_t *src)
{
return ~*src;
// or return *src ^ 0xff;
}
uint16_t neg16 (const uint16_t *src)
{
return ~*src;
// or return *src ^ 0x;
}
GCC transforms xor here to not + zero_extend, which isn't the best choice.
I guess combiner have to try xor pattern instead of not + zero_extend as it
might be cheaper.
[Bug middle-end/111754] [14 Regression] ICE: in decompose, at rtl.h:2313 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754 --- Comment #9 from Andrew Pinski --- The ICE seems to be gone, and the generated code looks correct.
[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r14-301-gf2d6beb7a4ddf1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689 Andrew Pinski changed: What|Removed |Added CC||shaohua.li at inf dot ethz.ch --- Comment #11 from Andrew Pinski --- *** Bug 111389 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/111389] [14 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111389 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 109689. *** This bug has been marked as a duplicate of bug 109689 ***
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Andrew Pinski --- 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 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 tree-optimization/109696] [14 Regression] ice: tree check fail since r14-377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109696 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 109711. *** This bug has been marked as a duplicate of bug 109711 ***
[Bug tree-optimization/109696] [14 Regression] ice: tree check fail since r14-377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109696 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- Looks like this one has been fixed. Would be a good idea to see what commit fixed it.
[Bug tree-optimization/111572] [14 Regression] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #5 from Andrew Pinski --- Hmm, this works on the trunk now. Would be a good idea to figure out what "fixed" it.
[Bug libstdc++/112397] New: Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Bug ID: 112397 Summary: Two persistent libstdc++ test failures on x86_64-apple-darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- FAIL: 17_intro/static.cc -std=gnu++17 (test for excess errors) FAIL: 20_util/to_chars/4.cc -std=gnu++17 (test for excess errors) The both have the same linker warning: ld: warning: direct access in function 'operator new[](unsigned long, std::nothrow_t const&) (.cold)' from file '/Users/fx/ibin-2023 1105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator new[](unsigned long, s td::nothrow_t const&)' from file '/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' m eans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with diff erent visibility settings. ld: warning: direct access in function 'operator new[](unsigned long, std::nothrow_t const&) (.cold)' from file '/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator new[](unsigned long, std::nothrow_t const&)' from file '/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs/libstdc++.a(new_opvnt.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. I am not sure what the "different visibility settings" are, or if it's just a red herring, but the testcase is compiled with: Executing on host: /Users/fx/ibin-20231105/./gcc/xg++ -shared-libgcc -B/Users/fx/ibin-20231105/./gcc -nostdinc++ -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src/.libs -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/libsupc++/.libs -B/Users/fx/irun-20231105/x86_64-apple-darwin21/bin/ -B/Users/fx/irun-20231105/x86_64-apple-darwin21/lib/ -isystem /Users/fx/irun-20231105/x86_64-apple-darwin21/include -isystem /Users/fx/irun-20231105/x86_64-apple-darwin21/sys-include -fchecking=1 -B/Users/fx/ibin-20231105/x86_64-apple-darwin21/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/include/x86_64-apple-darwin21 -I/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/include -I/Users/fx/gcc-upstream/libstdc++-v3/libsupc++ -I/Users/fx/gcc-upstream/libstdc++-v3/include/backward -I/Users/fx/gcc-upstream/libstdc++-v3/testsuite/util /Users/fx/gcc-upstream/libstdc++-v3/testsuite/17_intro/static.cc -std=gnu++17 -static-libstdc++ -fdiagnostics-plain-output ./libtestc++.a -liconv -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src/filesystem/.libs -L/Users/fx/ibin-20231105/x86_64-apple-darwin21/libstdc++-v3/src/experimental/.libs -lm -o ./static.exe(timeout = 360)
[Bug libbacktrace/112396] "make check" should not error out, even when some checks failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/install/test.html Even mentions -k option for a long time.
[Bug libbacktrace/112396] New: "make check" should not error out, even when some checks failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112396 Bug ID: 112396 Summary: "make check" should not error out, even when some checks failed Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- The behaviour in GCC is pretty consistent: parts of the testsuite do not error out in make, even when individual tests fail. The one exception is libbacktrace, which does error out when one or more test failed: make[4]: *** [test-suite.log] Error 1 make[3]: *** [check-TESTS] Error 2 make[2]: *** [check-am] Error 2 make[2]: Target `check' not remade because of errors. make[1]: *** [check-target-libbacktrace] Error 2 This means that if, like me, you forgot to run "make check" with -k, you get stopped in the middle of testing. To be nice to users, and for consistency, it would be nice if this behaviour was changed.
[Bug tree-optimization/112395] `CST1| (x & CST0)` -> `0x1e | x` iff `x&CST0` known zero bits outside of CST1 is known to be 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112395 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-11-05 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine.
[Bug tree-optimization/112395] New: `CST1| (x & CST0)` -> `0x1e | x` iff `x&CST0` known zero bits outside of CST1 is known to be 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112395
Bug ID: 112395
Summary: `CST1| (x & CST0)` -> `0x1e | x` iff `x&CST0` known
zero bits outside of CST1 is known to be 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
As reported at :
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635206.html
An exmaple is:
```
unsigned f(unsigned x){
if(x>=32)__builtin_unreachable();
return 30|(x&1); // --> 30|x
}
```
30 is 0x1e and x has a range of [0, 31] (which has a nonzero bits of 0x1f).
The &1 part can be removed from 30|(x&1) as 30 will set every bit except for
the first bit.
I think the following will work.
```
(simplify
(bit_ior (bit_and:s @0 INTEGER_CST@1) INTEGER_CST@2)
(if (wi::bit_and_not (wi::bit_and_not (tree_nonzero_bits (@0), wi::to_wide
(@1)), wi::to_wide (@0)) == 0)
(bit_ior @0 @2))
```
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com Status|NEW |ASSIGNED --- Comment #10 from Roger Sayle --- combine.cc's expand_field_assignment needs to defend against gen_lowpart (which is gen_lowpart_for_combine) returning a CLOBBER. Otherwise, we end up calling simplify_set on: (set (reg:DI 134) (and:DI (subreg:DI (ior:SI (ior:SI (and:SI (subreg:SI (reg/v:TI 114 [ sampler ]) 0) (const_int -129280 [0xfffe0700])) (and:SI (clobber:TI (const_int 0 [0])) (const_int -129025 [0xfffe07ff]))) (and:SI (reg:SI 130) (const_int 129024 [0x1f800]))) 0) (const_int 4294967295 [0x]))) where if you look closely the "(clobber:TI (const_int 0))" causes no end of fun in simplify_rtx; it's not surprising that an assert is eventually triggered in simplify_subreg. I'm testing a patch.
[Bug target/112394] New: ICE: in extract_constrain_insn, at recog.cc:2705 insn does not satisfy its constraints: {*vec_extractv2di_1} with -O -mavx512vbmi2 -mapxf -mno-sse4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112394
Bug ID: 112394
Summary: ICE: in extract_constrain_insn, at recog.cc:2705 insn
does not satisfy its constraints: {*vec_extractv2di_1}
with -O -mavx512vbmi2 -mapxf -mno-sse4.2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 56510
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56510&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512vbmi2 -mapxf -mno-sse4.2 testcase.c
testcase.c: In function 'foo':
testcase.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 759 758 679 2 (set (reg:DI 77 r17 [ _27+8 ])
(vec_select:DI (reg:V2DI 24 xmm4)
(parallel [
(const_int 1 [0x1])
]))) "testcase.c":16:6 7407 {*vec_extractv2di_1}
(nil))
during RTL pass: pro_and_epilogue
testcase.c:20:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2705
0x7ee999 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7eea20 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7df135 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2705
0x1424c75 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:836
0x1425e41 copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
/repo/gcc-trunk/gcc/regcprop.cc:1235
0x1490b11 prepare_shrink_wrap
/repo/gcc-trunk/gcc/shrink-wrap.cc:451
0x1490b11 try_shrink_wrapping(edge_def**, rtx_insn*)
/repo/gcc-trunk/gcc/shrink-wrap.cc:674
0x110442b thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6046
0x1104d82 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6543
0x1104d82 execute
/repo/gcc-trunk/gcc/function.cc:6624
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.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5128-20231105174125-g9acea4376fd-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5128-20231105174125-g9acea4376fd-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231105 (experimental) (GCC)
[Bug tree-optimization/112393] New: [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 Bug ID: 112393 Summary: [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56509&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -mavx5124fmaps -Wuninitialized testcase.c during GIMPLE pass: early_uninit testcase.c: In function 'foo': testcase.c:17:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1208 17 | } | ^ 0x7408fb gen_reg_rtx(machine_mode) /repo/gcc-trunk/gcc/emit-rtl.cc:1208 0x1067067 force_reg(machine_mode, rtx_def*) /repo/gcc-trunk/gcc/explow.cc:692 0x198d7f7 ix86_expand_vec_perm_vpermt2 /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:5261 0x199c9e7 expand_vec_perm_1 /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:20302 0x199ca11 expand_vec_perm_1 /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:20307 0x199ee18 ix86_expand_vec_perm_const_1 /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:22964 0x19c95d9 ix86_vectorize_vec_perm_const(machine_mode, machine_mode, rtx_def*, rtx_def*, rtx_def*, vec_perm_indices const&) /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:23295 0x1a68ea4 gimple_simplify_VEC_PERM_EXPR(gimple_match_op*, gimple**, tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*) /repo/build-gcc-trunk-amd64/gcc/gimple-match-8.cc:17848 0x1b4b543 gimple_resimplify3 /repo/gcc-trunk/gcc/gimple-match-exports.cc:1077 0x1b4c6a2 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) /repo/gcc-trunk/gcc/gimple-match-exports.cc:868 0x11322c1 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) /repo/gcc-trunk/gcc/gimple-fold.cc:7543 0x16e84ac try_to_simplify /repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:6136 0x16e84ac visit_stmt /repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:6179 0x16e90a5 process_bb /repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8010 0x16eabcc do_rpo_vn_1 /repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8609 0x16ec4da do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool, vn_lookup_kind) /repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8711 0x173f7af execute_early_warn_uninitialized /repo/gcc-trunk/gcc/tree-ssa-uninit.cc:1478 0x173f7af execute /repo/gcc-trunk/gcc/tree-ssa-uninit.cc:1517 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5128-20231105174125-g9acea4376fd-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5128-20231105174125-g9acea4376fd-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231105 (experimental) (GCC)
[Bug target/112105] [14 Regression] vector by lane operation costing broken since g:21416caf221fae4351319ef8ca8d41c0234bdfa7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Sandiford --- Fixed. Thanks for the catch.
[Bug target/112105] [14 Regression] vector by lane operation costing broken since g:21416caf221fae4351319ef8ca8d41c0234bdfa7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112105 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:0e6f3e9175bddb5cada6571744f33af574232c76 commit r14-5129-g0e6f3e9175bddb5cada6571744f33af574232c76 Author: Richard Sandiford Date: Sun Nov 5 12:08:02 2023 + aarch64: Rework aarch64_modes_tieable_p [PR112105] On AArch64, can_change_mode_class and modes_tieable_p are mostly answering the same questions: (a) Do two modes have the same layout for the bytes that are common to both modes? (b) Do all valid subregs involving the two modes behave as GCC would expect? (c) Is there at least one register that can hold both modes? These questions involve no class-dependent tests, and the relationship is symmetrical. This means we can do most of the checks in a common subroutine. can_change_mode_class is the hook that matters for correctness, while modes_tieable_p is more for optimisation. It was therefore can_change_mode_class that had the more accurate tests. modes_tieable_p was looser in some ways (e.g. it missed some big-endian tests) and overly strict in others (it didn't allow ties between a vector structure mode and the mode of a single lane). The overly strict part caused a missed combination in the testcase. I think the can_change_mode_class logic also needed some tweaks, as described in the changelog. gcc/ PR target/112105 * config/aarch64/aarch64.cc (aarch64_modes_compatible_p): New function, with the core logic extracted from... (aarch64_can_change_mode_class): ...here. Extend the previous rules to allow changes between partial SVE modes and other modes if the other mode is no bigger than an element, and if no other rule prevents it. Use the aarch64_modes_tieable_p handling of partial Advanced SIMD structure modes. (aarch64_modes_tieable_p): Use aarch64_modes_compatible_p. Allow all vector mode ties that it allows. gcc/testsuite/ PR target/112105 * gcc.target/aarch64/pr112105.c: New test. * gcc.target/aarch64/sve/pcs/struct_3_128.c: Expect a 32-bit spill rather than a 16-bit spill.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 --- Comment #12 from vincenzo Innocente --- confirm that the patch solves the issue c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINLIB -fpic -shared -o liba.so -ldl;c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -L. -la -Wl,-rpath=.; ./a.out 0# nested_func2(int) at /data/user/innocent/MallocProfiler/tests/testStacktrace.cpp:63 1# nested_func(int) at /data/user/innocent/MallocProfiler/tests/testStacktrace.cpp:93 2# func(int) at /data/user/innocent/MallocProfiler/tests/testStacktrace.cpp:101 3# main at /data/user/innocent/MallocProfiler/tests/testStacktrace.cpp:106 4# __libc_start_main at :0 5# _start at :0 6# what is the last empty entry is a different story I suppose (not an issue at the moment). Thanks again for the fast action
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-4612-g6decda1a35be57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380
Sam James changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Comment #9 from Sam James ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > That almost definitely just exposed the issue. Let me see if I can get a
> > testcase that fails without depending on that.
>
> New testcase which seems to have the same IR going into expand for GCC
> 13.2.0 and the trunk:
> [...]
This one seems to have started with:
commit r14-2526-g8911879415d6c2
Author: Roger Sayle
Date: Fri Jul 14 18:10:05 2023 +0100
i386: Improved insv of DImode/DFmode {high,low}parts into TImode.
