[Bug c++/120882] internal compiler error in /opt/compiler-explorer/gcc-trunk-20250630/include/c++/16.0.0/concepts since 11.1 only with -std=c++23, with c++20 works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120882 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is certainly invalid (though compiler shouldn't ICE even on invalid input). va_start second argument in C++23 and earlier must be the identifier of the rightmost argument (only C++26 allows va_start (args)) and __builtin_va_arg_pack () has completely different purpose, it should be used usually on always_inline functions where the inline function has ... at the end of arguments and so does the function it calls, __builtin_va_arg_pack () is then passed in place of the ... arguments.
[Bug c++/120884] New: internal compiler error: in tsubst_pack_expansion, at cp/pt.cc:14029 since 14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120884
Bug ID: 120884
Summary: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:14029 since 14.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119346:
Program:
```
#include
#include
#include
int main()
{
std::tuple tup{1, 2, "3"};
std::apply(
[](auto... args)
-> std::enable_if_t>>),}>,
tup);
}
```
Stack dump:
```
:9:14: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:14029
9 | [](auto... args)
| ^~~~
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0xd60a53 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0xb78076 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/GjPoc6P7b
[Bug target/119100] RISC-V: missed opportunities for vector-scalar instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100 --- Comment #9 from GCC Commits --- The master branch has been updated by Paul-Antoine Arras : https://gcc.gnu.org/g:6e24814d9e09019bf42b33b66827648ceff6e7c0 commit r16-1777-g6e24814d9e09019bf42b33b66827648ceff6e7c0 Author: Paul-Antoine Arras Date: Thu Jun 26 13:20:49 2025 + RISC-V: Vector-scalar negate-multiply-(subtract-)accumulate [PR119100] This pattern enables the combine pass (or late-combine, depending on the case) to merge a vec_duplicate into a (possibly negated) minus-mult RTL instruction. Before this patch, we have two instructions, e.g.: vfmv.v.fv6,fa0 vfnmacc.vv v2,v6,v4 After, we get only one: vfnmacc.vf v2,fa0,v4 PR target/119100 gcc/ChangeLog: * config/riscv/autovec-opt.md (*vfnmsub_,*vfnmadd_): Handle both add and acc variants. * config/riscv/vector.md (*pred_mul_neg__scalar_undef): New pattern. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f16.c: Add vfnmacc and vfnmsac. * gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f64.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f16.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f64.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f16.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f64.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f16.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f64.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf_mulop.h (DEF_VF_MULOP_CASE_1): Fix return type. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmacc-run-1-f16.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmacc-run-1-f32.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmacc-run-1-f64.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsac-run-1-f16.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsac-run-1-f32.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsac-run-1-f64.c: New test.
[Bug gcov-profile/120881] New: [16 Regression] -fstack-protector-all -pg doesn't call mount at function entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
Bug ID: 120881
Summary: [16 Regression] -fstack-protector-all -pg doesn't call
mount at function entry
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-zen4-1 gcc]$ cat /tmp/x.c
__attribute__ ((weak)) __attribute__ ((noinline, noclone)) void
f1 (void)
{
}
__attribute__ ((weak)) __attribute__ ((noinline, noclone)) void
f2 (void)
{
f1 ();
asm volatile ("");
}
__attribute__ ((weak)) __attribute__ ((noinline, noclone)) void
f3 (int count)
{
for (int i = 0; i < count; ++i)
{
f1 ();
f2 ();
}
}
int
main (void)
{
f3 (1000);
return 0;
}
[hjl@gnu-zen4-1 gcc]$ ./xgcc -B./ -fstack-protector-all -O2 -pg /tmp/x.c -S
[hjl@gnu-zen4-1 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.weak f1
.type f1, @function
f1:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
1: callmcount
movq%fs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
movq-8(%rbp), %rax
subq%fs:40, %rax
jne .L4
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
ret
.L4:
.cfi_restore_state
call__stack_chk_fail
.cfi_endproc
.LFE0:
.size f1, .-f1
.p2align 4
.weak f2
.type f2, @function
f2:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
1: callmcount
movq%fs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
callf1
movq-8(%rbp), %rax
subq%fs:40, %rax
jne .L7
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
ret
.L7:
.cfi_restore_state
call__stack_chk_fail
.cfi_endproc
.LFE1:
.size f2, .-f2
.p2align 4
.weak f3
.type f3, @function
f3:
.LFB2:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movq%r12, -8(%rbp)
.cfi_offset 12, -24
movq%fs:40, %r12
movq%r12, -24(%rbp)
movl%edi, %r12d
testl %r12d, %r12d
jle .L8
movq%rbx, -16(%rbp)
.cfi_offset 3, -32
xorl%ebx, %ebx
.p2align 4
.p2align 3
.L10:
callf1
addl$1, %ebx
callf2
cmpl%ebx, %r12d
jne .L10
movq-16(%rbp), %rbx
.cfi_restore 3
.L8:
movq-24(%rbp), %rax
subq%fs:40, %rax
jne .L13
movq-8(%rbp), %r12
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
ret
.L13:
.cfi_restore_state
movq%rbx, -16(%rbp)
.cfi_offset 3, -32
1: callmcount << Isn't at the function entry.
call__stack_chk_fail
.cfi_endproc
.LFE2:
.size f3, .-f3
.section.text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function
main:
.LFB3:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
1: callmcount
movq%fs:40, %rdi
movq%rdi, -8(%rbp)
movl$1000, %edi
callf3
movq-8(%rbp), %rax
subq%fs:40, %rax
jne .L16
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
xorl%eax, %eax
ret
.L16:
.cfi_restore_state
call__stack_chk_fail
.cfi_endproc
.LFE3:
.size main, .-main
.ident "GCC: (GNU) 16.0.0 20250629 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-zen4-1 gcc]$
[Bug c++/120880] New: g++: internal compiler error: Segmentation fault since 10.1 only with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120880
Bug ID: 120880
Summary: g++: internal compiler error: Segmentation fault since
10.1 only with -std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Only happens with -std=c++20
Program:
```
int main()
{
[](decltype(([]() -> int {})) f) {}();
}
```
Stack dump:
```
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug tree-optimization/120885] New: SLP build does not consider operand swapping for conditional commutative operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120885 Bug ID: 120885 Summary: SLP build does not consider operand swapping for conditional commutative operators Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- While r16-1778-gf788324c724240 added support for operand swapping during SLP build for internal function calls and ternary operators the handling of commutative but conditional internal functions isn't implemented yet. There is possibly difficulty with the build for operand zero continuing to live.
[Bug tree-optimization/120886] New: SLP build does not consider operand swapping for commutative builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120886 Bug ID: 120886 Summary: SLP build does not consider operand swapping for commutative builtin functions Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- While r16-1778-gf788324c724240 added support for internal functions notably support for __builtin_fma () is missing because commutative_ternary_fn_p operates on internal_fn rather than combined_fn.
[Bug fortran/120889] New: [16 regression] gfortran.dg/asan/array_constructor_1.f90 Fails since r16-1696-gdff66a690f6d47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120889 Bug ID: 120889 Summary: [16 regression] gfortran.dg/asan/array_constructor_1.f90 Fails since r16-1696-gdff66a690f6d47 Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kishan at gcc dot gnu.org CC: vehre at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-linux-gnu Running CI/gcc/gcc/testsuite/gfortran.dg/asan/asan.exp ... FAIL: gfortran.dg/asan/array_constructor_1.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/array_constructor_1.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/array_constructor_1.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/array_constructor_1.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/array_constructor_1.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/array_constructor_1.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/associate_58.f90 -fsanitize=address -O (test for excess errors) FAIL: gfortran.dg/asan/associate_59.f90 -fsanitize=address -O (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address -Os (test for excess errors) FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O0 (test for excess errors) FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O1 (test for excess errors) FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O2 (test for excess errors) FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O3 -g (test for excess errors) FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -Os (test for excess errors) === gcc Summary === # of unexpected failures32 # of unresolved testcases 30
[Bug target/120888] [16 regression] promotion of unsigned char and short function arguments sign extends them since r16-170-ga670ebde3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888 Sam James changed: What|Removed |Added Summary|promotion of unsigned char |[16 regression] promotion |and short function |of unsigned char and short |arguments sign extends them |function arguments sign |since |extends them since |gcc-16-170-ga670ebde3995|r16-170-ga670ebde3995 Target Milestone|--- |16.0
[Bug c++/120890] New: virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890 Bug ID: 120890 Summary: virtual destructor on base class variable does not call derived class destructor when using [] destructor Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Dirk.DeRycke at kla dot com Target Milestone: --- Created attachment 61764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61764&action=edit See description. The virtual destructor of the derived class is not called when calling delete [] on an array of base pointers. However calling virtual members through the base class does work. When dropping the array and using a single object there is no problem either. This doesn't work in GCC 14.2. 14.3 and 15.1 I checked the misbehaving code on Cfr compiler explorer https://godbolt.org/ Besides a redhat 14.2.1 compiler and a buildroot crosstool 14.2.x In attach tar.gz containing gcc14bug.cpp -> the faulting programm using object arrays [] bug_gcc_expected_result.txt -> correct results from GCC 11,12,13 bug_gcc_wrong_result.txt -> wrong results from GCC 14,15 gcc14bug_no_array.cpp -> dropping arrays makes it work
[Bug c++/120891] New: [C++20] ICE in tsubst when processing nested template lambda and with in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120891 Bug ID: 120891 Summary: [C++20] ICE in tsubst when processing nested template lambda and with in template instantiation Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marko1616 at outlook dot com Target Milestone: --- Created attachment 61765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61765&action=edit Reproduction code Abstract: Encounters an internal compiler error when processing nested lambda expressions involving tuple operations within template instantiation. Tested version: GNU C++17 (Debian 14.2.0-19) and mainline(92cbe07) Output: ``` Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++ Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20250630/configure --prefix=/opt/compiler-explorer/gcc-build/staging --enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2,cobol --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build-gcc-92cbe073528f774361519a430c2c0df859fe1329-binutils-2.44 Thread model: posix Supported LTO compression algorithms: zlib gcc version 16.0.0 20250630 (experimental) (Compiler-Explorer-Build-gcc-92cbe073528f774361519a430c2c0df859fe1329-binutils-2.44) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-fno-verbose-asm' '-S' '-v' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' /opt/compiler-explorer/gcc-trunk-20250630/bin/../libexec/gcc/x86_64-linux-gnu/16.0.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/ -D_GNU_SOURCE -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -g -std=c++20 -version -fdiagnostics-color=always -fno-verbose-asm -o /app/output.s GNU C++20 (Compiler-Explorer-Build-gcc-92cbe073528f774361519a430c2c0df859fe1329-binutils-2.44) version 16.0.0 20250630 (experimental) (x86_64-linux-gnu) compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../include/c++/16.0.0" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../include/c++/16.0.0/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../include/c++/16.0.0/backward" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../include/c++/16.0.0 /opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../include/c++/16.0.0/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../include/c++/16.0.0/backward /opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/include /opt/compiler-explorer/gcc-trunk-20250630/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-2025
[Bug c++/120890] virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890
--- Comment #1 from De Rycke, Dirk ---
// the simple example
#include
#include
class vBaseClass
{
public:
vBaseClass ()
{
printf ("Construct %s\n", __PRETTY_FUNCTION__);
}
virtual ~ vBaseClass ()
{
printf ("Destruct %s\n", __PRETTY_FUNCTION__);
}
virtual void print ()
{
printf ("%s\n", __PRETTY_FUNCTION__);
}
};
class derivedClass:public vBaseClass
{
public:
derivedClass ()
{
printf ("Construct %s\n", __PRETTY_FUNCTION__);
}
~derivedClass ()
{
printf ("Destruct %s\n", __PRETTY_FUNCTION__);
}
void print ()
{
printf ("%s\n", __PRETTY_FUNCTION__);
}
};
using
std::cout;
int
main (int argc, char *argv[])
{
cout << "Test 1: base var\n";
vBaseClass *
testObjs = new derivedClass[2];
testObjs[0].print ();
delete[]testObjs;
cout << "Test 2: derived var\n";
derivedClass *
testObjs2 = new derivedClass[2];
testObjs2[0].print ();
delete[]testObjs2;
}
output
Test 1: base var
Construct vBaseClass::vBaseClass()
Construct derivedClass::derivedClass()
Construct vBaseClass::vBaseClass()
Construct derivedClass::derivedClass()
virtual void derivedClass::print()
Destruct virtual vBaseClass::~vBaseClass() <- missing derived destructor
Destruct virtual vBaseClass::~vBaseClass() <- missing derived destructor
Test 2: derived var
Construct vBaseClass::vBaseClass()
Construct derivedClass::derivedClass()
Construct vBaseClass::vBaseClass()
Construct derivedClass::derivedClass()
virtual void derivedClass::print()
Destruct virtual derivedClass::~derivedClass()
Destruct virtual vBaseClass::~vBaseClass()
Destruct virtual derivedClass::~derivedClass()
Destruct virtual vBaseClass::~vBaseClass()
[Bug fortran/120889] [16 regression] gfortran.dg/asan/array_constructor_1.f90 Fails since r16-1696-gdff66a690f6d47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120889 --- Comment #1 from Andre Vehreschild --- I'll have a look as soon as I finish the work for aarch64-freebsd.
[Bug c/120520] [C2y] Implement N3466, Clarifications on null pointers in the library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e33409a83251d057eb03b22e8f95f3ad7bf822e1 commit r16-1775-ge33409a83251d057eb03b22e8f95f3ad7bf822e1 Author: Jakub Jelinek Date: Mon Jun 30 11:08:16 2025 +0200 Extend nonnull_if_nonzero attribute [PR120520] C2Y voted in the https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3466.pdf paper, which clarifies some of the conditional nonnull cases. For strncat/__strncat_chk no changes are necessary, we already use __attribute__((nonnull (1), nonnull_if_nonzero (2, 3))) attributes on the builtin and glibc can do the same too, meaning that first argument must be nonnull always and second must be nonnull if the third one is nonzero. The problem is with the fread/fwrite changes, where the paper adds: If size or nmemb is zero, +ptr may be a null pointer, fread returns zero and the contents of the array and the state of the stream remain unchanged. and ditto for fwrite, so the two argument nonnull_if_nonzero attribute isn't usable to express that, because whether the pointer can be null depends on 2 integral arguments rather than one. The following patch extends the nonnull_if_nonzero attribute, so that instead of requiring 2 arguments it allows 2 or 3, the first one is still the pointer argument index which sometimes must not be null and the other one or two are integral arguments, if there are 2, the invalid case is only if pointer is null and both the integral arguments are nonzero. 2025-06-30 Jakub Jelinek PR c/120520 PR c/117023 gcc/ * builtin-attrs.def (DEF_LIST_INT_INT_INT): Define it and use for 1,2,3. (ATTR_NONNULL_IF123_LIST): New DEF_ATTR_TREE_LIST. (ATTR_NONNULL_4_IF123_LIST): Likewise. * builtins.def (BUILT_IN_FWRITE): Use ATTR_NONNULL_4_IF123_LIST instead of ATTR_NONNULL_LIST. (BUILT_IN_FWRITE_UNLOCKED): Likewise. * gimple.h (infer_nonnull_range_by_attribute): Add another optional tree * argument defaulted to NULL. * gimple.cc (infer_nonnull_range_by_attribute): Add OP3 argument, handle 3 argument nonnull_if_nonzero attribute. * builtins.cc (validate_arglist): Handle 3 argument nonnull_if_nonzero attribute. * tree-ssa-ccp.cc (pass_post_ipa_warn::execute): Likewise. * ubsan.cc (instrument_nonnull_arg): Adjust infer_nonnull_range_by_attribute caller, handle 3 argument nonnull_if_nonzero attribute. * gimple-range-infer.cc (gimple_infer_range::gimple_infer_range): Handle 3 argument nonnull_if_nonzero attribute. * doc/extend.texi (nonnull_if_nonzero): Document 3 argument version of the attribute. gcc/c-family/ * c-attribs.cc (c_common_gnu_attributes): Allow 2 or 3 arguments for nonnull_if_nonzero attribute instead of only 2. (handle_nonnull_if_nonzero_attribute): Handle 3 argument nonnull_if_nonzero. * c-common.cc (struct nonnull_arg_ctx): Rename other member to other1, add other2 member. (check_function_nonnull): Clear a if nonnull attribute has an argument. Adjust for nonnull_arg_ctx changes. Handle 3 argument nonnull_if_nonzero attribute. (check_nonnull_arg): Adjust for nonnull_arg_ctx changes, emit different diagnostics for 3 argument nonnull_if_nonzero attributes. (check_function_arguments): Adjust ctx var initialization. gcc/analyzer/ * sm-malloc.cc (malloc_state_machine::on_stmt): Handle 3 argument nonnull_if_nonzero attribute. gcc/testsuite/ * gcc.dg/nonnull-9.c: Tweak for 3 argument nonnull_if_nonzero attribute support, add further tests. * gcc.dg/nonnull-12.c: New test. * gcc.dg/nonnull-13.c: New test. * gcc.dg/nonnull-14.c: New test. * c-c++-common/ubsan/nonnull-8.c: New test. * c-c++-common/ubsan/nonnull-9.c: New test.
[Bug c++/120875] New: internal compiler error: in unify, at cp/pt.cc:25494 since 11.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120875
Bug ID: 120875
Summary: internal compiler error: in unify, at cp/pt.cc:25494
since 11.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Program:
```
template
struct bar;
template
struct bar {};
```
Stack dump:
```
:4:8: internal compiler error: in unify, at cp/pt.cc:25494
4 | struct bar {};
|^
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0xd73097 maybe_process_partial_specialization(tree_node*)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/Ks818d19M
[Bug c++/120876] New: internal compiler error: Segmentation fault finish_id_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120876
Bug ID: 120876
Summary: internal compiler error: Segmentation fault
finish_id_expression
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Program:
```
#include
template
class IsCharArrayNew{
private:
static auto
Test(decltype(ArrayRef(static_cast(nullptr->std::true_type;
public:
static constexpr bool value=decltype(Test(0))::value;
};
int main()
{
std::cout<::value;
}
```
Stack dump:
```
:7:46: internal compiler error: Segmentation fault
7 | static constexpr bool value=decltype(Test(0))::value;
| ^~~
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xd4bb3d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd6e87d instantiate_decl(tree_node*, bool, bool)
???:0
0xbf91c8 mark_used(tree_node*, int)
???:0
0xda9b84 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned long)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/16vxjhaPP
[Bug c/117023] [C2y] Implement N3322, Allow zero length operations on null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023 --- Comment #12 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e33409a83251d057eb03b22e8f95f3ad7bf822e1 commit r16-1775-ge33409a83251d057eb03b22e8f95f3ad7bf822e1 Author: Jakub Jelinek Date: Mon Jun 30 11:08:16 2025 +0200 Extend nonnull_if_nonzero attribute [PR120520] C2Y voted in the https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3466.pdf paper, which clarifies some of the conditional nonnull cases. For strncat/__strncat_chk no changes are necessary, we already use __attribute__((nonnull (1), nonnull_if_nonzero (2, 3))) attributes on the builtin and glibc can do the same too, meaning that first argument must be nonnull always and second must be nonnull if the third one is nonzero. The problem is with the fread/fwrite changes, where the paper adds: If size or nmemb is zero, +ptr may be a null pointer, fread returns zero and the contents of the array and the state of the stream remain unchanged. and ditto for fwrite, so the two argument nonnull_if_nonzero attribute isn't usable to express that, because whether the pointer can be null depends on 2 integral arguments rather than one. The following patch extends the nonnull_if_nonzero attribute, so that instead of requiring 2 arguments it allows 2 or 3, the first one is still the pointer argument index which sometimes must not be null and the other one or two are integral arguments, if there are 2, the invalid case is only if pointer is null and both the integral arguments are nonzero. 2025-06-30 Jakub Jelinek PR c/120520 PR c/117023 gcc/ * builtin-attrs.def (DEF_LIST_INT_INT_INT): Define it and use for 1,2,3. (ATTR_NONNULL_IF123_LIST): New DEF_ATTR_TREE_LIST. (ATTR_NONNULL_4_IF123_LIST): Likewise. * builtins.def (BUILT_IN_FWRITE): Use ATTR_NONNULL_4_IF123_LIST instead of ATTR_NONNULL_LIST. (BUILT_IN_FWRITE_UNLOCKED): Likewise. * gimple.h (infer_nonnull_range_by_attribute): Add another optional tree * argument defaulted to NULL. * gimple.cc (infer_nonnull_range_by_attribute): Add OP3 argument, handle 3 argument nonnull_if_nonzero attribute. * builtins.cc (validate_arglist): Handle 3 argument nonnull_if_nonzero attribute. * tree-ssa-ccp.cc (pass_post_ipa_warn::execute): Likewise. * ubsan.cc (instrument_nonnull_arg): Adjust infer_nonnull_range_by_attribute caller, handle 3 argument nonnull_if_nonzero attribute. * gimple-range-infer.cc (gimple_infer_range::gimple_infer_range): Handle 3 argument nonnull_if_nonzero attribute. * doc/extend.texi (nonnull_if_nonzero): Document 3 argument version of the attribute. gcc/c-family/ * c-attribs.cc (c_common_gnu_attributes): Allow 2 or 3 arguments for nonnull_if_nonzero attribute instead of only 2. (handle_nonnull_if_nonzero_attribute): Handle 3 argument nonnull_if_nonzero. * c-common.cc (struct nonnull_arg_ctx): Rename other member to other1, add other2 member. (check_function_nonnull): Clear a if nonnull attribute has an argument. Adjust for nonnull_arg_ctx changes. Handle 3 argument nonnull_if_nonzero attribute. (check_nonnull_arg): Adjust for nonnull_arg_ctx changes, emit different diagnostics for 3 argument nonnull_if_nonzero attributes. (check_function_arguments): Adjust ctx var initialization. gcc/analyzer/ * sm-malloc.cc (malloc_state_machine::on_stmt): Handle 3 argument nonnull_if_nonzero attribute. gcc/testsuite/ * gcc.dg/nonnull-9.c: Tweak for 3 argument nonnull_if_nonzero attribute support, add further tests. * gcc.dg/nonnull-12.c: New test. * gcc.dg/nonnull-13.c: New test. * gcc.dg/nonnull-14.c: New test. * c-c++-common/ubsan/nonnull-8.c: New test. * c-c++-common/ubsan/nonnull-9.c: New test.
[Bug c++/120877] New: internal compiler error: Segmentation fault since 10.1 with std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120877 Bug ID: 120877 Summary: internal compiler error: Segmentation fault since 10.1 with std=c++20 Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mario.rodriguezb1 at um dot es Target Milestone: --- Program: ``` #include #include using var = any_name; var v = 5; get::index_of_type>(v) =5; ``` Stack dump: ``` :5:53: internal compiler error: Segmentation fault 5 | get::index_of_type>(v) =5; | ^ 0x2844425 diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag (*) [1], diagnostic_t) ???:0 0x2866fc6 internal_error(char const*, ...) ???:0 0xd988cb finish_call_expr(tree_node*, vec**, bool, bool, int) ???:0 0xd166e3 c_parse_file() ???:0 0xe7e469 c_common_parse_file() ???:0 ``` To quickly reproduce: https://godbolt.org/z/ncMbrfbdP
[Bug middle-end/118094] Removal of checking size being zero before memcpy when can prove src/dst arguments are non-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118094 Bug 118094 depends on bug 120520, which changed state. Bug 120520 Summary: [C2y] Implement N3466, Clarifications on null pointers in the library https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/120520] [C2y] Implement N3466, Clarifications on null pointers in the library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Implemented for GCC 16. Though this really needs changes on the glibc side as well, both for this paper and for the earlier paper for which nonnull_if_nonzero 2 argument attribute has been added.
[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106113 Uroš Bizjak changed: What|Removed |Added CC||guillaume.piolat at gmail dot com --- Comment #7 from Uroš Bizjak --- *** Bug 98612 has been marked as a duplicate of this bug. ***
[Bug target/98612] _mm_comieq_sd has wrong semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612 Uroš Bizjak changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #11 from Uroš Bizjak --- (In reply to Dominik Mierzejewski from comment #10) > It looks like this was fixed in GCC13 (bug 106113). Closed as duplicate. *** This bug has been marked as a duplicate of bug 106113 ***
[Bug c++/120878] New: ICE: in adjust_temp_type, at cp/constexpr.cc:1791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120878
Bug ID: 120878
Summary: ICE: in adjust_temp_type, at cp/constexpr.cc:1791
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
Starts to baliling out since gcc-11: https://godbolt.org/z/3aWo3dsMs
Simplified test:
struct GLS {
int a;
};
auto GL2 = [](auto a); { return GLS{a}; };
constexpr GLS (*fp3)(char) = GL2;
static_assert(fp3('3').a == '3', "");
Stack Dump:
: In lambda function:
:4:22: error: expected '{' before ';' token [-Wtemplate-body]
4 | auto GL2 = [](auto a); { return GLS{a}; };
| ^
: At global scope:
:4:24: error: expected unqualified-id before '{' token
4 | auto GL2 = [](auto a); { return GLS{a}; };
|^
:5:30: error: invalid user-defined conversion from ''
to 'GLS (*)(char)' [-fpermissive]
5 | constexpr GLS (*fp3)(char) = GL2;
| ^~~
:4:12: note: candidate is: 'constexpr::operator
decltype
(((const*)0)->operator()(static_cast()))
(*)(auto:1)() const [with auto:1 = char; decltype
(((const*)0)->operator()(static_cast()))
= void]' (near match)
4 | auto GL2 = [](auto a); { return GLS{a}; };
|^
:4:12: note: no known conversion from 'void (*)(char)' to 'GLS
(*)(char)'
:6:18: internal compiler error: in adjust_temp_type, at
cp/constexpr.cc:1791
6 | static_assert(fp3('3').a == '3', "");
| ~~~^
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0xb6b911 maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0xde82a7 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
???:0
0xb288b4 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xdd98b2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/120887] New: internal compiler error: in type_dependent_expression_p, at cp/pt.cc:29376 since 12.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120887
Bug ID: 120887
Summary: internal compiler error: in
type_dependent_expression_p, at cp/pt.cc:29376 since
12.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Program:
```
/* internal compiler error: Check code */
#include
int main(){
EXPECT_THROW([[maybe_unused]] (auto e = (expected{});),
std::bad_expected_access);
}
```
Stack dump:
```
:4:67: internal compiler error: in type_dependent_expression_p, at
cp/pt.cc:29376
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0x184f51c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x18530d7 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0xd2b5ba instantiation_dependent_expression_p(tree_node*)
???:0
0x184f51c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x184f718 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x184fdc6 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xb93bac cp_fold_function(tree_node*)
???:0
0xbe0429 finish_function(bool)
???:0
0xc2b3ca maybe_add_lambda_conv_op(tree_node*)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/6PM6zfqx5
[Bug target/120888] New: promotion of unsigned char and short function arguments sign extends them since gcc-16-170-ga670ebde3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888 Bug ID: 120888 Summary: promotion of unsigned char and short function arguments sign extends them since gcc-16-170-ga670ebde3995 Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- Created attachment 61763 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61763&action=edit gcc/testsuite/gcc.target/xtensa/abi_u8_arg.c xtensa ABI prescribes sign extension of signed 8- and 16-bit function arguments to 32 bits and zero extension of unsigned 8- and 16-bit function arguments. Attached test starts failing at revision gcc-16-170-ga670ebde3995. While debugging it I've noticed that precompute_register_parameters() gets the `args` argument where `unsignedp` is 0 and thus generates sign extension call for that argument.
[Bug target/120888] promotion of unsigned char and short function arguments sign extends them since gcc-16-170-ga670ebde3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888 Sam James changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Sam James --- https://inbox.sourceware.org/gcc-patches/636adbd9-4d16-4892-b8f7-b2906edc7...@yahoo.co.jp/
[Bug c++/120883] New: internal compiler error: in write_type, at cp/mangle.cc:2687 since 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120883
Bug ID: 120883
Summary: internal compiler error: in write_type, at
cp/mangle.cc:2687 since 13.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120275:
Program:
```
#include
int main() {
apply(
[](auto&&... a) {
decltype(auto) l = {a...};
return l;
},
std::make_tuple(1, 2.3, '4')
);
return 0;
}
```
Stack dump:
```
In file included from
/opt/compiler-explorer/gcc-trunk-20250630/include/c++/16.0.0/tuple:43,
from :2:
/opt/compiler-explorer/gcc-trunk-20250630/include/c++/16.0.0/bits/invoke.h:62:5:
internal compiler error: in write_type, at cp/mangle.cc:2687
62 | __invoke_impl(__invoke_other, _Fn&& __f, _Args&&... __args)
| ^
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0xc3dda9 mangle_decl(tree_node*)
???:0
0x1827ab5 decl_assembler_name(tree_node*)
???:0
0x1850d97 assign_assembler_name_if_needed(tree_node*)
???:0
0xf521bf cgraph_node::analyze()
???:0
0xf55791 symbol_table::finalize_compilation_unit()
???:0
```
To quickly reproduce:
https://godbolt.org/z/3aGnzjzve
[Bug gcov-profile/120881] [16 Regression] -fstack-protector-all -pg doesn't call mount at function entry by r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881 H.J. Lu changed: What|Removed |Added CC||lili.cui at intel dot com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-06-30 Summary|[16 Regression] |[16 Regression] |-fstack-protector-all -pg |-fstack-protector-all -pg |doesn't call mount at |doesn't call mount at |function entry |function entry by ||r16-1550-g9244ea4bf55638 --- Comment #1 from H.J. Lu --- It is caused by r16-1550-g9244ea4bf55638: 2c30f828e4507863713cff44cd30c88aa7f27865 is the first bad commit commit 2c30f828e4507863713cff44cd30c88aa7f27865 Author: Lili Cui Date: Tue Jun 17 21:39:38 2025 +0800 x86: Enable separate shrink wrapping
[Bug gcov-profile/120881] [16 Regression] -fstack-protector-all -pg doesn't call mount at function entry by r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881 Sam James changed: What|Removed |Added Target Milestone|--- |16.0
[Bug tree-optimization/120817] [13/14/15/16 regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #10 from Richard Biener ---
(In reply to Tamar Christina from comment #8)
> C testcase
>
> typedef struct {
> int _M_current;
> } __normal_iterator;
>
> typedef struct {
> char _M_elems[5];
> } array_5;
>
> __normal_iterator __trans_tmp_1 = {0};
>
> array_5 copySourceIntoTarget() {
> array_5 target;
> char* target_it = target._M_elems;
>
> while (__trans_tmp_1._M_current != 0) {
> *target_it = 0;
> __trans_tmp_1._M_current++;
> target_it++;
> }
>
> return target;
> }
>
> compiled with -mcpu=neoverse-n2 -O1 -ftree-loop-vectorize
>
> The cost model for Neoverse-N2 is needed to get it to generate an Adv.SIMD
> main loop and an SVE trailing loop.
So the issue seems to be that DSE sees the .MASK_STORE after the epilog
is dead because it is to &target + _55 + POLY_INT_CST[16, 16]. Given
pointers may not "advance" to before an object we get an ao_ref with base
&target + _55
and offset = POLY_INT_CST[16, 16]
that is always out of char _M_elems[5].
So, iff that pointer increment by _55 is say for alignment peeling via mask
with
a negative bias that pointer arithmetic invokes UB and has to be done
in uintptr_t.
[Bug c++/120882] New: internal compiler error in /opt/compiler-explorer/gcc-trunk-20250630/include/c++/16.0.0/concepts since 11.1 only with -std=c++23, with c++20 works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120882
Bug ID: 120882
Summary: internal compiler error in
/opt/compiler-explorer/gcc-trunk-20250630/include/c++/
16.0.0/concepts since 11.1 only with -std=c++23, with
c++20 works fine
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Program:
```
#include
#include
void print_all(const char *,...) {
va_list args;
va_start(args, __builtin_va_arg_pack());
std::apply([=](const std::string_view& fmt, auto... args) {
print(fmt.c_str(), std::forward(args)...);
}, std::tuple(std::string_view{args}...));
va_end(args);
```
Stack dump:
```
/opt/compiler-explorer/gcc-trunk-20250630/include/c++/16.0.0/concepts:59:15:
required for the satisfaction of '__same_as<_Tp, _Up>'in set_diagnostic_buffer,
at diagnostic.cc:1960
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0x284383b diagnostic_context::finish()
???:0
0x2843b87 diagnostic_context::action_after_output(diagnostic_t)
???:0
0x284430e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2865821 warning(diagnostic_option_id, char const*, ...)
???:0
0xe05148 build_type_attribute_qual_variant(tree_node*, tree_node*, int)
???:0
0xdc5dd2 cp_build_type_attribute_variant(tree_node*, tree_node*)
???:0
0xd23306 canonicalize_type_argument(tree_node*, int)
???:0
0xd69e73 coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
???:0
0xd4a08f lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
???:0
0xd4b562 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd4be07 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc0e05a maybe_print_single_constraint_context(diagnostic_text_output_format&,
tree_node*)
???:0
0x2864678 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x2843f76 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2865821 warning(diagnostic_option_id, char const*, ...)
???:0
```
To quickly reproduce:
https://godbolt.org/z/1hGM97qvc
[Bug target/118280] [14/15/16 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280 Neal Frager changed: What|Removed |Added Attachment #61760|0 |1 is obsolete|| --- Comment #23 from Neal Frager --- Created attachment 61762 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61762&action=edit microblaze atomic test and set patch for gcc 14 I converted the diff I received from our engineering team to a version that can be applied to gcc-14. When reviewing the patch, please use this version for your review and not the version created by diff.
[Bug c++/96570] Warnings desired for time_t to/from int coversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570 --- Comment #17 from Richard Biener --- (In reply to Richard Biener from comment #16) > I have posted a prototype at > https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687651.html Discussion shows a more general approach with a __attribute__((no_implicit_truncation)) type attribute might be better. The case of widening conversions to time_t are not understood and better be separated. There's unresolved issues with respect to usual arithmetic conversions and integer promotions (cf composite types), like for time_t + 1, which will complicate implementation (and lack test coverage).
[Bug c++/120879] New: ICE: tree check: expected tree_vec, have identifier_node in tsubst_decl, at cp/pt.cc:15757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120879
Bug ID: 120879
Summary: ICE: tree check: expected tree_vec, have
identifier_node in tsubst_decl, at cp/pt.cc:15757
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-invalid-code, needs-reduction
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
$cat test.cpp
template auto lambda1() {
return [](auto x) {
struct A : T::template X... {
using T::template X::f ...;
using typename T::template X::type ...;
void g(int n) { f(n); }
void h() { type value; }
A self_member; };
return A();
};
}
struct A {
template template struct X {
void f(int);
using type = int;
X self_member;
};
};
void f() {
lambda1()
(0)
.g(0);
}
With assertion enabled:
$g++ test.cpp
: In lambda function:
:9:3: error: field 'self_member' has incomplete type
'lambda1()A' [-Wtemplate-body]
9 | A self_member; };
| ^~~
:3:12: note: definition of 'struct lambda1()A' is
not complete until the closing brace
3 | struct A : T::template X... {
|^
: At global scope:
:15:46: error: too many template-parameter-lists
15 | template template struct X {
| ^
: In instantiation of 'struct lambda1()A':
:9:16: required from 'lambda1():: [with auto:1 =
int]'
9 | A self_member; };
|^
:24:5: required from here
23 | lambda1()
|
24 | (0)
| ^~~
:3:12: error: no class template named 'X' in 'struct A'
3 | struct A : T::template X... {
|^
:4:43: error: no class template named 'X' in 'struct A'
4 | using T::template X::f ...;
| ^~~
:4:43: internal compiler error: tree check: expected tree_vec, have
identifier_node in tsubst_decl, at cp/pt.cc:15757
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0x9f8e25 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xd4c0c4 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd7a999 instantiate_class_template(tree_node*)
???:0
0xd6e87d instantiate_decl(tree_node*, bool, bool)
???:0
0xbf7843 maybe_instantiate_decl(tree_node*)
???:0
0xbf95b7 mark_used(tree_node*, int)
???:0
0xb2a403 build_op_call(tree_node*, vec**, int)
???:0
0xd98c6e finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
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/120733] [16 Regression][aarch64] ICE in gen_highpart, at lra.cc:1484 since r16-1565-g2dcc6dbd8a00ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120733
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:da3f2a561649c7c4899449c6b3ab2b6d67792a71
commit r16-1774-gda3f2a561649c7c4899449c6b3ab2b6d67792a71
Author: Richard Sandiford
Date: Mon Jun 30 08:52:26 2025 +0100
lra: Check for null lowpart_subregs [PR120733]
lra-eliminations.cc:move_plus_up tries to:
Transform (subreg (plus reg const)) to (plus (subreg reg) const)
when it is possible.
Most of it is heavily conditional:
if (!paradoxical_subreg_p (x)
&& GET_CODE (subreg_reg) == PLUS
&& CONSTANT_P (XEXP (subreg_reg, 1))
&& GET_MODE_CLASS (x_mode) == MODE_INT
&& GET_MODE_CLASS (subreg_reg_mode) == MODE_INT)
{
rtx cst = simplify_subreg (x_mode, XEXP (subreg_reg, 1),
subreg_reg_mode,
subreg_lowpart_offset (x_mode,
subreg_reg_mode));
if (cst && CONSTANT_P (cst))
but the final:
return gen_rtx_PLUS (x_mode, lowpart_subreg (x_mode,
XEXP (subreg_reg, 0),
subreg_reg_mode),
cst);
assumed without checking that lowpart_subreg succeeded. In the PR,
this led to creating a PLUS with a null operand.
In more detail, the testcase had:
(var_location a (plus:SI (subreg:SI (reg/f:DI 64 sfp) 0)
(const_int -4 [0xfffc])))
with sfp being eliminated to (plus:DI (reg:DI sp) (const_int 16)).
Initially, during the !subst_p phase, lra_eliminate_regs_1 sees
the PLUS and recurses into each operand. The recursive call sees
the SUBREG and recurses into the SUBREG_REG. Since !subst_p,
this final recursive call replaces (reg:DI sfp) with:
(plus:DI (reg:DI sfp) (const_int 16))
(i.e. keeping the base register the same). So the SUBREG is
eliminated to:
(subreg:SI (plus:DI (reg:DI sfp) (const_int 16)) 0)
The PLUS handling in lra_eliminate_regs_1 then passes this to
move_plus_up, which tries to push the SUBREG into the PLUS.
This means trying to create:
(plus:SI (simplify_gen_subreg:SI (reg:DI sfp) 0) (const_int 16))
The simplify_gen_subreg then returns null, because simplify_subreg_regno
fails both with allow_stack_regs==false (when trying to simplify the
SUBREG to a REG) and with allow_stack_regs=true (when validating
whether the SUBREG can be generated). And that in turn happens
because aarch64 refuses to allow SImode to be stored in sfp:
if (regno == SP_REGNUM)
/* The purpose of comparing with ptr_mode is to support the
global register variable associated with the stack pointer
register via the syntax of asm ("wsp") in ILP32. */
return mode == Pmode || mode == ptr_mode;
if (regno == FRAME_POINTER_REGNUM || regno == ARG_POINTER_REGNUM)
return mode == Pmode;
This seems dubious. If the frame pointer can hold a DImode value then it
can also hold an SImode value. There might be limited cases when the low
32 bits of the frame pointer are useful, but aarch64_hard_regno_mode_ok
doesn't have the context to second-guess things like that. It seemed
from a quick scan of other targets that they behave more as I'd expect.
So there might be a target bug here too. But it seemed worth fixing the
unchecked use of lowpart_subreg independently of that.
The patch fixes an existing ICE in gcc.c-torture/compile/pass.c.
gcc/
PR rtl-optimization/120733
* lra-eliminations.cc (move_plus_up): Check whether lowpart_subreg
returns null.
[Bug testsuite/120859] FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120859
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Andrew Pinski ---
I think this file just needs `/* { dg-do compile } */`
I will check tomorrow.
[Bug middle-end/120855] [16 Regression] Recent changes causing ICE in assemble_name_resolve since r16-1738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120855 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/118280] [14/15/16 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280 --- Comment #21 from Neal Frager --- Created attachment 61761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61761&action=edit test case for microblaze atomic test and set support Attached is a test case for verifying the atomic test and set support.
[Bug target/118280] [14/15/16 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280 --- Comment #20 from Neal Frager --- Created attachment 61760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61760&action=edit microblaze atomic test and set patch Attached is a proposal for adding atomic test and set support to the microblaze architecture. Our current solution requires the -mxl-barrel-shift build flag to be enabled which is not enabled by default. Do you see any issues with us changing this to make the -mxl-barrel-shift flag enabled by default? Could you please review and provide comments before we submit this as a solution? Thank you in advance for any feedback. Best regards, Neal Frager AMD
[Bug target/118280] [14/15/16 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280 --- Comment #22 from Neal Frager --- Hello everyone, Could we ask for a review / request for comment of the attached patch which will enable atomic test and set support for microblaze? Please note that this solution requires the -mxl-barrel-shift flag to be enabled, which is not the case by default. Please let us know your comments and if this could be a patch that could be submitted as a solution to the microblaze atomic issue. Best regards, Neal Frager AMD
[Bug c++/120874] New: internal compiler error: in type_dependent_expression_p, at cp/pt.cc:29442 since 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120874
Bug ID: 120874
Summary: internal compiler error: in
type_dependent_expression_p, at cp/pt.cc:29442 since
7.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Program:
```
template
void kernel1() {
__builtin_addressof(kernel1);
}
```
Stack dump:
```
:3:33: internal compiler error: in type_dependent_expression_p, at
cp/pt.cc:29442
3 | __builtin_addressof(kernel1);
| ^
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0xd91a67 finish_expr_stmt(tree_node*)
???:0
0xd166e3 c_parse_file()
???:0
0xe7e469 c_common_parse_file()
???:0
```
To reproduce:
https://godbolt.org/z/M1dfjjcvv
[Bug target/120733] [16 Regression][aarch64] ICE in gen_highpart, at lra.cc:1484 since r16-1565-g2dcc6dbd8a00ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120733 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Sandiford --- Fixed.
[Bug c++/120873] New: internal compiler error: error reporting routines re-entered. since 11.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120873
Bug ID: 120873
Summary: internal compiler error: error reporting routines
re-entered. since 11.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Program:
```
#include
using namespace std;
template
void myFunc(T a, decltype(cout << a) o=cout) {
cout << o << endl;
}
int main() {
myFunc(5);
}
```
Stack dump:
```
internal compiler error: error reporting routines re-entered.
0x284430e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x28668af error_at(unsigned long, char const*, ...)
???:0
0xb72b2a satisfaction_cache::get()
???:0
0xb79b68 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xd4c236 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd4b94b tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd74a1d instantiate_template(tree_node*, tree_node*, int)
???:0
0xd7740a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xb287c6 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xdd98b2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xd4bb3d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x28a4493 pretty_printer::format(text_info&)
???:0
0x28a9c53 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x2864678 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
???:0
0x2843f76 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2844425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2866fc6 internal_error(char const*, ...)
???:0
0xaede72 fancy_abort(char const*, int, char const*)
???:0
0x284383b diagnostic_context::finish()
???:0
```
To quickly reproduce:
https://godbolt.org/z/oKocEexe6
[Bug c++/120890] virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890 --- Comment #2 from De Rycke, Dirk --- Compilation optimization options are irrelevant. Just compile with g++ and run the output
[Bug target/120659] ICE: in riscv_sched_variable_issue, at config/riscv/riscv.cc:9879 with -O2 -mcpu=sifive-x280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120659 --- Comment #2 from GCC Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:c8cb537fdbdbc9e1c77ec389bcb99ad87b15cb92 commit r16-1779-gc8cb537fdbdbc9e1c77ec389bcb99ad87b15cb92 Author: Kito Cheng Date: Tue Jun 17 16:20:19 2025 +0800 RISC-V: Adding B ext, fp16 and missing scalar instruction type for sifive-7 pipeline model [PR120659] gcc/ChangeLog: PR target/120659 * config/riscv/sifive-7.md: Add B extension, fp16 and missing scalar instruction type for sifive-7 pipeline model. gcc/testsuite/ChangeLog: PR target/120659 * gcc.target/riscv/pr120659.c: New test.
[Bug fortran/120843] [15/16-Regression, Coarray] Inconsistent ranks for operator reported when coarray ranks differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843 Andre Vehreschild changed: What|Removed |Added Last reconfirmed||2025-06-30 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Andre Vehreschild --- Updated patch available at https://gcc.gnu.org/pipermail/fortran/2025-June/062416.html Waiting for review.
[Bug c++/120884] internal compiler error: in tsubst_pack_expansion, at cp/pt.cc:14029 since 14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120884 --- Comment #1 from Richard Biener --- Can you please help and at least fill in the ice-on-invalid or ice-on-invalid keywords yourself? Or are you not knowing whether you are fuzzing a valid or invalid testcase? You are putting quite a load on us with this endless bugfilings.
[Bug c++/120890] virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890 --- Comment #6 from Andrew Pinski --- See https://www.parashift.com/c++-faq-lite/array-derived-vs-base.html also.
[Bug c++/120890] virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- This code is undefined. Doing: vBaseClass * testObjs = new derivedClass[2]; ... delete[]testObjs; is undefined. For arrays, you have to do the delete on the same type as being created. https://stackoverflow.com/questions/6171814/why-is-it-undefined-behavior-to-delete-an-array-of-derived-objects-via-a-base
[Bug middle-end/120865] ICE in gimple-expr.cc:484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 Benjamin Schulz changed: What|Removed |Added Attachment #61751|mein_omp.cpp|main_omp.cpp description|| --- Comment #6 from Benjamin Schulz --- Comment on attachment 61751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61751 main_omp.cpp the file name in the cmakelists.txt is of course main_omp.cpp, so I changed that in the attachments
[Bug middle-end/120865] ICE in gimple-expr.cc:484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 --- Comment #7 from Benjamin Schulz --- the correct output is now this one without -O The internal compiler error is at all o levels, -O1, O2, O3.. Interestingly -ffast-math works and leads to a considerable speed-up. Just using -fno-math-errno -fno-trapping-math leads to a speed-up as well. I find it interesting that even if I put in -fno-signed-zeros, one can find -0 in the output of the LU decomposition. Ordinary matrix multiplication, on gpu 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 80 90 100 110 176 202 228 254 272 314 356 398 368 426 484 542 A Cholesky decomposition with the multiplication on gpu 4 12 -16 12 37 -43 -16 -43 98 2 0 0 6 1 0 -8 5 3 Now the cholesky decomposition is entirely done on gpu 2 0 0 6 1 0 -8 5 3 Now we do the same with the lu decomposition 1 -2 -2 -3 3 -9 0 -9 -1 2 4 7 -3 -6 26 2 Just the multiplication on gpu 1 0 0 0 3 1 0 0 -1 -0 1 0 -3 4 -2 1 1 -2 -2 -3 0 -3 6 0 0 0 2 4 0 0 0 1 Entirely on gpu 1 0 0 0 3 1 0 0 -1 -0 1 0 -3 4 -2 1 1 -2 -2 -3 0 -3 6 0 0 0 2 4 0 0 0 1 Now we do the same with the qr decomposition 12 -51 4 6 167 -68 -4 24 -41 Just the multiplication on gpu 0.857143 -0.394286 -0.331429 0.428571 0.902857 0.0342857 -0.285714 0.171429 -0.942857 14 21 -14 -1.11022e-16 175 -70 -3.10862e-15 -4.79616e-14 35 Entirely on gpu 0.857143 -0.394286 -0.331429 0.428571 0.902857 0.0342857 -0.285714 0.171429 -0.942857 14 21 -14 -1.11022e-16 175 -70 -1.33227e-15 -1.95399e-14 35 In order to test the qr decomposition, we can use Strassen's algorithm 12 -51 4 6 167 -68 -4 24 -41 or its Winograd variant, with the smaller matrices computed on gpu 12 -51 4 6 167 -68 -4 24 -41
[Bug tree-optimization/120892] Missed unrolling at -O3 due to split-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120892 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener --- IIRC path splitting is supposed to elide a dynamic branch by duplicating a loop latch into a conditional (making the loop have multiple latches).
[Bug fortran/120847] [15/16-Regression, Coarray] ICE after "Component ... already declared at..." when type with coarray comp is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847 Andre Vehreschild changed: What|Removed |Added Last reconfirmed||2025-06-30 Ever confirmed|0 |1 Summary|[Coarray] ICE after |[15/16-Regression, Coarray] |"Component ... already |ICE after "Component ... |declared at..." when type |already declared at..." |with coarray comp is|when type with coarray comp |defined |is defined Known to fail||15.1.0, 16.0 Known to work||14.1.0 Status|UNCONFIRMED |WAITING --- Comment #1 from Andre Vehreschild --- Patch proposed at: https://gcc.gnu.org/pipermail/fortran/2025-June/062417.html
[Bug tree-optimization/120892] New: Missed unrolling at -O3 due to split-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120892
Bug ID: 120892
Summary: Missed unrolling at -O3 due to split-paths
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Consider the following testcase, on aarch64:
typedef struct {
long ob_refcnt;
int size;
} PyListObject;
PyListObject *src;
PyListObject dst;
int main(void) {
#pragma GCC unroll 8
for (long i = 0; i < 128; i++) {
PyListObject *v = &src[i];
if (v->ob_refcnt >= 0)
v->ob_refcnt++;
dst = *v;
}
}
at -O2 it is unrolled successfully, as requested. I see:
./xgcc -B . -c t.c -S -o /dev/null -O2 -fdump-rtl-loop2_unroll-details=- | grep
"unroll"
t.c:9:3: note: considering unrolling loop 1 at BB 3
considering unrolling loop with constant number of iterations
t.c:9:3: optimized: loop unrolled 7 times
but at -O3 we fail to unroll the loop:
./xgcc -B . -c t.c -S -o /dev/null -O3 -fdump-rtl-loop2_unroll-details=- | grep
"unroll"
t.c:11:10: note: considering unrolling loop 1 at BB 3
considering unrolling loop with constant number of iterations
considering unrolling loop with runtime-computable number of iterations
considering unrolling loop stupidly
;; Not unrolling, contains branches
the problem seems to be due to the split-paths gimple pass. Disabling the
pass:
./xgcc -B . -c t.c -S -o /dev/null -O3 -fno-split-paths
-fdump-rtl-loop2_unroll-details=- | grep "unroll"
t.c:9:3: note: considering unrolling loop 1 at BB 3
considering unrolling loop with constant number of iterations
t.c:9:3: optimized: loop unrolled 7 times
the loop is unrolled as expected. Before split-paths, in SLSR, we have this
loop:
[local count: 1063004407]:
# ivtmp.12_14 = PHI
_6 = (void *) ivtmp.12_14;
_4 = MEM[(long int *)_6];
if (_4 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 627172604]:
_5 = _4 + 1;
_22 = (void *) ivtmp.12_14;
MEM[(long int *)_22] = _5;
[local count: 1063004410]:
_21 = (void *) ivtmp.12_14;
dst = MEM[(struct PyListObject *)_21];
ivtmp.12_15 = ivtmp.12_14 + 16;
if (ivtmp.12_15 != _24)
goto ; [98.99%]
else
goto ; [1.01%]
and then split paths duplicates the contents of the common code in bb 5 into
the conditional block (bb 4), to give:
[local count: 1063004407]:
# ivtmp.12_14 = PHI
_6 = (void *) ivtmp.12_14;
_4 = MEM[(long int *)_6];
if (_4 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 627172604]:
_5 = _4 + 1;
_22 = (void *) ivtmp.12_14;
MEM[(long int *)_22] = _5;
_16 = (void *) ivtmp.12_14;
dst = MEM[(struct PyListObject *)_16];
ivtmp.12_2 = ivtmp.12_14 + 16;
if (ivtmp.12_2 != _24)
goto ; [98.99%]
else
goto ; [1.01%]
[local count: 435831806]:
_21 = (void *) ivtmp.12_14;
dst = MEM[(struct PyListObject *)_21];
ivtmp.12_15 = ivtmp.12_14 + 16;
if (ivtmp.12_15 != _24)
goto ; [98.99%]
else
goto ; [1.01%]
[local count: 1052266997]:
# ivtmp.12_13 = PHI
goto ; [100.00%]
it's not clear to me that this transformation is even beneficial independently
of the unrolling issue, but it's unfortunate that doing this blocks the
requested unrolling.
[Bug fortran/120889] [16 regression] gfortran.dg/asan/array_constructor_1.f90 Fails since r16-1696-gdff66a690f6d47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120889 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |16.0
[Bug libstdc++/120650] Error of requesting %d from month_day_last is not detected at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120650 Tomasz Kamiński changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tomasz Kamiński --- Changes applied to v15 and v16.
[Bug c++/120890] virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890 --- Comment #4 from De Rycke, Dirk --- (In reply to Andrew Pinski from comment #3) > I am 99% sure the behavior here is correct as you can't delete an array of > derivedClass via a pointer of vBaseClass. It will always delete an array of > vBaseClass. Please compile with GCC 11,12,13... or see the results from my runs with these compilers in the attached zip file. So... Then 11,12,13 were incorrect ;), but do happen to have my expected behaviour.
[Bug target/109116] vector_pair register allocation bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109116 --- Comment #4 from GCC Commits --- The master branch has been updated by kishan parmar : https://gcc.gnu.org/g:69a2c243dd2cf9f77150c0eb86dfbc0931876bc1 commit r16-1782-g69a2c243dd2cf9f77150c0eb86dfbc0931876bc1 Author: Peter Bergner Date: Mon Jun 30 19:01:25 2025 +0530 rs6000: Disassemble opaque modes using subregs to allow optimizations PR109116 reveals missed optimizations when using unspecs to extract vector components from opaque-mode variables. Since RTL optimizers do not understand unspecs, this leads to redundant register copies. Replace unspecs with subregs, which are well understood by RTL passes, allowing optimizations to take place. 2025-06-30 Peter Bergner gcc/ PR target/109116 * config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_EXTRACT. (vsx_disassemble_pair): Expand into a vector register sized subreg. (mma_disassemble_acc): Likewise. (*vsx_disassemble_pair): Delete. (*mma_disassemble_acc): Likewise.
[Bug tree-optimization/120893] SLP costing costs vec_construct while forwprop turns it into vec_permute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120893
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-06-30
Status|UNCONFIRMED |NEW
Blocks||53947
Ever confirmed|0 |1
Keywords||missed-optimization
--- Comment #1 from Richard Biener ---
vect_build_slp_tree_1 handles references to existing vector elements and
rejects combining from two such. vect_build_slp_tree_2 handles a single vector
source
as extern unpermuted vector + VEC_PERM. Extending this to exactly _two_
vector sources (re-use the two_operands flag maybe?) should be trivial
given we already emit a VEC_PERM.
Note this interacts with permuting operands upthread which might be able
to permute the graph to a shape where all existing vectors appear on
their own, like { a[0] + b[0], b[1] + a[1] } vs. { a[0] + b[0], a[1] + b[1] }
where we obviously prefer to vectorize as a + b rather than
perm (a, b, { 0, 2 }) + perm (a, b { 3, 1 }).
While we have a permute optimization phase that does not have the power
to "undo" such permute.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/120893] New: SLP costing costs vec_construct while forwprop turns it into vec_permute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120893 Bug ID: 120893 Summary: SLP costing costs vec_construct while forwprop turns it into vec_permute Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jchrist at linux dot ibm.com Target Milestone: --- Created attachment 61766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61766&action=edit Test case The attached test case fails to SLP vectorize on s390x due to unprofitable costs. The high costs come from two vec_construct operations that are created for external nodes that combine two different vectors: missed: Build SLP failed: different BIT_FIELD_REF arguments in _25 = BIT_FIELD_REF ; Forwprop pass later replaces these vec_construct operations by vec_permute operations which would be a lot cheaper and make vectorization profitable: _2 = VEC_PERM_EXPR ; vect__2.3_54 = VIEW_CONVERT_EXPR(_2); _4 = VEC_PERM_EXPR ; vect__4.4_56 = VIEW_CONVERT_EXPR(_4); Instead of treating this special case inside a vector cost model, could this be solved in SLP directly?
[Bug libstdc++/120650] Error of requesting %d from month_day_last is not detected at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120650 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:53d2ca1541b34bb2f840d5aede9b826025dd0bb7 commit r15-9876-g53d2ca1541b34bb2f840d5aede9b826025dd0bb7 Author: Tomasz KamiÅski Date: Tue Jun 24 09:17:12 2025 +0200 libstdc++: Report compilation error on formatting "%d" from month_last [PR120650] For month_day we incorrectly reported day information to be available, which lead to format_error being thrown from the call to formatter::format at runtime, instead of making call to format ill-formed. PR libstdc++/120650 libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (formatter::parse): Call _M_parse with only Month being available. (cherry picked from commit 190f077fe5f318e168a7a1e1aa57058f377e)
[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 --- Comment #2 from Walter Spector --- Revisiting this, I still think that by the definition of the default -std=gnu, the compiler should give a warning by default, and give an error when -std=f95 (or higher) is specified. Currently no warning is issued by default, and only a warning is issued with -std=f95: $ cat pf.f program pf implicit none character(*), parameter :: hwc = '(12hhello World!)' print 100 100 format (12hHello world!) write (*, hwc) end $ gfortran pf.f $ ./a.out Hello world! hello World! $ $ rm a.out $ gfortran -std=f95 pf.f pf.f:7:21: 7 | 100 format (12hHello world!) | 1 Warning: The H format specifier at (1) is a Fortran 95 deleted feature pf.f:9:19: 9 | write (*, hwc) | 1 Warning: The H format specifier at (1) is a Fortran 95 deleted feature $ ./a.out Hello world! hello World! $ $ gfortran --version GNU Fortran (GCC) 16.0.0 20250529 (experimental) Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $
[Bug ipa/120894] Usage of std::pmr::polymorphic_allocator is not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120894
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |ipa
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2025-06-30
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
This seems related to how std::function optimizing. Basically we don't
devirutalize things until late .
Before inlining we have:
```
_1 = std::pmr::get_default_resource ();
res ={v} {CLOBBER(bob)};
res.D.43232._vptr.memory_resource = &MEM [(void
*)&_ZTVN12_GLOBAL__N_114StaticResourceE + 16B];
res.buffer = &buf[0];
res.buffer_left = 16;
res.upstream = _1;
MEM[(struct polymorphic_allocator *)&D.44315] ={v} {CLOBBER(bob)};
MEM[(struct polymorphic_allocator *)&D.44315]._M_resource = &res.D.43232;
std::vector >::vector
(&vec, 16, &D.44315);
```
And that function was:
```
MEM[(struct _Vector_impl *)this_2(D)].D.43600 = MEM[(const struct
polymorphic_allocator &)__a_5(D)];
MEM[(struct _Vector_impl_data *)this_2(D) + 8B] ={v} {CLOBBER(bob)};
MEM[(struct _Vector_impl_data *)this_2(D) + 8B]._M_start = 0B;
MEM[(struct _Vector_impl_data *)this_2(D) + 8B]._M_finish = 0B;
MEM[(struct _Vector_impl_data *)this_2(D) + 8B]._M_end_of_storage = 0B;
if (__n_4(D) != 0)
goto ; [71.00%]
else
goto ; [29.00%]
[local count: 83859236]:
_10 = MEM[(struct polymorphic_allocator *)this_2(D)]._M_resource;
_11 = *_10._vptr.memory_resource;
_12 = MEM[(int (*) () *)_11 + 16B];
_13 = OBJ_TYPE_REF(_12;(struct memory_resource)_10->2B) (_10, __n_4(D), 1);
```
MEM[(struct polymorphic_allocator *)this_2(D)]._M_resource
could be optimize to just :
MEM[(const struct polymorphic_allocator &)__a_5(D)]._M_resource I think.
That might improve things slightly but not enough though.
[Bug target/120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763 Bug 120763 depends on bug 120714, which changed state. Bug 120714 Summary: RISC-V: incorrect frame pointer CFA address for stack-clash protection loops https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/120714] RISC-V: incorrect frame pointer CFA address for stack-clash protection loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Fixed with Alexey's patch on the trunk.
[Bug target/120714] RISC-V: incorrect frame pointer CFA address for stack-clash protection loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714 --- Comment #5 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:45a17e3081120f51f8e8b1d7cda73c7d89453e85 commit r16-1834-g45a17e3081120f51f8e8b1d7cda73c7d89453e85 Author: Alexey Merzlyakov Date: Mon Jun 30 13:58:29 2025 -0600 [RISC-V] Correct CFA notes for stack-clash protection [PR120714] Fixes incorrect SP-addresses used in CFA notes for the stack probes unrelative to the frame's top. It applied to the RISC-V targets code generation when the stack-clash protection is enabled. PR target/120714 gcc/ChangeLog: * config/riscv/riscv.cc (riscv_allocate_and_probe_stack_space): Fix SP-addresses in REG_CFA_DEF_CFA notes for stack-clash case. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr120714.c: New test.
[Bug target/119944] [16] RISC-V: g++.dg/torture/pr119610.C "terminate called after throwing an instance of 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119944 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Jeffrey A. Law --- Same root cause. Alexey's patch has been committed to the trunk. *** This bug has been marked as a duplicate of bug 120714 ***
[Bug target/120714] RISC-V: incorrect frame pointer CFA address for stack-clash protection loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714 Jeffrey A. Law changed: What|Removed |Added CC||ewlu at rivosinc dot com --- Comment #7 from Jeffrey A. Law --- *** Bug 119944 has been marked as a duplicate of this bug. ***
[Bug target/120659] ICE: in riscv_sched_variable_issue, at config/riscv/riscv.cc:9879 with -O2 -mcpu=sifive-x280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120659 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Resolved on the trunk.
[Bug target/120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763 Bug 120763 depends on bug 120659, which changed state. Bug 120659 Summary: ICE: in riscv_sched_variable_issue, at config/riscv/riscv.cc:9879 with -O2 -mcpu=sifive-x280 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120659 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/120650] Error of requesting %d from month_day_last is not detected at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120650 Tomasz Kamiński changed: What|Removed |Added Target Milestone|--- |15.2
[Bug target/120895] AVX data types default alignment is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895 --- Comment #1 from David C. Partridge --- This also applies to arm64 / Neon
[Bug target/120895] AVX data types default alignment is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895 --- Comment #2 from Andrew Pinski --- (In reply to David C. Partridge from comment #1) > This also applies to arm64 / Neon Do you have an example there because I think the problems are 2 different issues.
[Bug tree-optimization/120892] Missed unrolling at -O3 due to split-paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120892 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112402 CC||pinskia at gcc dot gnu.org Last reconfirmed||2025-06-30 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- I was originally going to move path splitting to RTL after unrolling but there was some performance regressions with that; I don't know if I have the patch still though (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112402#c2 for information on this idea and some of the history around path splitting which I had collected a few years back). What I did to resolve the ifcvt issue was tune the heurstics in path splitting instead. That obvious didn't solve the unrolling issue. Maybe there is tuning to heurstics that can help if the trip count is constant.
[Bug c++/120890] virtual destructor on base class variable does not call derived class destructor when using [] destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120890 --- Comment #3 from Andrew Pinski --- I am 99% sure the behavior here is correct as you can't delete an array of derivedClass via a pointer of vBaseClass. It will always delete an array of vBaseClass.
[Bug target/120714] RISC-V: incorrect frame pointer CFA address for stack-clash protection loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714 Raphael M Zinsly changed: What|Removed |Added CC||rzinsly at ventanamicro dot com --- Comment #4 from Raphael M Zinsly --- I forgot about the residual in my patch, Alexey's patch is the correct fix and it works to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119944 as well. I haven't integrated my fix so we can drop it and apply https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687773.html instead.
[Bug target/120895] AVX data types default alignment is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895 --- Comment #3 from David C. Partridge --- (In reply to Andrew Pinski from comment #2) > (In reply to David C. Partridge from comment #1) > > This also applies to arm64 / Neon > > Do you have an example there because I think the problems are 2 different > issues. Sorry that was an assumption on my part. I will try the test case on macOS/Arm
[Bug tree-optimization/120886] SLP build does not consider operand swapping for commutative builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120886
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Last reconfirmed||2025-06-30
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
I see this in gimple-match-exports.cc in:
```
bool
commutative_ternary_op_p (code_helper code, tree type)
{
if (code.is_tree_code ())
return commutative_ternary_tree_code (tree_code (code));
auto cfn = combined_fn (code);
return commutative_ternary_fn_p (associated_internal_fn (cfn, type));
}
```
I wonder if we just do:
```
internal_fn fn = IFN_LAST;
if (gimple_call_internal_p (call))
fn = gimple_call_internal_fn (call);
else if (gimple_call_builtin_p (call, BUILT_IN_NORMAL)
fn = associated_internal_fn (as_combined_fn (DECL_FUNCTION_CODE
(gimple_call_fndecl (call)), type);
```
where type here is the lhs type.
[Bug c++/120894] New: Usage of std::pmr::polymorphic_allocator is not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120894
Bug ID: 120894
Summary: Usage of std::pmr::polymorphic_allocator is not
optimized out
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following program is not fully optimized (to 16-byte stack allocation + zeroing
and a call to 'use').
$ cat pmr.cpp
#include
#include
#ifdef WORKAROUND
namespace std::pmr {
[[gnu::pure]] memory_resource* get_default_resource() noexcept;
memory_resource::~memory_resource() {}
}
#endif
void use(const std::byte*) noexcept;
namespace
{
struct StaticResource final : public std::pmr::memory_resource
{
constexpr StaticResource(void* buffer, std::size_t buffer_size,
std::pmr::memory_resource* upstream = std::pmr::get_default_resource())
noexcept
: buffer{buffer}, buffer_left{buffer_size}, upstream{upstream}
{
}
void* do_allocate(std::size_t bytes, std::size_t alignment =
alignof(std::max_align_t)) override
{
if (auto ret = static_cast(std::align(alignment, bytes,
buffer, buffer_left)))
{
buffer_left -= bytes;
buffer = &ret[bytes];
return ret;
}
else
{
return upstream->allocate(bytes, alignment);
}
}
void do_deallocate(void*, std::size_t, std::size_t =
alignof(std::max_align_t)) override {}
bool do_is_equal(const memory_resource& other) const noexcept override {
return &other == this; }
private:
void* buffer;
std::size_t buffer_left;
std::pmr::memory_resource* upstream;
};
}
void test()
{
std::byte buf[16];
StaticResource res(&buf[0], sizeof(buf));
std::pmr::vector vec{16, &res};
use(vec.data());
}
$ g++ -std=c++20 -O3 pmr.cpp
Resulting assembly still have non-inlined calls to StaticResource::do_allocate,
unused call std::pmr::get_default_resource and invocation of no-op destructor
of std::pmr::memory_resource.
See here: https://godbolt.org/z/br57EaGhn
This can be improved somewhat by compilation with additional -DWORKAROUND flag,
but the calls to std::pmr::get_default_resource and StaticResource::do_allocate
are still there.
"test()":
sub rsp, 72
movqxmm0, QWORD PTR .LC0[rip]
lea rax, [rsp+16]
movqxmm1, rax
punpcklqdq xmm0, xmm1
movaps XMMWORD PTR [rsp], xmm0
call"std::pmr::get_default_resource()"
movdqa xmm0, XMMWORD PTR [rsp]
lea rdi, [rsp+32]
mov edx, 1
mov esi, 16
mov QWORD PTR [rsp+56], rax
movaps XMMWORD PTR [rsp+32], xmm0
mov QWORD PTR [rsp+48], 16
call"(anonymous namespace)::StaticResource::do_allocate(unsigned
long, unsigned long)"
pxorxmm0, xmm0
movups XMMWORD PTR [rax], xmm0
mov rdi, rax
call"use(std::byte const*)"
add rsp, 72
ret
clang with -O2 -DWORKAROUND does pretty good job:
test():
sub rsp, 24
xorps xmm0, xmm0
movaps xmmword ptr [rsp], xmm0
mov rdi, rsp
calluse(std::byte const*)@PLT
add rsp, 24
ret
Obviously marking the std::pmr::get_default_resource as 'pure' function is
wrong, so it would be great if we had an attribute that indicates functions
does
not modify program state, but cannot be reordered or CSE-d.
Also not sure why but ~memory_resource is not-defined inline, and most likely
we
cannot change it due to ABI so we would need another attribute that states the
function is a no-op.
[Bug tree-optimization/120885] SLP build does not consider operand swapping for conditional commutative operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120885 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-06-30 Status|UNCONFIRMED |NEW Severity|normal |enhancement Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106 --- Comment #9 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:b8d33869fda464b4582ebdff3ea3c720f23276b0 commit r16-1828-gb8d33869fda464b4582ebdff3ea3c720f23276b0 Author: Eric Botcazou Date: Mon Jun 30 18:57:27 2025 +0200 Ada: Provide fallback for GNATMAKE_FOR_BUILD Makefile variable The variable is set only at the top level. gcc/ada/ PR ada/120106 * Make-generated.in (GNATMAKE_FOR_BUILD): Define.
[Bug tree-optimization/120893] SLP costing costs vec_construct while forwprop turns it into vec_permute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120893 --- Comment #2 from Andrew Pinski --- I thought I had saw another place which had asked a similar question about this ...
[Bug c++/120896] New: __PRETTY_FUNCTION__ incorrect behavior (depends on instanciation order)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120896
Bug ID: 120896
Summary: __PRETTY_FUNCTION__ incorrect behavior (depends on
instanciation order)
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kelbonage at gmail dot com
Target Milestone: ---
https://godbolt.org/z/7zn8Echa5
```cpp
#include
template
struct S
{};
template
constexpr const char* n()
{
static auto name = __PRETTY_FUNCTION__;
return name;
}
int main()
{
std::println("{}", n>());
std::println("{}", n>());
}
```
Output:
constexpr const char* n() [with T = S<>]
constexpr const char* n() [with T = S<>]
But if line order changed:
std::println("{}", n>());
std::println("{}", n>());
Output:
constexpr const char* n() [with T = S]
constexpr const char* n() [with T = S]
[Bug c++/120895] New: AVX data types default alignment is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895 Bug ID: 120895 Summary: AVX data types default alignment is not correct Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david.partridge at perdrix dot co.uk Target Milestone: --- Created attachment 61767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61767&action=edit test case demonstrating problem The alignment *requirement* of __m512 is 64 bytes, and as of C++17, all elements of a std::vector<__m512> *must* be 64 byte aligned. The compiler is setting a required alignment of 16 bytes, not 64 bytes, but the type requires alignment of 64 bytes. This is NOT a case where it has better performance when aligned to 64 bytes. It is *necessary* to avoid SIGSEGV faults in the intrinsics. Similar comments apply to most other SIMD datatypes. Using g++ (Ubuntu 13.1.0-8ubuntu1~22.04) 13.1.0 The elements of such vectors aren't even aligned on 32 byte boundaries!!! System is x86_64 See attached file for test case When I run the test case I get: amonra@styx:~/m512$ ./a.out std::alignment_of_v<__m512> is: 16 alignof(__m512) is: 16 __alignof__(__m512) is: 64 Address of data%64: 0 Address1%64: 0 Address2%64: 16 a.out: m512.cpp:35: int main(int, char**): Assertion `align2 == 0' failed. Aborted (core dumped) amonra@styx:~/m512$ It all works fine on MSVC (VS2022) I know it is possible to work round this by using e.g.: #include : typedef std::vector > VectorType; but that should not be necessary. Please ensure that all SIMD data types are correctly aligned Thanks David
[Bug target/120888] [16 regression] promotion of unsigned char and short function arguments sign extends them since r16-170-ga670ebde3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Attachment #61763|0 |1 is obsolete|| --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Created attachment 61768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61768&action=edit gcc/testsuite/gcc.target/xtensa/abi_u8_arg.c
[Bug target/120897] New: __aeabi_d2h/__aeabi_d2h_alt function not implemented in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120897 Bug ID: 120897 Summary: __aeabi_d2h/__aeabi_d2h_alt function not implemented in libgcc Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: arm*-*-*eabi GCC defines its own set of functions for conversions between half float and float/double: set_conv_libfunc (trunc_optab, HFmode, SFmode, (arm_fp16_format == ARM_FP16_FORMAT_IEEE ? "__gnu_f2h_ieee" : "__gnu_f2h_alternative")); set_conv_libfunc (sext_optab, SFmode, HFmode, (arm_fp16_format == ARM_FP16_FORMAT_IEEE ? "__gnu_h2f_ieee" : "__gnu_h2f_alternative")); set_conv_libfunc (trunc_optab, HFmode, DFmode, (arm_fp16_format == ARM_FP16_FORMAT_IEEE ? "__gnu_d2h_ieee" : "__gnu_d2h_alternative")); The https://github.com/ARM-software/abi-aa/blob/c51addc3dc03e73a016a1e4edf25440bcac76431/rtabi32/rtabi32.rst#standard-conversions-between-floating-types Specifies the following functions: __aeabi_f2h/__aeabi_f2h_alt __aeabi_h2f/__aeabi_h2f_alt __aeabi_d2h/__aeabi_d2h_alt libgcc does not have an implemention for these though. This not implementation of these causes problems when compiling some code with LLVM and then linking with GCC. Since LLVM uses the ABI specified names while GCC has its own. A patch was posted to fix part of this but it looks like it never went in: https://gcc.gnu.org/legacy-ml/gcc-patches/2012-07/msg00902.html See https://reviews.llvm.org/D94557 also.
[Bug c++/106619] Inconsistent __PRETTY_FUNCTION__ output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106619 Andrew Pinski changed: What|Removed |Added CC||kelbonage at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 120896 has been marked as a duplicate of this bug. ***
[Bug c++/120896] __PRETTY_FUNCTION__ value depends on instanciation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120896 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 106619 ***
[Bug target/120888] [16 regression] promotion of unsigned char and short function arguments sign extends them since r16-170-ga670ebde3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|xtensa |xtensa, x86 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Last reconfirmed||2025-06-30
[Bug tree-optimization/113524] FAIL: gcc.dg/torture/pr113026-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for bogus messages, line 10)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113524
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #9 from Marek Polacek ---
I see this on ppc64le also, but with
FAIL: gcc.dg/torture/pr113026-2.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for bogus messages, line 9)
FAIL: gcc.dg/torture/pr113026-2.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for bogus messages, line 17)
FAIL: gcc.dg/torture/pr113026-2.c -O3 -g (test for bogus messages, line 9)
FAIL: gcc.dg/torture/pr113026-2.c -O3 -g (test for bogus messages, line 17)
The excess errors are:
pr113026-2.c: In function ‘foo1’:
pr113026-2.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | dst1[i] = src[i]; /* { dg-bogus "" } */
| ^~~~
pr113026-2.c:4:6: note: at offset 17 into destination object ‘dst1’ of size 17
4 | char dst1[17];
| ^~~~
pr113026-2.c:9:13: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
9 | dst1[i] = src[i]; /* { dg-bogus "" } */
| ^~~~
pr113026-2.c:4:6: note: at offset 18 into destination object ‘dst1’ of size 17
4 | char dst1[17];
| ^~~~
[Bug target/120627] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-2186-g9d8ef2711df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120627 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Jeffrey A. Law --- Same root cause. *** This bug has been marked as a duplicate of bug 120242 ***
[Bug target/120242] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-9239-g4d7a634f6d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242 --- Comment #5 from Jeffrey A. Law --- *** Bug 120627 has been marked as a duplicate of this bug. ***
[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 --- Comment #3 from Jerry DeLisle --- I have not had much time to finish this one. I will try to get to it.
[Bug rtl-optimization/120242] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-9239-g4d7a634f6d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30 14:38:33 2025 -0600
[committed] [PR rtl-optimization/120242] Fix SUBREG_PROMOTED_VAR_P after
ext-dce's actions
I've gone back and forth of these problems multiple times. We have two
passes,
ext-dce and combine which eliminate extensions using totally different
mechanisms.
ext-dce looks for cases where the state of upper bits in an object aren't
observable and if they aren't observable, then eliminates extensions which
set
those bits.
combine looks for cases where we know the state of the upper bits and can
prove
an extension is just setting those bits to their prior value. Combine also
looks for cases where the precise extension isn't really important, just
the
knowledge that the upper bits are zero or sign extended from a narrower
mode
is needed.
Combine relies heavily on the SUBREG_PROMOTED_VAR state to do its job. If
the
actions of ext-dce (or any other pass for that matter) make
SUBREG_PROMOTED_VAR's state inconsistent with combine's expectations, then
combine can end up generating incorrect code.
--
When ext-dce eliminates an extension and turns it into a subreg copy
(without
any known SUBREG_PROMOTED_VAR state). Since we can no longer guarantee the
destination object has any known extension state, we scurry around and wipe
SUBREG_PROMOTED_VAR state for the destination object.
That's fine and dandy, but ultimately insufficient. Consider if the
destination of the optimized extension was used as a source in a simple
copy
insn. Furthermore assume that the destination of that copy is used within
a
SUBREG expression with SUBREG_PROMOTED_VAR set. ext-dce's actions have
clobbered the SUBREG_PROMOTED_VAR state on the destination of that copy,
albeit
indirectly.
This patch addresses this problem by taking the set of pseudos directly
impacted by ext-dce's actions and expands that set by building a transitive
closure for pseudos connected via copies. We then scurry around finding
SUBREG_PROMOTED_VAR state to wipe for everything in that expanded set of
pseudos. Voila, everything just works.
--
The other approach here would be to further expand the liveness sets inside
ext-dce. That's a simpler path forward, but ultimately regresses the
quality
of codes we do care about.
One good piece of news is that with the transitive closure bits in place,
we
can eliminate a bit of the live set expansion we had in place for
SUBREG_PROMOTED_VAR objects.
--
So let's take one case of the 5 that have been reported.
In ext-dce we have this insn:
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
There are reachable uses of (reg 134):
> (insn 49 47 52 6 (set (mem/c:HI (lo_sum:DI (reg/f:DI 186)
> (symbol_ref:DI ("al") [flags 0x86] )) [2 al+0 S2 A16])
> (subreg/s/v:HI (reg:DI 134 [ al_lsm.9 ]) 0)) 279
{*movhi_internal}
> (expr_list:REG_DEAD (reg/f:DI 186)
> (nil)))Obviously safe if we were to remove the extension.
> (insn 52 49 53 6 (set (reg:DI 176)
> (and:DI (reg:DI 134 [ al_lsm.9 ])
> (const_int 5 [0x5]))) "j.c":21:12 106 {*anddi3}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 53 52 56 6 (set (reg:SI 177 [ _8 ])
> (zero_extend:SI (subreg:HI (reg:DI 176) 0))) "j.c":21:12 551
{*zero_extendhisi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 176)
> (nil))) Safe to remove the extension as we only read the low 16
bits from the destination register (reg 176) in insn 53.
> (insn 27 26 29 3 (set (reg:DI 162)
> (sign_extend:DI (plus:SI (subreg/s/v:SI (reg:DI 134 [ al_lsm.9 ])
0)
> (const_int 1 [0x1] "j.c":17:17 8 {addsi3_extended}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
Again, not as obvious as the first case, but we only read the low 16 bits
from
(reg 162) in insn 29. So those upper bits in (reg 134) don't matter.
> (insn 26 92 27 3 (set (reg:DI 144 [ ivtmp.17 ])
> (reg:DI 134 [ al_lsm.9 ])) 277 {*movdi_64bit}
> (nil))
> (insn 30 29 31 3 (set (reg:DI 135 [ al.2_3 ])
> (sig
[Bug rtl-optimization/120627] [15/16 regression] RISC-V: Miscompile at -O[23] since r15-2186-g9d8ef2711df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120627
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30 14:38:33 2025 -0600
[committed] [PR rtl-optimization/120242] Fix SUBREG_PROMOTED_VAR_P after
ext-dce's actions
I've gone back and forth of these problems multiple times. We have two
passes,
ext-dce and combine which eliminate extensions using totally different
mechanisms.
ext-dce looks for cases where the state of upper bits in an object aren't
observable and if they aren't observable, then eliminates extensions which
set
those bits.
combine looks for cases where we know the state of the upper bits and can
prove
an extension is just setting those bits to their prior value. Combine also
looks for cases where the precise extension isn't really important, just
the
knowledge that the upper bits are zero or sign extended from a narrower
mode
is needed.
Combine relies heavily on the SUBREG_PROMOTED_VAR state to do its job. If
the
actions of ext-dce (or any other pass for that matter) make
SUBREG_PROMOTED_VAR's state inconsistent with combine's expectations, then
combine can end up generating incorrect code.
--
When ext-dce eliminates an extension and turns it into a subreg copy
(without
any known SUBREG_PROMOTED_VAR state). Since we can no longer guarantee the
destination object has any known extension state, we scurry around and wipe
SUBREG_PROMOTED_VAR state for the destination object.
That's fine and dandy, but ultimately insufficient. Consider if the
destination of the optimized extension was used as a source in a simple
copy
insn. Furthermore assume that the destination of that copy is used within
a
SUBREG expression with SUBREG_PROMOTED_VAR set. ext-dce's actions have
clobbered the SUBREG_PROMOTED_VAR state on the destination of that copy,
albeit
indirectly.
This patch addresses this problem by taking the set of pseudos directly
impacted by ext-dce's actions and expands that set by building a transitive
closure for pseudos connected via copies. We then scurry around finding
SUBREG_PROMOTED_VAR state to wipe for everything in that expanded set of
pseudos. Voila, everything just works.
--
The other approach here would be to further expand the liveness sets inside
ext-dce. That's a simpler path forward, but ultimately regresses the
quality
of codes we do care about.
One good piece of news is that with the transitive closure bits in place,
we
can eliminate a bit of the live set expansion we had in place for
SUBREG_PROMOTED_VAR objects.
--
So let's take one case of the 5 that have been reported.
In ext-dce we have this insn:
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
There are reachable uses of (reg 134):
> (insn 49 47 52 6 (set (mem/c:HI (lo_sum:DI (reg/f:DI 186)
> (symbol_ref:DI ("al") [flags 0x86] )) [2 al+0 S2 A16])
> (subreg/s/v:HI (reg:DI 134 [ al_lsm.9 ]) 0)) 279
{*movhi_internal}
> (expr_list:REG_DEAD (reg/f:DI 186)
> (nil)))Obviously safe if we were to remove the extension.
> (insn 52 49 53 6 (set (reg:DI 176)
> (and:DI (reg:DI 134 [ al_lsm.9 ])
> (const_int 5 [0x5]))) "j.c":21:12 106 {*anddi3}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 53 52 56 6 (set (reg:SI 177 [ _8 ])
> (zero_extend:SI (subreg:HI (reg:DI 176) 0))) "j.c":21:12 551
{*zero_extendhisi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 176)
> (nil))) Safe to remove the extension as we only read the low 16
bits from the destination register (reg 176) in insn 53.
> (insn 27 26 29 3 (set (reg:DI 162)
> (sign_extend:DI (plus:SI (subreg/s/v:SI (reg:DI 134 [ al_lsm.9 ])
0)
> (const_int 1 [0x1] "j.c":17:17 8 {addsi3_extended}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
Again, not as obvious as the first case, but we only read the low 16 bits
from
(reg 162) in insn 29. So those upper bits in (reg 134) don't matter.
> (insn 26 92 27 3 (set (reg:DI 144 [ ivtmp.17 ])
> (reg:DI 134 [ al_lsm.9 ])) 277 {*movdi_64bit}
> (nil))
> (insn 30 29 31 3 (set (reg:DI 135 [ al.2_3 ])
> (sig
[Bug rtl-optimization/120813] [15/16 Regression] RISC-V: Miscompile at -O[23] since r15-9239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120813
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30 14:38:33 2025 -0600
[committed] [PR rtl-optimization/120242] Fix SUBREG_PROMOTED_VAR_P after
ext-dce's actions
I've gone back and forth of these problems multiple times. We have two
passes,
ext-dce and combine which eliminate extensions using totally different
mechanisms.
ext-dce looks for cases where the state of upper bits in an object aren't
observable and if they aren't observable, then eliminates extensions which
set
those bits.
combine looks for cases where we know the state of the upper bits and can
prove
an extension is just setting those bits to their prior value. Combine also
looks for cases where the precise extension isn't really important, just
the
knowledge that the upper bits are zero or sign extended from a narrower
mode
is needed.
Combine relies heavily on the SUBREG_PROMOTED_VAR state to do its job. If
the
actions of ext-dce (or any other pass for that matter) make
SUBREG_PROMOTED_VAR's state inconsistent with combine's expectations, then
combine can end up generating incorrect code.
--
When ext-dce eliminates an extension and turns it into a subreg copy
(without
any known SUBREG_PROMOTED_VAR state). Since we can no longer guarantee the
destination object has any known extension state, we scurry around and wipe
SUBREG_PROMOTED_VAR state for the destination object.
That's fine and dandy, but ultimately insufficient. Consider if the
destination of the optimized extension was used as a source in a simple
copy
insn. Furthermore assume that the destination of that copy is used within
a
SUBREG expression with SUBREG_PROMOTED_VAR set. ext-dce's actions have
clobbered the SUBREG_PROMOTED_VAR state on the destination of that copy,
albeit
indirectly.
This patch addresses this problem by taking the set of pseudos directly
impacted by ext-dce's actions and expands that set by building a transitive
closure for pseudos connected via copies. We then scurry around finding
SUBREG_PROMOTED_VAR state to wipe for everything in that expanded set of
pseudos. Voila, everything just works.
--
The other approach here would be to further expand the liveness sets inside
ext-dce. That's a simpler path forward, but ultimately regresses the
quality
of codes we do care about.
One good piece of news is that with the transitive closure bits in place,
we
can eliminate a bit of the live set expansion we had in place for
SUBREG_PROMOTED_VAR objects.
--
So let's take one case of the 5 that have been reported.
In ext-dce we have this insn:
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
There are reachable uses of (reg 134):
> (insn 49 47 52 6 (set (mem/c:HI (lo_sum:DI (reg/f:DI 186)
> (symbol_ref:DI ("al") [flags 0x86] )) [2 al+0 S2 A16])
> (subreg/s/v:HI (reg:DI 134 [ al_lsm.9 ]) 0)) 279
{*movhi_internal}
> (expr_list:REG_DEAD (reg/f:DI 186)
> (nil)))Obviously safe if we were to remove the extension.
> (insn 52 49 53 6 (set (reg:DI 176)
> (and:DI (reg:DI 134 [ al_lsm.9 ])
> (const_int 5 [0x5]))) "j.c":21:12 106 {*anddi3}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 53 52 56 6 (set (reg:SI 177 [ _8 ])
> (zero_extend:SI (subreg:HI (reg:DI 176) 0))) "j.c":21:12 551
{*zero_extendhisi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 176)
> (nil))) Safe to remove the extension as we only read the low 16
bits from the destination register (reg 176) in insn 53.
> (insn 27 26 29 3 (set (reg:DI 162)
> (sign_extend:DI (plus:SI (subreg/s/v:SI (reg:DI 134 [ al_lsm.9 ])
0)
> (const_int 1 [0x1] "j.c":17:17 8 {addsi3_extended}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
Again, not as obvious as the first case, but we only read the low 16 bits
from
(reg 162) in insn 29. So those upper bits in (reg 134) don't matter.
> (insn 26 92 27 3 (set (reg:DI 144 [ ivtmp.17 ])
> (reg:DI 134 [ al_lsm.9 ])) 277 {*movdi_64bit}
> (nil))
> (insn 30 29 31 3 (set (reg:DI 135 [ al.2_3 ])
> (sig
[Bug rtl-optimization/120736] [15/16 Regression] RISC-V: Miscompile at -O[23] since r15-5375-gbeec291225b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120736
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30 14:38:33 2025 -0600
[committed] [PR rtl-optimization/120242] Fix SUBREG_PROMOTED_VAR_P after
ext-dce's actions
I've gone back and forth of these problems multiple times. We have two
passes,
ext-dce and combine which eliminate extensions using totally different
mechanisms.
ext-dce looks for cases where the state of upper bits in an object aren't
observable and if they aren't observable, then eliminates extensions which
set
those bits.
combine looks for cases where we know the state of the upper bits and can
prove
an extension is just setting those bits to their prior value. Combine also
looks for cases where the precise extension isn't really important, just
the
knowledge that the upper bits are zero or sign extended from a narrower
mode
is needed.
Combine relies heavily on the SUBREG_PROMOTED_VAR state to do its job. If
the
actions of ext-dce (or any other pass for that matter) make
SUBREG_PROMOTED_VAR's state inconsistent with combine's expectations, then
combine can end up generating incorrect code.
--
When ext-dce eliminates an extension and turns it into a subreg copy
(without
any known SUBREG_PROMOTED_VAR state). Since we can no longer guarantee the
destination object has any known extension state, we scurry around and wipe
SUBREG_PROMOTED_VAR state for the destination object.
That's fine and dandy, but ultimately insufficient. Consider if the
destination of the optimized extension was used as a source in a simple
copy
insn. Furthermore assume that the destination of that copy is used within
a
SUBREG expression with SUBREG_PROMOTED_VAR set. ext-dce's actions have
clobbered the SUBREG_PROMOTED_VAR state on the destination of that copy,
albeit
indirectly.
This patch addresses this problem by taking the set of pseudos directly
impacted by ext-dce's actions and expands that set by building a transitive
closure for pseudos connected via copies. We then scurry around finding
SUBREG_PROMOTED_VAR state to wipe for everything in that expanded set of
pseudos. Voila, everything just works.
--
The other approach here would be to further expand the liveness sets inside
ext-dce. That's a simpler path forward, but ultimately regresses the
quality
of codes we do care about.
One good piece of news is that with the transitive closure bits in place,
we
can eliminate a bit of the live set expansion we had in place for
SUBREG_PROMOTED_VAR objects.
--
So let's take one case of the 5 that have been reported.
In ext-dce we have this insn:
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
There are reachable uses of (reg 134):
> (insn 49 47 52 6 (set (mem/c:HI (lo_sum:DI (reg/f:DI 186)
> (symbol_ref:DI ("al") [flags 0x86] )) [2 al+0 S2 A16])
> (subreg/s/v:HI (reg:DI 134 [ al_lsm.9 ]) 0)) 279
{*movhi_internal}
> (expr_list:REG_DEAD (reg/f:DI 186)
> (nil)))Obviously safe if we were to remove the extension.
> (insn 52 49 53 6 (set (reg:DI 176)
> (and:DI (reg:DI 134 [ al_lsm.9 ])
> (const_int 5 [0x5]))) "j.c":21:12 106 {*anddi3}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 53 52 56 6 (set (reg:SI 177 [ _8 ])
> (zero_extend:SI (subreg:HI (reg:DI 176) 0))) "j.c":21:12 551
{*zero_extendhisi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 176)
> (nil))) Safe to remove the extension as we only read the low 16
bits from the destination register (reg 176) in insn 53.
> (insn 27 26 29 3 (set (reg:DI 162)
> (sign_extend:DI (plus:SI (subreg/s/v:SI (reg:DI 134 [ al_lsm.9 ])
0)
> (const_int 1 [0x1] "j.c":17:17 8 {addsi3_extended}
> (expr_list:REG_DEAD (reg:DI 134 [ al_lsm.9 ])
> (nil)))
> (insn 29 27 30 3 (set (reg:DI 134 [ al_lsm.9 ])
> (zero_extend:DI (subreg:HI (reg:DI 162) 0))) "j.c":17:17 552
{*zero_extendhidi2_bitmanip}
> (expr_list:REG_DEAD (reg:DI 162)
> (nil)))
Again, not as obvious as the first case, but we only read the low 16 bits
from
(reg 162) in insn 29. So those upper bits in (reg 134) don't matter.
> (insn 26 92 27 3 (set (reg:DI 144 [ ivtmp.17 ])
> (reg:DI 134 [ al_lsm.9 ])) 277 {*movdi_64bit}
> (nil))
> (insn 30 29 31 3 (set (reg:DI 135 [ al.2_3 ])
> (sig
[Bug c/120898] New: ICE at -O2 calling function with old-style definition taking a VLA parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120898
Bug ID: 120898
Summary: ICE at -O2 calling function with old-style definition
taking a VLA parameter
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stephenheumann at gmail dot com
Target Milestone: ---
Compiling this with -O2:
```
int foo(a,b)
int a;
int b[][a];
{
return sizeof(b[1]);
}
int main(void) {
int c[4][4];
foo(4,c);
}
```
gives the following:
: In function 'foo':
:1:5: warning: old-style function definition [-Wold-style-definition]
1 | int foo(a,b)
| ^~~
during GIMPLE pass: einline
: In function 'main':
:10:9: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.cc:355
10 | foo(4,c);
| ^~~~
0x20bd0f5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x20ce646 internal_error(char const*, ...)
???:0
0x7a56c6 fancy_abort(char const*, int, char const*)
???:0
0xe8f0bf copy_tree_body_r(tree_node**, int*, void*)
???:0
0x11391b2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x1139391 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xe8a88b remap_type(tree_node*, copy_body_data*)
???:0
0xe8a88b remap_type(tree_node*, copy_body_data*)
???:0
0xe97d59 optimize_inline_calls(tree_node*)
???:0
0x1f0f07e early_inliner(function*)
???:0
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/120888] [16 regression] promotion of unsigned char and short function arguments sign extends them since r16-170-ga670ebde3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888 --- Comment #3 from H.J. Lu --- Created attachment 61769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61769&action=edit A patch Please try this.
[Bug cobol/120779] HIGH-VALUE / LOW-VALUE not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120779 --- Comment #2 from GCC Commits --- The master branch has been updated by James K. Lowden : https://gcc.gnu.org/g:612c4c104ac0c2726d2de27f350040ad5f8d5776 commit r16-1836-g612c4c104ac0c2726d2de27f350040ad5f8d5776 Author: James K. Lowden Date: Mon Jun 30 16:51:49 2025 -0400 cobol: Revise diagnostic linemap management. Update linemap filename before location in both parsers. Rely on parser to update linemap. Lexer maintains location. Various small syntax corrections and extensions. PR cobol/120772 PR cobol/120779 PR cobol/120790 PR cobol/120791 PR cobol/120794 gcc/cobol/ChangeLog: * gcobc: Supply -fPIC for shared objects. * genapi.cc (linemap_add): Delete empty macro. (parser_enter_file): Do not call linemap_add. (parser_leave_file): Same. * gengen.cc (location_from_lineno): Remove function. * lexio.cc (parse_replacing_term): Allow empty term. (cdftext::process_file): Always append to output. (cdftext::segment_line): Output #line directives. * lexio.h (struct span_t): Count lines in span. * parse.y: Revamp REPOSITORY, and minor syntax extensions. * parse_ante.h (input_file_status_notify): Update linemap filename before location. (intrinsic_token_of): Declare. (parser_move_carefully): Support MOVE pointer. * parse_util.h (intrinsic_token_of): New function. * scan.l: New EOF logic, accept NOT=, own yylloc and yylineno. * scan_ante.h (class enter_leave_t): Do not store newline count. (cdf_location_set): Remove declaration. (ydfltype_of): New function. (update_location): Accept location parameter. (reset_location): New function. (YY_USER_ACTION): Use update_location(). (YY_USER_INIT): Update CDF location. (verify_ws): New function. (wait_for_the_child): Removed. * symbols.h (cobol_fileline_set): return line number. * util.cc (valid_move): Use range-based for loop. (struct input_file_t): Remove line_map pointer. (class unique_stack): New peek() member function. (cobol_lineno_save): Rename to overload cobol_lineno(). (cobol_lineno): Replaces cobol_lineno_save(). (cobol_filename): Return void. (location_from_lineno): New function used by genapi.cc. (cdf_location_set): Remove. (matched_length): No change. (cobol_fileline_set): Return line number. (fisspace): Remove extra semicolon. (fisprint): Same. * util.h (cobol_filename_restore): Return void. (cobol_lineno_save): Remove declaration. (cobol_lineno): Declare.
