[Bug libgomp/121009] [libgomp]fwrite return value ignored in libgomp/error.c causes build failure with -Werror=unused-result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121009 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Glibc was fixed 13 years ago. https://sourceware.org/bugzilla/show_bug.cgi?id=11959 So closing as won't fix.
[Bug c++/121010] New: Error on lambda in fold expression in lambda capturing pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121010
Bug ID: 121010
Summary: Error on lambda in fold expression in lambda capturing
pack
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eczbek.void at gmail dot com
Target Milestone: ---
https://godbolt.org/z/TW4T33shG
```
void f(auto... x) {
[x...] {
(..., [x] {});
};
}
int main() {}
```
```
: In lambda function:
:3:25: error: parameter packs not expanded with '...':
[-Wtemplate-body]
3 | (..., [x] {});
| ^
:3:25: note: 'x'
Compiler returned: 1
```
Works in 10.5
[Bug tree-optimization/121011] New: Bad optimizations by GCC 15.0.1 from Fedora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121011
Bug ID: 121011
Summary: Bad optimizations by GCC 15.0.1 from Fedora
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
void xorbuf_3(void *dst, const void *src1, const void *src2, unsigned count) {
unsigned char *d = dst;
const unsigned char *s1 = src1;
const unsigned char *s2 = src2;
#define longcount ~(unsigned)(sizeof(long)-1)
while (count & longcount) {
*(long*)d = *(long*)s1 ^ *(long*)s2;
count -= sizeof(long);
d += sizeof(long);
s1 += sizeof(long);
s2 += sizeof(long);
}
while (count--)
*d++ = *s1++ ^ *s2++;
}
$ gcc -Os -S bitops.c
The result is rather bad.
.file "bitops.c"
.text
.globl xorbuf_3
.type xorbuf_3, @function
xorbuf_3:
.LFB0:
.cfi_startproc
xorl%eax, %eax
.L2:
movl%ecx, %r8d
subl%eax, %r8d
cmpl$7, %r8d
jbe .L7
movq(%rsi,%rax), %r8
xorq(%rdx,%rax), %r8
movq%r8, (%rdi,%rax)
addq$8, %rax
jmp .L2
.L7:
movl%ecx, %eax
shrl$3, %eax
leal0(,%rax,8), %r8d
# 3 insns above: bold effort to calculate the number of bytes we processed. too
bad it was already present in %rax...
imull $-8, %eax, %eax
addq%r8, %rdx
addq%r8, %rsi
addq%r8, %rdi
leal(%rax,%rcx), %r8d
# subtracting (%rax * 8) from %rcx by... %rcx += %rax * -8! With IMUL!! Even
though we happen to have a ready (%rax * 8) result in %r8 and could just "subq
%r8, %rcx"!!!
xorl%eax, %eax
.L4:
cmpq%r8, %rax
je .L8
movb(%rsi,%rax), %cl
xorb(%rdx,%rax), %cl
movb%cl, (%rdi,%rax)
incq%rax
jmp .L4
.L8:
ret
.cfi_endproc
.LFE0:
.size xorbuf_3, .-xorbuf_3
.ident "GCC: (GNU) 15.0.1 20250418 (Red Hat 15.0.1-0)"
.section.note.GNU-stack,"",@progbits
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,cobol,lto
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-15.0.1-build/gcc-15.0.1-20250418/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250418 (Red Hat 15.0.1-0) (GCC)
[Bug tree-optimization/120996] [16 regression][AArch64] 15% regression in microBUDE since r16-1108-gb7960a3f966a0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120996 Dhruv Chawla changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109154 --- Comment #4 from Dhruv Chawla --- Also added https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154, which is a previous case where a similar issue occurred.
[Bug c++/121012] New: Error on lambda with auto parameter as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012
Bug ID: 121012
Summary: Error on lambda with auto parameter as template
argument
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eczbek.void at gmail dot com
Target Milestone: ---
https://godbolt.org/z/nfeh3Tbez
```
template int x;
int main() {
x<[](auto) {}>;
}
```
```
: In function 'int main()':
:4:14: error: use of 'auto' in template argument
[-Wabbreviated-auto-in-template-arg]
4 | x<[](auto) {}>;
| ^~~~
Compiler returned: 1
```
This works in 15.1
[Bug other/120905] Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris 10 SPARC (linker error?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905 --- Comment #17 from TCH --- Okay, GCC6 now compiles and the resulting compiler can compile too. So, this is the right way to do: untxz gcc-6.5.0.tar.xz cd gcc-6.5.0 patch -p0 < ../gcc6_solaris10.patch cd .. mkdir gcc6 cd gcc6 export LD_LIBRARY_PATH="$LD_LIBRARY_PATH"':/opt/csw/lib/' ../gcc-6.5.0/configure --prefix=/opt/gcc6 --build=sparc-sun-solaris2.10 --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --disable-nls --enable-languages=c,c++,objc --with-gmp=/opt/csw --with-mpfr=/opt/csw --with-mpc=/opt/csw make make install And then, when using the compiler: export LD_LIBRARY_PATH="$LD_LIBRARY_PATH"':/opt/csw/lib/' export PATH='/opt/gcc6/bin:'"$PATH" gcc whatever.c It may be better, if the exporting lines are put into '.profile'. Thanks again for the help.
[Bug libgomp/121009] New: [libgomp]fwrite return value ignored in libgomp/error.c causes build failure with -Werror=unused-result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121009 Bug ID: 121009 Summary: [libgomp]fwrite return value ignored in libgomp/error.c causes build failure with -Werror=unused-result Product: gcc Version: 14.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: dongjianqiang2 at huawei dot com CC: jakub at gcc dot gnu.org Target Milestone: --- When building GCC/libgomp with -Werror=unused-result, the build fails due to fwrite() return values being ignored in libgomp/error.c. This happens because some versions of glibc declare fwrite() with __attribute__((__warn_unused_result__)). https://github.com/bminor/glibc/blob/glibc-2.8/libio/stdio.h#L685 This makes the build fail with: gcc/libgomp/error.c: In function 'GOMP_warning': gcc/libgomp/error.c:101:7: error: ignoring return value of 'fwrite', declared with attribute warn_unused_result [-Werror=unused-result] fwrite (msg, 1, msglen, stderr); ^~~ gcc/libgomp/error.c: In function 'GOMP_error': gcc/libgomp/error.c:116:7: error: ignoring return value of 'fwrite' declared with attribute 'warn_unused_result' [-Werror=unused-result] fwrite (msg, 1, msglen, stderr); ^~~
[Bug c++/121008] New: Error on 'this' inside noexcept specifier of lambda capturing 'this' inside noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008
Bug ID: 121008
Summary: Error on 'this' inside noexcept specifier of lambda
capturing 'this' inside noexcept specifier
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eczbek.void at gmail dot com
Target Milestone: ---
https://godbolt.org/z/PEfMv78fd
```
struct A {
void f() noexcept(noexcept([this]() noexcept(noexcept(this)) {})) {}
};
int main() {}
```
```
:2:63: error: invalid use of 'this' at top level
2 | void f() noexcept(noexcept([this]() noexcept(noexcept(this))
{})) {}
| ^~~~
Compiler returned: 1
```
This works in 15.1
[Bug libgomp/121009] [libgomp]fwrite return value ignored in libgomp/error.c causes build failure with -Werror=unused-result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121009 --- Comment #2 from John Dong --- (In reply to Andrew Pinski from comment #1) > Glibc was fixed 13 years ago. > https://sourceware.org/bugzilla/show_bug.cgi?id=11959 > > So closing as won't fix. Thank you, Andrew, for the quick clarification and the reference to the glibc bug.
[Bug tree-optimization/121011] Bad optimizations by GCC 15.0.1 from Fedora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121011 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-07-09 Component|target |tree-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68008 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- -fno-tree-scev-cprop is a workaround. Note I am 90% sure this code will also run into aliasing problems and alignment issues but with the function by itself there is no way to tell.
[Bug tree-optimization/120996] [16 regression][AArch64] 15% regression in microBUDE since r16-1108-gb7960a3f966a0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120996 --- Comment #5 from Andrew Pinski --- (In reply to Dhruv Chawla from comment #4) > Also added https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154, which is a > previous case where a similar issue occurred. With almost exactly the same code even.
[Bug c++/121012] [16 Regression] Error on lambda with auto parameter as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012 Andrew Pinski changed: What|Removed |Added Summary|Error on lambda with auto |[16 Regression] Error on |parameter as template |lambda with auto parameter |argument|as template argument Known to work||15.1.0 Target Milestone|--- |16.0 Known to fail||16.0
[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917 --- Comment #27 from Andrew Pinski --- (In reply to GCC Commits from comment #19) > The trunk branch has been updated by Jason Merrill : > > https://gcc.gnu.org/g:8abc2e66be72a34db8c3cc97e4fbd90b7abae61d > > commit r16-2065-g8abc2e66be72a34db8c3cc97e4fbd90b7abae61d I think this commit caused PR 121012 .
[Bug c++/121012] [16 Regression] Error on lambda with auto parameter as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-09 See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=117518|a/show_bug.cgi?id=120917 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I am 99% sure this was introduced by r16-2065 . Adding -Wno-abbreviated-auto-in-template-arg allows the testcase to work.
[Bug c++/121010] Error on lambda in fold expression in lambda capturing pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121010 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Yes this is a dup. *** This bug has been marked as a duplicate of bug 103876 ***
[Bug c++/103876] Parameter pack not expanded in lambda within static_assert in a fold-expression of a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103876 Andrew Pinski changed: What|Removed |Added CC||eczbek.void at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 121010 has been marked as a duplicate of this bug. ***
[Bug libstdc++/118341] Missing -D_GLIBCXX_ASSERTIONS checks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- *** Bug 120364 has been marked as a duplicate of this bug. ***
[Bug libstdc++/118341] Missing -D_GLIBCXX_ASSERTIONS checks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341 Jonathan Wakely changed: What|Removed |Added Blocks||110339 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > *** Bug 120364 has been marked as a duplicate of this bug. *** And C++26 requires these to be checked: constexpr bool operator[](size_t pos) const; Hardened preconditions: pos < size() is true. constexpr bitset::reference operator[](size_t pos); Hardened preconditions: pos < size() is true. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 [Bug 110339] Implement C++26 library features
[Bug libstdc++/120997] New: std::span::subspan returns initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
Bug ID: 120997
Summary: std::span::subspan returns
initializer list
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: yuhan at y2research dot com
Target Milestone: ---
```
#include
#include
#include
auto main() -> int {
std::array data{};
std::span data_view(data.data(), 5);
std::cout << "data_view.data():\t" << data_view.data() << '\n';
std::cout << "data_view.size():\t" << data_view.size() << '\n';
std::cout << "\n";
std::span data_view_2 = data_view.subspan(0, 5);
std::cout << "data_view_2.data():\t" << data_view_2.data() << '\n';
std::cout << "data_view_2.size():\t" << data_view_2.size() << '\n';
std::cout << "\n";
return 0;
}
```
(Godbolt: https://godbolt.org/z/1Ta4rrsb5 )
The above code when compiled with "-std=c++26 -Wall -Wextra" prints
```
data_view.data(): 0x7ffc7ca19b9b
data_view.size(): 5
data_view_2.data(): 0x7ffc7ca19b3e
data_view_2.size(): 2
```
Namely, `data_view_2` is a size 2 span even though it was created with
`data_view.subspan(0, 5)`. It seems like the return object in `subspan` (C++26)
is being falsely interpreted as an initializer list rather than a pointer and
size, causing `data_view_2` to point to the initializer list on stack (which is
immediately invalidated upon return).
This bug does not occur on C++23 (-std=c++23). It also seems to only occur for
`const bool` (not `bool`, not `int`, etc.).
[Bug libstdc++/119820] Formatting ranges make a subrange via ranges::subrange (__first, __first + __n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820 Tomasz Kamiński changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-07-08 --- Comment #2 from Tomasz Kamiński --- I agree that this is a bug, but as you mention, is a lower priority one. Please post if you will find a different test case.
[Bug libstdc++/110339] Implement C++26 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 Bug 110339 depends on bug 120364, which changed state. Bug 120364 Summary: std::bitset is missing hardened preconditions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120364 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug cobol/120998] New: [16 regression] unable to bootstrap with cobol and without --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120998 Bug ID: 120998 Summary: [16 regression] unable to bootstrap with cobol and without --disable-werror Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com Target Milestone: --- Since sometime between 20250615 (last good snapshot) and 20250622 (first bad snapshot) I can no longer bootstrap gcc-16 with cobol in --enable-languages. With today's master I get: /mnt/scratch/objdir16b/./prev-gcc/xg++ -B/mnt/scratch/objdir16b/./prev-gcc/ -B/mnt/scratch/install16/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir16b/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir16b/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir16b/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/mnt/scratch/objdir16b/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/mnt/scratch/other/mikpe-gcc.git/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir16b/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir16b/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -Icobol -I/mnt/scratch/other/mikpe-gcc.git/gcc -I/mnt/scratch/other/mikpe-gcc.git/gcc/cobol -I/mnt/scratch/other/mikpe-gcc.git/gcc/../include -I/mnt/scratch/other/mikpe-gcc.git/gcc/../libcpp/include -I/mnt/scratch/other/mikpe-gcc.git/gcc/../libcody -I/home/mikpe/pkgs/linux-x86_64/gmp-6.3.0/include -I/home/mikpe/pkgs/linux-x86_64/mpfr-4.2.2/include -I/home/mikpe/pkgs/linux-x86_64/mpc-1.3.1/include -I/mnt/scratch/other/mikpe-gcc.git/gcc/../libdecnumber -I/mnt/scratch/other/mikpe-gcc.git/gcc/../libdecnumber/bid -I../libdecnumber -I/mnt/scratch/other/mikpe-gcc.git/gcc/../libbacktrace -o cobol/util.o -MT cobol/util.o -MMD -MP -MF cobol/.deps/util.TPo /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc: In function 'void ydferror(const char*, ...)': /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc:1985:41: error: function 'void ydferror(const char*, ...)' might be a candidate for 'gcc_tdiag' format attribute [-Werror=suggest-attribute=format] 1985 | bool ret = global_dc->diagnostic_impl (&richloc, nullptr, option_zero, | ~~~^~~~ 1986 | gmsgid, &ap, DK_ERROR); | ~~ /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc: In function 'void error_msg(const YYLTYPE&, const char*, ...)': /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc:2043:41: error: function 'void error_msg(const YYLTYPE&, const char*, ...)' might be a candidate for 'gcc_tdiag' format attribute [-Werror=suggest-attribute=format] 2043 | bool ret = global_dc->diagnostic_impl (&richloc, nullptr, option_zero,\ | ~~~^ 2044 | gmsgid, &ap, DK_ERROR); \ | ~~ /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc:2050:3: note: in expansion of macro 'ERROR_MSG_BODY' 2050 | ERROR_MSG_BODY | ^~ /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc: In function 'void error_msg(const YDFLTYPE&, const char*, ...)': /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc:2043:41: error: function 'void error_msg(const YDFLTYPE&, const char*, ...)' might be a candidate for 'gcc_tdiag' format attribute [-Werror=suggest-attribute=format] 2043 | bool ret = global_dc->diagnostic_impl (&richloc, nullptr, option_zero,\ | ~~~^ 2044 | gmsgid, &ap, DK_ERROR); \ | ~~ /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc:2057:3: note: in expansion of macro 'ERROR_MSG_BODY' 2057 | ERROR_MSG_BODY | ^~ /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc: In function 'void yyerror(const char*, ...)': /mnt/scratch/other/mikpe-gcc.git/gcc/cobol/util.cc:2069:41: error: function 'void yyerror(const char*, ...)' might be a candidate for 'gcc_tdiag' format attribute [-Werror=suggest-attribute=format] 2069 | bool ret = global_dc->diagnostic_impl (&richl
[Bug c++/120917] warning: use of 'auto' in template argument only available with '-fconcepts-ts'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #26 from Frank Heckenbach ---
(In reply to Frank Heckenbach from comment #24)
> (In reply to Jason Merrill from comment #23)
> >
> > Then yes, it does look like it should work; libstdc++ uses that 'requires
> > function call' pattern in
> >
> > template
> > concept __is_derived_from_optional = requires (const _Tp& __t) {
> > [](const optional<_Up>&){ }(__t);
> > };
>
> Thanks, the lambda makes it a bit shorter, and the knowledge that libstdc++
> uses it gives me more confidence. So I'll try this:
>
> template typename P> concept
> DerivedFromTemplate = requires (T v) { [] (const P
> &) { } (v); };
FYI, I applied this in my code, and apart from partial (T ) and
nested (T >) cases, as expected, and a few cases that became ambiguous
(I assume because it has slightly different precedence in overload resolution
or so), it worked as I hoped it would.
After dealing with some new compiler warnings (some useful, some probably bogus
like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116332#c3) and some issues in
libraries used, I could finally compile all my code with gcc-14 without .
So concerning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917#c15, I for
one won't need it with "-fpermissive" now. Thanks for all the help resolving
this matter.
[Bug c++/63164] unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
Thomas de Bock changed:
What|Removed |Added
CC||tdebock at DRWUK dot com
--- Comment #9 from Thomas de Bock ---
I managed to implement this optimization on rtti.cc:763 by simply adding a
check for if the target type is final (though ideally it should also recognize
non-final types with final destructor), then building the generic tree, that
compares the addresses of the source object and target type's vtables at
runtime. The issue with that is exactly as Florian says, this being a valid
solution depends on the source either being statically compiled or
__GXX_MERGED_TYPEINFO_NAMES being enabled (which it is not by default),
allowing for the optimization and never needing to call __dynamic_cast or
compare the type names.
Looking into the way clang implements this optimization, we can see at
CGExprCXX.cpp:2311 that it decides whether or not the optimization should be
applied:
// If the destination is effectively final, the cast succeeds if and only
// if the dynamic type of the pointer is exactly the destination type.
bool IsExact = !IsDynamicCastToVoid &&
CGM.getCodeGenOpts().OptimizationLevel > 0 &&
DestRecordTy->getAsCXXRecordDecl()->isEffectivelyFinal() &&
CGM.getCXXABI().shouldEmitExactDynamicCast(DestRecordTy);
with ItaniumCXXABI.cpp:225:
bool shouldEmitExactDynamicCast(QualType DestRecordTy) override {
return hasUniqueVTablePointer(DestRecordTy);
}
and ItaniumCXXABI.cpp:194:
bool hasUniqueVTablePointer(QualType RecordTy) {
const CXXRecordDecl *RD = RecordTy->getAsCXXRecordDecl();
// Under -fapple-kext, multiple definitions of the same vtable may be
// emitted.
if (!CGM.getCodeGenOpts().AssumeUniqueVTables ||
getContext().getLangOpts().AppleKext)
return false;
// If the type_info* would be null, the vtable might be merged with that of
// another type.
if (!CGM.shouldEmitRTTI())
return false;
// If there's only one definition of the vtable in the program, it has a
// unique address.
if (!llvm::GlobalValue::isWeakForLinker(CGM.getVTableLinkage(RD)))
return true;
// Even if there are multiple definitions of the vtable, they are required
// by the ABI to use the same symbol name, so should be merged at load
// time. However, if the class has hidden visibility, there can be
// different versions of the class in different modules, and the ABI
// library might treat them as being the same.
if (CGM.GetLLVMVisibility(RD->getVisibility()) !=
llvm::GlobalValue::DefaultVisibility)
return false;
return true;
}
As Florian said, with this code, would there not still be a case in which the
optimization is applied but fails(?):
When loading a library with dlopen and RTLD_LOCAL, since the types cannot be
resolved, two equivalent types (one from the executable, one from the library
loaded with dlopen) will not share a vtable, causing the optimized dynamic_cast
code to incorrectly decide the types are not the same.
If this is not the case could we not replicate clang's behaviour by checking
the value of __GXX_MERGED_TYPEINFO_NAMES around rtti.cc:763, the typeinfo
header can simply check the __GXX_MERGED_TYPEINFO_NAMES value and adjust its
implementation accordingly, but:
- Is it, at the point where the generic tree for dynamic_cast (or hopefully the
optimization) is constructed, possible anymore to check for the value of the
__GXX_MERGED_TYPEINFO_NAMES preprocessor directive?
- If not, would implementing the optimization by adding an additional function
(maybe in the typeinfo header) that handles these final type dynamic_casts that
checks the value of __GXX_MERGED_TYPEINFO_NAMES, then decides based on that
whether to simply compare vtable ptrs or compare the type names too, be
realistic?
[Bug cobol/120998] [16 regression] unable to bootstrap with cobol and without --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120998 Richard Biener changed: What|Removed |Added Target Milestone|--- |16.0 Keywords||build
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 --- Comment #10 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:b7b8eb90abaeaaf4a51325e087cd43a4dac8d25a commit r16-2098-gb7b8eb90abaeaaf4a51325e087cd43a4dac8d25a Author: Luc Grosheintz Date: Tue Jul 8 10:24:26 2025 +0200 libstdc++: Implement mdspan and tests [PR107761]. Implements the class mdspan as described in N4950, i.e. without P3029. It also adds tests for mdspan. This commit completes the implementation of P0009, i.e. the C++23 part . PR libstdc++/107761 libstdc++-v3/ChangeLog: * include/std/mdspan (mdspan): New class. * src/c++23/std.cc.in (mdspan): Add. * testsuite/23_containers/mdspan/class_mandate_neg.cc: New test. * testsuite/23_containers/mdspan/mdspan.cc: New test. * testsuite/23_containers/mdspan/layout_like.h: Add class LayoutLike which models a user-defined layout. Reviewed-by: Tomasz KamiÅski Signed-off-by: Luc Grosheintz
[Bug target/120993] powerpc64le with ibm128 long double LDBL_NORM_MAX does not conform to C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993 --- Comment #1 from Andrew Pinski --- powerpc64le is moving towards defaulting to ieee128 long double so this might become mute.
[Bug libstdc++/119739] [C++26] Implement P0952R2, A new specification for std::generate_canonical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119739 Nathan Myers changed: What|Removed |Added CC||ncm at gcc dot gnu.org Target Milestone|--- |16.0 Assignee|unassigned at gcc dot gnu.org |ncm at gcc dot gnu.org
[Bug libstdc++/119740] [C++26] Implement P2714R1, Bind front and back to NTTP callables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119740 Nathan Myers changed: What|Removed |Added Target Milestone|--- |16.0 CC||ncm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ncm at gcc dot gnu.org
[Bug tree-optimization/120358] [15 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #38 from rguenther at suse dot de --- On Tue, 8 Jul 2025, hol...@applied-asynchrony.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 > > --- Comment #37 from Holger Hoffstätte --- > (In reply to Richard Biener from comment #36) > > Should be fixed on trunk. The issue is latent since forever, I'll pick this > > to most branches. I hope somebody can test on the very original Qt > > testcase. > > I dropped the patch into my gcc-15.1.1_p20250705 snapshot on Gentoo, rebuilt > gcc and all attached test cases now pass. \o/ > > Thank you! Thank you for staying this long with us for the analysis!
[Bug tree-optimization/120916] debug line info for IV increment is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
--- Comment #8 from Jan Hubicka ---
Patching create_gcov to account all of debug statements associated with a given
address instead of just the last one gets me:
test total:4350509 head:8642
1: 4484 // {
2: 4484 // for (
3: 4484 //int i = 0;
4: 160 //i < s
5: 160 //i++)
6: 160 // a[i]++
7: 3677 // }
main total:6497 head:0
1: 0
2: 0
2.1: 2105 test:2079
2.3: 2105 test:2079
3: 2287 test:2079
4: 0
which looks better. However I am not sure if I can handle multiple debug
statements associated to the same line with different inline stacks, since
inline stacks seems to be keyed to locations.
I am not sure if auto-profiles have chance to give realistic loop iteration
count estimates. Counts suggests 322 iterations, since loop iterates 1023 and
is unrolled by factor 4 it is still somewhat off, but at least we get much
better profile.
[Bug tree-optimization/120916] debug line info for IV increment is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916 --- Comment #9 from Jan Hubicka --- Created attachment 61818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61818&action=edit create_gcov path
[Bug libstdc++/120914] [C++26] P3029R1 Better mdspan's CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120914 Tomasz Kamiński changed: What|Removed |Added Target Milestone|--- |16.0 --- Comment #4 from Tomasz Kamiński --- Completed in v16. span changes are applied retroactively to C++20 mode.
[Bug c++/117784] [C++26] P2686R4 - constexpr structured bindings and references to constexpr variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117784 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c81447d969f27a8653ebb1a450372f0d25a2e628 commit r16-2108-gc81447d969f27a8653ebb1a450372f0d25a2e628 Author: Jakub Jelinek Date: Tue Jul 8 19:21:55 2025 +0200 c++: Implement part of C++26 P2686R4 - constexpr structured bindings [PR117784] The following patch implements the constexpr structured bindings part of the P2686R4 paper, so the [dcl.pre], [dcl.struct.bind], [dcl.constinit] and first hunk in [dcl.constexpr] changes. The paper doesn't have a feature test macro and the constexpr structured binding part of it seems more-less self-contained, so I think it is useful to get this in independently from the rest. Of course, automatic constexpr/constinit structured bindings in the tuple cases or automatic constexpr/constinit structured bindings with auto & will not really work for now. Another reason for the split is that for C++ < 26, I think what the patch implements is basically what the users will see, i.e. we can accept constexpr or constinit structured binding with pedwarn, but I think we can't change the constant expression rules in C++ < 26. I plan to look at the rest of the paper. 2025-07-08 Jakub Jelinek PR c++/117784 * decl.cc: Implement part of C++26 P2686R4 - constexpr structured bindings. (cp_finish_decl): Pedwarn for C++23 and older on constinit on structured bindings except for static/thread_local where it uses earlier error. (grokdeclarator): Pedwarn on constexpr structured bindings for C++23 and older instead of emitting error always, don't clear constexpr_p in that case. * parser.cc (cp_parser_decomposition_declaration): Copy over DECL_DECLARED_CONSTEXPR_P and DECL_DECLARED_CONSTINIT_P flags. * g++.dg/cpp1z/decomp3.C (test): For constexpr structured binding initialize from constexpr var instead of non-constexpr and expect just a pedwarn for C++23 and older instead of error always. * g++.dg/cpp26/decomp9.C (foo): Likewise. * g++.dg/cpp26/decomp22.C: New test. * g++.dg/cpp26/decomp23.C: New test. * g++.dg/cpp26/decomp24.C: New test. * g++.dg/cpp26/decomp25.C: New test.
[Bug c++/117784] [C++26] P2686R4 - constexpr structured bindings and references to constexpr variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117784 --- Comment #3 from Jakub Jelinek --- As the commit message says, so far partially implemented. One can declare structured bindings constexpr as long as the C++23-ish constant expression handling allows that.
[Bug tree-optimization/121001] frange on float_var*0.f includes NaN even if float_var does not include NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121001 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > GCC behaves IMHO correctly. On the true edge of a == a we know a is [-Inf, > +Inf]. > And +Inf*0.f or -Inf*0.f is NaN. Oh I missed that. For some reason I thought Inf *0.0 was 0.0.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 121001, which changed state. Bug 121001 Summary: frange on float_var*0.f includes NaN even if float_var does not include NaN https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121001 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[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 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #9) > (In reply to GCC Commits from comment #6) > > The master branch has been updated by Andre Vehreschild : > > > > https://gcc.gnu.org/g:15413e05eb9cde976b8890cd9b597d0a41a8eb27 > > > > commit r16-1967-g15413e05eb9cde976b8890cd9b597d0a41a8eb27 > > Author: Andre Vehreschild > > Date: Wed Jul 2 11:06:17 2025 +0200 > > > > Fortran: Remove corank conformability checks [PR120843] > > > > Remove the checks on coranks conformability in expressions, > > because there is nothing in the standard about it. When a coarray > > has no coindexes it it treated like a non-coarray, when it has > > a full-corank coindex its result is a regular array. So nothing > > to check for corank conformability. > > > > PR fortran/120843 > > > > gcc/fortran/ChangeLog: > > > > * resolve.cc (resolve_operator): Remove conformability check, > > because it is not in the standard. > > > > gcc/testsuite/ChangeLog: > > > > * gfortran.dg/coarray/coindexed_6.f90: Enhance test to have > > coarray components covered. > > This one also needs backporting to 15-branch. Otherwise we ICE on Toon's > code. Reopening so that it is not forgotten.
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 qinzhao at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-07-08 Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #1 from qinzhao at gcc dot gnu.org --- with gcc -O1 -fdump-tree-all t.c, in a-t.c.112t.objsz1, we see the object size is generated as _22: sizetype _26(D); _12 = &p_18->n; _23 = MEM [(void *)_12]; _24 = MAX_EXPR <_23, 0>; _25 = (sizetype) _24; _22 = _26(D) * _25; In the above, _25 is the # of element of the array, which is loaded from &p_18->n, the counted_by field of the structure, _26 is the size of each element, which is the size of A[m], is got as "element_size" in the following code in gcc/tree-object-size.cc: /* The type of the 6th argument type is the pointer TYPE to the original flexible array type. */ tree pointer_to_array_type = TREE_TYPE (gimple_call_arg (call, 5)); gcc_assert (POINTER_TYPE_P (pointer_to_array_type)); tree element_type = TREE_TYPE (TREE_TYPE (pointer_to_array_type)); tree element_size = TYPE_SIZE_UNIT (element_type); we can cleanly see that _26 is an uninitialized variable, whose initialization has been eliminated by the previous optimization already due to it's not used in IL at all. >From a-t.c.007.gimple, the initialization to the "element_size" is still available as: _7 = (sizetype) m.0; _8 = _7 * 4; D.4602 = _8; the above is eliminated by dse1. So, it's not reliable to get the "element_size" from the TYPE_SIZE_UNIT of the TYPE of the VLA type.
[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed for GCC 16.
[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:7d11ae1dd95a0296eeb5c14bfe3a5d4ec8873e3b
commit r16-2111-g7d11ae1dd95a0296eeb5c14bfe3a5d4ec8873e3b
Author: Marek Polacek
Date: Tue Jul 8 10:09:36 2025 -0400
c++: bogus error with union in qualified name [PR83469]
While working on Reflection I noticed that we reject:
union U { int i; };
constexpr auto r = ^^typename ::U;
which is due to PR83469. Andrew P. posted a patch in 2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586344.html
for which I had some comments but an updated patch never came.
~~
There are a few issues here with typenames and unions (and even struct
keywords with unions). First in cp_parser_check_class_key,
we need to allow typenames to name union types and union key
to be able to use with typenames.
The next issue is we need to record if we had a union key,
right now we just record it was a struct/class/typename one
which is wrong.
~~
This patch is an updated and cleaned up version; I've also addressed
a missing bit in pt.cc.
PR c++/83469
PR c++/93809
gcc/cp/ChangeLog:
* cp-tree.h (UNION_TYPE_P): Define.
(TYPENAME_IS_UNION_P): Define.
* decl.cc (struct typename_info): Add union_p field.
(struct typename_hasher::equal): Compare union_p field.
(build_typename_type): Use ti.union_p for union_type. Set
TYPENAME_IS_UNION_P.
* error.cc (dump_type) : Handle
TYPENAME_IS_UNION_P.
* module.cc (trees_out::type_node): Likewise.
* parser.cc (cp_parser_check_class_key): Allow typename key for
union
types and allow union keyword for typename types.
* pt.cc (tsubst) : Don't conflate unions with
class_type. For TYPENAME_IS_CLASS_P, check NON_UNION_CLASS_TYPE_P
rather than CLASS_TYPE_P. Add TYPENAME_IS_UNION_P handling.
gcc/testsuite/ChangeLog:
* g++.dg/template/error45.C: Adjust dg-error.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfail.
* g++.dg/parse/union1.C: New test.
* g++.dg/parse/union2.C: New test.
* g++.dg/parse/union3.C: New test.
* g++.dg/parse/union4.C: New test.
* g++.dg/parse/union5.C: New test.
* g++.dg/parse/union6.C: New test.
Co-authored-by: Andrew Pinski
Reviewed-by: Jason Merrill
[Bug c++/83469] union is not accepted as a valid class-key in template name resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:7d11ae1dd95a0296eeb5c14bfe3a5d4ec8873e3b
commit r16-2111-g7d11ae1dd95a0296eeb5c14bfe3a5d4ec8873e3b
Author: Marek Polacek
Date: Tue Jul 8 10:09:36 2025 -0400
c++: bogus error with union in qualified name [PR83469]
While working on Reflection I noticed that we reject:
union U { int i; };
constexpr auto r = ^^typename ::U;
which is due to PR83469. Andrew P. posted a patch in 2021:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586344.html
for which I had some comments but an updated patch never came.
~~
There are a few issues here with typenames and unions (and even struct
keywords with unions). First in cp_parser_check_class_key,
we need to allow typenames to name union types and union key
to be able to use with typenames.
The next issue is we need to record if we had a union key,
right now we just record it was a struct/class/typename one
which is wrong.
~~
This patch is an updated and cleaned up version; I've also addressed
a missing bit in pt.cc.
PR c++/83469
PR c++/93809
gcc/cp/ChangeLog:
* cp-tree.h (UNION_TYPE_P): Define.
(TYPENAME_IS_UNION_P): Define.
* decl.cc (struct typename_info): Add union_p field.
(struct typename_hasher::equal): Compare union_p field.
(build_typename_type): Use ti.union_p for union_type. Set
TYPENAME_IS_UNION_P.
* error.cc (dump_type) : Handle
TYPENAME_IS_UNION_P.
* module.cc (trees_out::type_node): Likewise.
* parser.cc (cp_parser_check_class_key): Allow typename key for
union
types and allow union keyword for typename types.
* pt.cc (tsubst) : Don't conflate unions with
class_type. For TYPENAME_IS_CLASS_P, check NON_UNION_CLASS_TYPE_P
rather than CLASS_TYPE_P. Add TYPENAME_IS_UNION_P handling.
gcc/testsuite/ChangeLog:
* g++.dg/template/error45.C: Adjust dg-error.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfail.
* g++.dg/parse/union1.C: New test.
* g++.dg/parse/union2.C: New test.
* g++.dg/parse/union3.C: New test.
* g++.dg/parse/union4.C: New test.
* g++.dg/parse/union5.C: New test.
* g++.dg/parse/union6.C: New test.
Co-authored-by: Andrew Pinski
Reviewed-by: Jason Merrill
[Bug c++/83469] union is not accepted as a valid class-key in template name resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Marek Polacek --- Fixed for GCC 16.
[Bug c++/121008] [16 Regression] Error on 'this' inside noexcept specifier of lambda capturing 'this' inside noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||needs-bisection Last reconfirmed||2025-07-09 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/121008] [16 Regression] Error on 'this' inside noexcept specifier of lambda capturing 'this' inside noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008 Andrew Pinski changed: What|Removed |Added Known to fail||16.0 Keywords||rejects-valid Known to work||15.1.0 Summary|Error on 'this' inside |[16 Regression] Error on |noexcept specifier of |'this' inside noexcept |lambda capturing 'this' |specifier of lambda |inside noexcept specifier |capturing 'this' inside ||noexcept specifier Target Milestone|--- |16.0
[Bug tree-optimization/120817] [13/14/15 Regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817 --- Comment #21 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0ebeed53983dbcefcf7b950895c9d88c85342cf4 commit r15-9941-g0ebeed53983dbcefcf7b950895c9d88c85342cf4 Author: Richard Biener Date: Mon Jul 7 09:56:50 2025 +0200 tree-optimization/120817 - bogus DSE of .MASK_STORE DSE used ao_ref_init_from_ptr_and_size for .MASK_STORE but alias-analysis will use the specified size to disambiguate against smaller objects. For .MASK_STORE we instead have to make the access size unspecified but we can still constrain the access extent based on the maximum size possible. PR tree-optimization/120817 * tree-ssa-dse.cc (initialize_ao_ref_for_dse): Use ao_ref_init_from_ptr_and_range with unknown size for .MASK_STORE and .MASK_LEN_STORE. * gcc.dg/vect/pr120817.c: New testcase. (cherry picked from commit 439b14e222571da76da2bfec04b9035fb9f1862d)
[Bug tree-optimization/120817] [13/14/15 Regression] Wrong code when compiled with -O1 -ftree-loop-vectorize for AArch64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817 --- Comment #22 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:77066fec7ae3b57806c5d8fed9429c7db9ee446b commit r15-9942-g77066fec7ae3b57806c5d8fed9429c7db9ee446b Author: Tamar Christina Date: Mon Jul 7 17:05:01 2025 +0100 testsuite: add sve hw check to testcase [PR120817] Drop down from SVE2 to SVE1 as that's the minimum required for the test, and since it's a mid-end test add the aarch64_sve_hw check. gcc/testsuite/ChangeLog: PR tree-optimization/120817 * gcc.dg/vect/pr120817.c: Add SVE HW check. (cherry picked from commit 4b9f760c511a4ef3a390dd6cfab80bada57c2535)
[Bug tree-optimization/120927] [15 Regression] 510.parest_r segfaults built with -Ofast -march=znver4 --param vect-partial-vector-usage=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120927 --- Comment #9 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:b8599692a336b29851bdc5d8506a51d57521595c commit r15-9940-gb8599692a336b29851bdc5d8506a51d57521595c Author: Richard Biener Date: Thu Jul 3 14:39:22 2025 +0200 tree-optimization/120927 - 510.parest_r segfault with masked epilog The following fixes bad alignment computaton for epilog vectorization when as in this case for 510.parest_r and masked epilog vectorization with AVX512 we end up choosing AVX to vectorize the main loop and masked AVX512 (sic!) to vectorize the epilog. In that case alignment analysis for the epilog tries to force alignment of the base to 64, but that cannot possibly help the epilog when the main loop had used a vector mode with smaller alignment requirement. There's another issue, that the check whether the step preserves alignment needs to consider possibly previously involved VFs (here, the main loops smaller VF) as well. These might not be the only case with problems for such a mode mix but at least there it seems wise to never use DR alignment forcing when analyzing an epilog. We get to chose this mode setup because the iteration over epilog modes doesn't prevent this, the maybe_ge (cached_vf_per_mode[0], first_vinfo_vf) skip is conditional on !supports_partial_vectors and it is also conditional on having a cached VF. Further nothing in vect_analyze_loop_1 rejects this setup - it might be conceivable that a target can do masking only for larger modes. There is a second reason we end up with this mode setup, which is that vect_need_peeling_or_partial_vectors_p says we do not need peeling or partial vectors when analyzing the main loop with AVX512 (if it would say so we'd have chosen a masked AVX512 epilog-only vectorization). It does that because it looks at LOOP_VINFO_COST_MODEL_THRESHOLD (which is not yet computed, so always zero at this point), and compares max_niter (5) against the VF (8), but not with equality as the comment says but with greater. This also needs looking at, PR120939. PR tree-optimization/120927 * tree-vect-data-refs.cc (vect_compute_data_ref_alignment): Do not force a DRs base alignment when analyzing an epilog loop. Check whether the step preserves alignment for all VFs possibly involved sofar. * gcc.dg/vect/vect-pr120927.c: New testcase. * gcc.dg/vect/vect-pr120927-2.c: Likewise. (cherry picked from commit 918f4517564c2cf7e5bb907428d5413742bee56f)
[Bug tree-optimization/120944] [12/13/14/15 Regression] Incorrect optimization with accessing a volatile structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120944 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:2c23368ed910a911e72af5decfc39bef11a9efac commit r15-9939-g2c23368ed910a911e72af5decfc39bef11a9efac Author: Richard Biener Date: Fri Jul 4 09:08:19 2025 +0200 tree-optimization/120944 - bogus VN with volatile copies The following avoids translating expressions through volatile copies. PR tree-optimization/120944 * tree-ssa-sccvn.cc (vn_reference_lookup_3): Gate optimizations invalid when volatile is involved. * gcc.dg/torture/pr120944.c: New testcase. (cherry picked from commit 6ed1e2ae1a742d859c2dd74c9e7cebdd3618e8b1)
[Bug tree-optimization/120358] [15 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #39 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0f1e4dd1f9354ea962113e066152d0a77209f732 commit r15-9944-g0f1e4dd1f9354ea962113e066152d0a77209f732 Author: Richard Biener Date: Mon Jul 7 15:13:38 2025 +0200 tree-optimization/120358 - bogus PTA with structure access When we compute the constraint for something like MEM[(const struct QStringView &)&tok2 + 32] we go and compute what (const struct QStringView &)&tok2 + 32 points to and then add subvariables to its dereference that possibly fall in the range of the access according to the original refs size. In doing that we disregarded that the subvariable the starting address points to might not be aligned to it and thus the access might start at any point within that variable. The following conservatively adjusts the pruning of adjacent sub-variables to honor this. PR tree-optimization/120358 * tree-ssa-structalias.cc (get_constraint_for_1): Adjust pruning of sub-variables according to the imprecise known start offset. (cherry picked from commit aa5ae523e84a97bf3a582ea0fa73d959afa9b9c7)
[Bug tree-optimization/118669] Misaligned store after vectorization without using misaligned type with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 --- Comment #15 from GCC Commits --- The releases/gcc-15 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c625bc9c7c294ef2851ae42d4a5b6cc899fecb5e commit r15-9943-gc625bc9c7c294ef2851ae42d4a5b6cc899fecb5e Author: Richard Biener Date: Wed Jul 2 09:30:05 2025 +0200 tree-optimization/118669 - fixup wrongly aligned loads/stores The vectorizer tracks alignment of datarefs with dr_aligned and dr_unaligned_supported but that's aligned with respect to the target alignment which can be less aligned than the mode used for the access. The following fixes this discrepancy for vectorizing loads and stores. The issue is visible for aarch64 SVE and risc-v where VLA vector modes have larger than element alignment but the target handles element alignment just fine. PR tree-optimization/118669 * tree-vect-stmts.cc (vectorizable_load): Emit loads with proper (element) alignment. (vectorizable_store): Likewise. (cherry picked from commit 37bf13adcda564dfdb28c3aa736f2cac71c73d09)
[Bug tree-optimization/118669] Misaligned store after vectorization without using misaligned type with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.2 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||15.1.1 --- Comment #16 from Richard Biener --- Fixed for GCC 15.2.
[Bug middle-end/118443] [Meta bug] Bugs triggered by and blocking more smtgcc testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118443 Bug 118443 depends on bug 118669, which changed state. Bug 118669 Summary: Misaligned store after vectorization without using misaligned type with SVE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/120358] [14 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 Richard Biener changed: What|Removed |Added Known to work||15.1.1 Summary|[15 regression] |[14 regression] |qtbase-6.9.0 miscompiled|qtbase-6.9.0 miscompiled |since |since |r15-580-gf3e5f4c58591f5 |r15-580-gf3e5f4c58591f5 Known to fail||15.1.0 Target Milestone|15.2|14.4 --- Comment #40 from Richard Biener --- I'm keeping this open, somewhat mis-classified for me to track as backporting candidate. The issue should be as old as field-sensitive support in PTA (a small testcase will likely reveal that). So technically a regression, but of course PTA solutions usually quickly degenerate meaning it's very hard to manifest those issues into an actual testcase that gets miscompiled.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 120927, which changed state. Bug 120927 Summary: [15 Regression] 510.parest_r segfaults built with -Ofast -march=znver4 --param vect-partial-vector-usage=1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120927 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[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 Status|REOPENED|WAITING --- Comment #11 from Andre Vehreschild --- Yes, I am stupid. I so wanted to use the updated patch, but I just took the hash from my note w/o even looking into it. Just backported the correct one and regtesting.
[Bug tree-optimization/120927] [15 Regression] 510.parest_r segfaults built with -Ofast -march=znver4 --param vect-partial-vector-usage=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120927 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||15.1.0 Resolution|--- |FIXED Known to work||15.1.1 --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/119920] Missed vectorization for conditioned adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920 --- Comment #9 from Alfie Richards --- Confirmed this fixes my test case. The optimization is fascinating, and looks really elegant. Thanks for sending it!
[Bug tree-optimization/121001] frange on float_var*0.f includes NaN even if float_var does not include NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121001 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- GCC behaves IMHO correctly. On the true edge of a == a we know a is [-Inf, +Inf]. And +Inf*0.f or -Inf*0.f is NaN.
[Bug tree-optimization/121004] float_var*0.0f if we know a is either -0.0 or 0.0 can be just done as copysign(0.0, a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
--- Comment #1 from Andrew Pinski ---
Actually LLVM transforms a*0.0f into copysign if it knows that a is finite.
That is:
```
float f0(float a)
{
if (__builtin_isnan(a) || __builtin_isinf(a))
__builtin_unreachable();
float t = a*0.f;
return t;
}
```
I am not 100% sure if this happens in PR 120996 but there is a possibility.
[Bug libstdc++/118681] [C++17] unsynchronized_pool_resource may fail to respect alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681 --- Comment #11 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ac2fb60a67d6d1de6446c25c5623b8a1389f4770 commit r16-2112-gac2fb60a67d6d1de6446c25c5623b8a1389f4770 Author: Jonathan Wakely Date: Fri Jul 4 16:44:13 2025 +0100 libstdc++: Ensure pool resources meet alignment requirements [PR118681] For allocations with size > alignment and size % alignment != 0 we were sometimes returning pointers that did not meet the requested aligment. For example, allocate(24, 16) would select the pool for 24-byte objects and the second allocation from that pool (at offset 24 bytes into the pool) is only 8-byte aligned not 16-byte aligned. The pool resources need to round up the requested allocation size to a multiple of the alignment, so that the selected pool will always return allocations that meet the alignment requirement. libstdc++-v3/ChangeLog: PR libstdc++/118681 * src/c++17/memory_resource.cc (choose_block_size): New function. (synchronized_pool_resource::do_allocate): Use choose_block_size to determine appropriate block size. (synchronized_pool_resource::do_deallocate): Likewise (unsynchronized_pool_resource::do_allocate): Likewise. (unsynchronized_pool_resource::do_deallocate): Likewise * testsuite/20_util/synchronized_pool_resource/118681.cc: New test. * testsuite/20_util/unsynchronized_pool_resource/118681.cc: New test. Reviewed-by: Tomasz KamiÅski
[Bug tree-optimization/121003] New: Sometimes __builtin_unreachable is still there before the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121003 Bug ID: 121003 Summary: Sometimes __builtin_unreachable is still there before the vectorizer Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Created attachment 61821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61821&action=edit testcase Take the attached testcase (which is from PR 120996 but added some if (a) __builtin_unreachable() that I thought would help) and we have some `if (a) __builtin_unreachable()` still there in ifcvt even though we got the ranges from them already. This is at -O3. I have not reduced the testcase yet though. The form of the `if (a)unreachable()` are all of: if (__builtin_isinf (x) || __builtin_isnan(x)) __builtin_unreachable(); Trying to say we only have finite values.
[Bug tree-optimization/121004] New: float_var*0.0f if we know a is either -0.0 or 0.0 can be just done as copysign(0.0, a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
Bug ID: 121004
Summary: float_var*0.0f if we know a is either -0.0 or 0.0 can
be just done as copysign(0.0, a)
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
float f(float a)
{
if (a != 0)
__builtin_unreachable();
float t = a*0.f;
return t;
}
float f1(float a)
{
return __builtin_copysignf(0.0, a);
}
```
f should optimize to f1. This is what LLVM does.
[Bug libstdc++/118681] [C++17] unsynchronized_pool_resource may fail to respect alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681 --- Comment #12 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:eb412029f5cec52275d14956fe01473015a9ce0e commit r16-2115-geb412029f5cec52275d14956fe01473015a9ce0e Author: Jonathan Wakely Date: Wed Jul 9 00:54:33 2025 +0100 libstdc++: Fix double free in new pool resource test [PR118681] This was supposed to free p1 and p2, not free p2 twice. libstdc++-v3/ChangeLog: PR libstdc++/118681 * testsuite/20_util/unsynchronized_pool_resource/118681.cc: Fix deallocate argument.
[Bug fortran/120637] Memory leak in finalization gfortran 9.5-16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637 --- Comment #8 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:d1f05661fa6c8a6ea6f59ad365a84469100e425e commit r16-2086-gd1f05661fa6c8a6ea6f59ad365a84469100e425e Author: Andre Vehreschild Date: Wed Jun 25 14:46:16 2025 +0200 Fortran: Ensure finalizers are created correctly [PR120637] Finalize_component freeed an expression that it used to remember which components in which context it had finalized already. While it makes sense to free the copy of the expression, if it is unused, it causes issues, when comparing to a non existent expression. This is now detected by returning true, when the expression has been used. PR fortran/120637 gcc/fortran/ChangeLog: * class.cc (finalize_component): Return true, when a finalizable component was detect and do not free it. gcc/testsuite/ChangeLog: * gfortran.dg/asan/finalize_1.f90: New test.
[Bug fortran/120637] Memory leak in finalization gfortran 9.5-16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637 --- Comment #9 from Andre Vehreschild --- This is candidate for a backport to at least gcc-15. I therefore wait a week to let it mature before backporting.
[Bug c++/120776] [C++26] P1306R5 - Expansion statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776 Jakub Jelinek changed: What|Removed |Added Attachment #61786|0 |1 is obsolete|| --- Comment #3 from Jakub Jelinek --- Created attachment 61817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61817&action=edit gcc16-pr120776-wip.patch Some further progress. Current main problem is instantiation of expansion stmt body. And really nothing is done so far about destructuring expansion stmts, break/continue isn't handled etc.
[Bug tree-optimization/120980] Vectorizer (early exit) introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #6 from Krister Walfridsson ---
(In reply to Richard Biener from comment #4)
> (In reply to Krister Walfridsson from comment #3)
> > (In reply to Richard Biener from comment #2)
> > And there are more problems. For example, how does a fully out-of-bounds
> > load interact with pointer provenance? The out-of-bounds bytes do not
> > correspond to the provenance and may even belong to a different object, so
> > the provenance check will still classify the load as UB, even if we relax
> > the in-range check.
>
> Isn't provenance determined by the restrictions on pointer arithmetic? That
> is,
> a pointer adjustment (or implied address calculation from a memory
> access) that gets us outside of the object the pointer base points to would
> still have that original provenance.
>
> But sure, for your testcase it's very difficult to distinguish the case
> where the compiler did sth wrong from the case where correctness depends
> on the actual input - with a2[2] = { 0, 0 } the original scalar code would
> already access out-of-bound elements.
>
> Maybe if we say that if there's a in-bound or partial in-bound access
> then an access that's based on the same (or advanced) pointer is OK,
> even if fully out-of-bounds, if it is within the same page (based on
> alignment knowledge)? That is, somehow treat the separate accesses as
> one?
Provenance is more important for the GIMPLE semantic than it is for C.
It is UB in C to perform pointer arithmetic that moves a pointer outside of an
object (with a special case for "one past"), so for
char arr1[1000];
char *p = arr1;
char *q = p + i;
it's UB in C if (i < 0 || i > 1000). That means if we see a memory access *q,
we know it must refer to arr1 (or the "one past" case), even without
considering provenance.
In GIMPLE, where pointers may point outside their original objects, it's the
provenance restrictions that ensure *q stays within the intended object. In
other words, *q may access _any_ valid memory unless the provenance check
blocks it by making the access UB!
Assume we have a second array arr2 placed directly after arr1 in memory.
Without provenance restrictions,
char sum = *p + *q;
has defined semantics even for values such as i = 1100, where it would now be
required to produce the same result as arr1[0] + arr2[100]. This would
significantly constrain most memory optimizations...
But when allowing fully out-of-bounds loads, we cannot really distinguish
whether *p + *q represents arr1[0] + arr1[i], where provenance should be
checked to make it UB if *q would access another object, or arr1[0] +
*out-of-bounds-access, where we must ignore provenance to allow the load.
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 --- Comment #14 from H.J. Lu --- (In reply to Filip Kastl from comment #11) > (In reply to H.J. Lu from comment #9) > > Created attachment 61803 [details] > > A patch > > > > Please try this. > > Tried applying this on top of r16-1644-gaba3b9d3a48a07. > With r16-1644-gaba3b9d3a48a07 ... 224s > With r16-1644-gaba3b9d3a48a07 and the patch ... 161s > (this is on the machine where I originally measured 24% slowdown) > > Looks like this patch gets us the original speed and even a bit more. Nice. > > (In reply to H.J. Lu from comment #10) > > (In reply to Filip Kastl from comment #8) > > > The same commit (r16-1644-gaba3b9d3a48a07) causes ~20% slowdown of 470lbm > > > from 2006 SPEC on Zen5 with -Ofast -march=native -flto -fprofile-use. > > > > > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1283.240.0 > > > > Can you extra a small testcase to show the issue? > > I could try. But we already have a patch. So I think we don't have to > search for a smaller testcase. What do you think? It isn't needed.
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #2 from Richard Biener --- (In reply to qinzhao from comment #1) > with gcc -O1 -fdump-tree-all t.c, in a-t.c.112t.objsz1, we see the object > size is generated as _22: > > sizetype _26(D); > > _12 = &p_18->n; > _23 = MEM [(void *)_12]; > _24 = MAX_EXPR <_23, 0>; > _25 = (sizetype) _24; > _22 = _26(D) * _25; > > In the above, _25 is the # of element of the array, which is loaded from > &p_18->n, the counted_by field of the structure, _26 is the size of each > element, which is the size of A[m], is got as "element_size" in the > following code in gcc/tree-object-size.cc: > > /* The type of the 6th argument type is the pointer TYPE to the original > flexible array type. */ > tree pointer_to_array_type = TREE_TYPE (gimple_call_arg (call, 5)); > gcc_assert (POINTER_TYPE_P (pointer_to_array_type)); > tree element_type = TREE_TYPE (TREE_TYPE (pointer_to_array_type)); > tree element_size = TYPE_SIZE_UNIT (element_type); > > > we can cleanly see that _26 is an uninitialized variable, whose > initialization has been eliminated by the previous optimization already due > to it's not used in IL at all. You indeed cannot use (non-constant) TYPE_SIZE_UNIT in this way. If there is an ARRAY_REF in the IL you can use array_ref_element_size to get at it. But arbitrary VLA type sizes to not survive unless you use them in the original GENERIC IL.
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 --- Comment #16 from Filip Kastl --- Ok, I'll try to extract a smaller testcase.
[Bug tree-optimization/121003] Sometimes __builtin_unreachable is still there before the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121003 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-07-09 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- ifcvt should possibly get rid of all __builtin_unreachable() aggressively (in the vectorizer version copy, of course).
[Bug tree-optimization/120358] [15 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #37 from Holger Hoffstätte --- (In reply to Richard Biener from comment #36) > Should be fixed on trunk. The issue is latent since forever, I'll pick this > to most branches. I hope somebody can test on the very original Qt testcase. I dropped the patch into my gcc-15.1.1_p20250705 snapshot on Gentoo, rebuilt gcc and all attached test cases now pass. \o/ Thank you!
Re: Bug in G++ 14.2.0
On 08/07/25 08:44 +, Žarko Asen wrote: Hi I would like to report a critical issue with G++ 14.2.0, namely assigning from a variable declared in the same line as assignment is perfectly legal and compiles with G++; namely const uint32_t x1 = x1 + 1; // Is legal even though, there is no x declared previously This mailing list is for automated mail from our Bugzilla database, not for reporting bugs directly by email. Please see https://gcc.gnu.org/bugs/ for how to report bugs. But anyway, did you try -Wuninitialized ? The code is well-formed, meaning the compiler has to compile it, but it's undefined if executed at runtime. So we give a warning.
[Bug tree-optimization/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922 --- Comment #6 from Robin Dapp --- (In reply to Tamar Christina from comment #5) > Question, can I count on > > -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8 > > always being available as a codegen option for RVV? or do I need some > require-effective-target checks? For a compile test? Yes, that should always be available. To be extra sure you can add a target riscv_v.
[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005 benh at kernel dot crashing.org changed: What|Removed |Added CC||benh at kernel dot crashing.org --- Comment #20 from benh at kernel dot crashing.org --- I don't know if this data point is worth it but I've been chasing a hang in Koji when trying to build our gcc 14 that points to that test as well. It appears that it was sporadic until recent updates to our glibc (basically c9s glibc) which makes it happen much more often (maybe due to changes in the cond vars implementation ? not sure...). What I observe is that sometimes rwlock_1.ext doesn't just fail/timeout, it actually deadlocks in what looks like a cleanup path (and stays there forever). The build has to be killed (or ssh in the builder & kill rwlock_1.ext and the test suite then continues). Now when I just run that test manually (with pretty much the same libgomp & libgfortran installed system-wide), I get a slightly different "error": [ec2-user@ip-172-31-17-247 libgomp5]$ ./rwlock_1.exe STOP 2 STOP 2 Internal Error: Trying to free nonempty asynchronous unit Error termination. Backtrace: #0 0x7f210b4d8d7e in free_async_unit at ../../../libgfortran/io/async.c:211 #1 0x7f210b4cd429 in close_unit_1 at ../../../libgfortran/io/unit.c:759 #2 0x7f210b57109d in _dl_fini at /usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/elf/dl-fini.c:142 #3 0x7f210ae4231c in __run_exit_handlers at /usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/stdlib/exit.c:126 #4 0x7f210ae4246f in __GI_exit at /usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/stdlib/exit.c:156 #5 0x401884 in ??? #6 0x7f210b0f0b4d in gomp_thread_start at ../../../libgomp/team.c:129 #7 0x7f210ae8b4e9 in start_thread at /usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/nptl/pthread_create.c:443 #8 0x7f210af106cf in clone3 at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 #9 0x in ??? and in gdb: Thread 13 "rwlock_1.exe" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x709f4640 (LWP 2491931)] __pthread_clockjoin_ex (threadid=140736011957824, thread_return=thread_return@entry=0x0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:43 43if (INVALID_NOT_TERMINATED_TD_P (pd)) (gdb) backtrace #0 __pthread_clockjoin_ex (threadid=140736011957824, thread_return=thread_return@entry=0x0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:43 #1 0x7788ce83 in ___pthread_join (threadid=, thread_return=thread_return@entry=0x0) at pthread_join.c:25 #2 0x77ed8d30 in __gthread_join (__threadid=, __value_ptr=0x0) at ../libgcc/gthr-default.h:682 #3 _gfortrani_async_close (au=0x7fffbc003540) at ../../../libgfortran/io/async.c:486 #4 0x77ecd42a in close_unit_1 (u=0x7fffbc000fb0, locked=locked@entry=1) at ../../../libgfortran/io/unit.c:759 #5 0x77ecd61a in _gfortrani_close_units () at ../../../libgfortran/io/unit.c:836 #6 0x77fcb09e in _dl_fini () at dl-fini.c:142 #7 0x7784231d in __run_exit_handlers (status=status@entry=2, listp=0x779fa838 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:126 #8 0x77842470 in __GI_exit (status=status@entry=2) at exit.c:156 #9 0x77c25cb3 in _gfortran_stop_numeric (code=2, quiet=) at ../../../libgfortran/runtime/stop.c:126 #10 0x00401885 in MAIN__._omp_fn.0 () #11 0x77f88b4e in gomp_thread_start (xdata=) at ../../../libgomp/team.c:129 #12 0x7788b4ea in start_thread (arg=) at pthread_create.c:443 #13 0x779106d0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 Thread 13 "rwlock_1.exe" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x709f4640 (LWP 2491931)] __pthread_clockjoin_ex (threadid=140736011957824, thread_return=thread_return@entry=0x0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:43 43if (INVALID_NOT_TERMINATED_TD_P (pd)) (gdb) backtrace #0 __pthread_clockjoin_ex (threadid=140736011957824, thread_return=thread_return@entry=0x0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:43 #1 0x7788ce83 in ___pthread_join (threadid=, thread_return=thread_return@entry=0x0) at pthread_join.c:25 #2 0x77ed8d30 in __gthread_join (__threadid=, __value_ptr=0x0) at ../libgcc/gthr-default.h:682 #3 _gfortrani_async_close (au=0x7fffbc003540) at ../../../libgfortran/io/async.c:486 #4 0x77ecd42a in close_unit_1 (u=0x7fffbc000fb0, locked=locked@entry=1) at ../../../libgfortran/io/unit.c:759 #5 0x77ecd61a in _
[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005 --- Comment #21 from benh at kernel dot crashing.org --- s/rwlock_1.ext/rwlock1_exe/ ... looks like my fingers refuse to type ".exe" .. I wonder why :-)
[Bug target/120957] [16 Regression] 6% slowdown of 503.bwaves_r on Zen2 since r16-1647-gc06979ff957485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 6-9%|[16 Regression] 6% slowdown
|slowdown of 503.bwaves_r on |of 503.bwaves_r on Zen2
|Zen{2,3} since |since
|r16-1647-gc06979ff957485|r16-1647-gc06979ff957485
--- Comment #4 from Filip Kastl ---
Ok, on Zen3 this bisects to r16-1644-gaba3b9d3a48a07. So the Zen2 and Zen3
slowdowns seem to really be separate problems.
Sorry for that. Usually it doesn't happen that I see two similar but distinct
slowdowns in the same time frame.
[Bug tree-optimization/120972] restrict does not work for not-parameter pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
--- Comment #6 from Feng Xue ---
(In reply to rguent...@suse.de from comment #5)
> I see. I see annotating loops with pragmas as a more user-friendly way
> of getting there. What we have at our disposal in terms of pragmas
> is quite limiting though, and if the application is a benchmark where
> changes are not allowed this doesn't help, of course.
>
> Handling outermost scope variables is reasonable I think. I'll note
> another problem though, which is
>
> void foo (int *a, int *b)
> {
> int * __restrict p = a;
> *p = *b;
> p = b;
> *p = *a;
> }
>
> I'd have to re-read the standard wording but since on GIMPLE we can't
> restrict ourselves to variables with initializer (that distinction
> is lost), we have to deal with possibly multiple assignments to
> the restrict qualified pointer (and the "first" one possibly being
> DCEd already).
>
> Another issue is that of propagation. We are happily replacing
>
> int * __restrict p = a;
> *p = *b;
>
> with
>
> *a = *b;
>
> but you can't reply on all uses of 'p' being replaced, so you
> might get an invalid mix of accesses via the restrict qualified
> and the not restrict qualified pointer from the initializer.
A simple and safe way is to forget __restrict on "p" if it is replaced by "a".
Or in some limited sceinaros, there is no memory access or any address
computation on "a" before assignment of "p = a" and after assignment of "a", we
also set "a" as __restrict.
[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 Robin Dapp changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Robin Dapp --- This has been fixed a while ago already and passes on trunk. We didn't re-add the overlap constraints since but if there's any concern about those it should be discussed in a new bug.
[Bug target/120461] ICE: in gen_reg_rtx, at emit-rtl.cc:1189 with -mcpu=xt-c920 -mrvv-vector-bits=zvl -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120461 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #1 from Robin Dapp --- In emit_vlmax_insn_lra we try to emit a vsetivli which doesn't exist for XTheadVector. Testing a simple patch.
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 --- Comment #12 from Filip Kastl --- As I've commented in pr120957, I've also bisected 9% Zen3 -Ofast -march=native slowdown to this commit. That slowdown can also be solved by applying the patch hjl has provided.
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 --- Comment #13 from Filip Kastl --- (In reply to Filip Kastl from comment #12) > As I've commented in pr120957, I've also bisected 9% Zen3 -Ofast > -march=native slowdown to this commit. That slowdown can also be solved by > applying the patch hjl has provided. the slowdown is on 503.bwaves_r
[Bug target/119100] RISC-V: missed opportunities for vector-scalar instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100 --- Comment #11 from Paul-Antoine Arras --- (In reply to Jeffrey A. Law from comment #10) > So I don't mind these changes being tagged to pr119100. My only concern is > how do we know when we're done on this bug? The way I see it is, this bug encompasses all vector-scalar fused multiply-add instructions. All the single width varieties are already done. What is missing now is the widening varieties, which I am currently working on. Once this is done, I think we can consider this PR resolved.
[Bug tree-optimization/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922 --- Comment #5 from Tamar Christina --- Question, can I count on -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8 always being available as a codegen option for RVV? or do I need some require-effective-target checks?
[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 --- Comment #10 from GCC Commits --- The releases/gcc-15 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:67452737d8e6d2629104ac811eaf6ec8c1790614 commit r15-9935-g67452737d8e6d2629104ac811eaf6ec8c1790614 Author: Andre Vehreschild Date: Fri Jun 27 15:31:21 2025 +0200 Fortran: Ensure arguments in coarray call get unique components in add_data [PR120847] PR fortran/120847 gcc/fortran/ChangeLog: * coarray.cc (check_add_new_comp_handle_array): Make the count of components static to be able to create more than one. Create an array component only for array expressions. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/coindexed_7.f90: New test. (cherry picked from commit ee31ab9b1950b7f47f030bda231ace34d187ae26)
[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 --- Comment #7 from GCC Commits --- The releases/gcc-15 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:887ddb4d8c3ddd27c3a5cfd79f21dd52403c82fa commit r15-9934-g887ddb4d8c3ddd27c3a5cfd79f21dd52403c82fa Author: Andre Vehreschild Date: Fri Jun 27 14:39:13 2025 +0200 Fortran: Fix non-conformable corank on this_image ref [PR120843] PR fortran/120843 gcc/fortran/ChangeLog: * resolve.cc (resolve_operator): Report inconsistent coranks only when not referencing this_image. (gfc_op_rank_conformable): Treat coranks as inconformable only when a coindex other then implicit this_image is used. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/coindexed_6.f90: New test. (cherry picked from commit 1b0930e9046e0b6201fa03c2843f3b06e522acd1)
[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 Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from Andre Vehreschild --- Backported to gcc-15. Closing.
[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 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Andre Vehreschild --- Backported to gcc-15, closing.
[Bug tree-optimization/120982] Incorrect alignment after (early exit) vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120982
--- Comment #3 from Richard Biener ---
That is, DR_TARGET_ALIGNMENT and dr_aligned do not mix well for "over-aligned"
DR_TARGET_ALIGNMENT.
The immediate issue might be best fixed by dropping the set_ptr_info_alignment
calls, but we are using the same wrong over-alignment for .MASK_LOAD for
example here:
else if (final_mask)
{
tree ptr = build_int_cst (ref_type, align * BITS_PER_UNIT);
possibly harmless again in the end of course.
Instead of complicating uses of DR_TARGET_ALIGNMENT it might be better
to have DR_TARGET_LOOP_ALIGNMENT for the purpose of ensuring each
first access in the vector loop is aligned (or DR_TARGET_GROUP_ALIGNMENT).
Of course that would require handling that everywhere.
I also wonder why we even pass analysis with this large DR_TARGET_ALIGNMENT
when DR_STEP obviously does not maintain it ...
[Bug c/120993] New: powerpc64le LDBL_NORM_MAX does not conform to C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993
Bug ID: 120993
Summary: powerpc64le LDBL_NORM_MAX does not conform to C23
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
ISO C23 §5.2.5.3.3¶32 says that LDBL_NORM_MAX must equal:
(1 - FLT_RADIX**-LDBL_MANT_DIG) * FLT_RADIX**LDBL_MAX_EXP
and on powerpc64le where FLT_RADIX=2, LDBL_MANT_DIG=106, LDBL_MAX_EXP=1024 this
must equal:
(1 - 2**-106) * 2**1024
= 2**1024 - 2**918
However, on this platform GCC defines LDBL_NORM_MAX to be
8.98846567431157953864652595394501288e+307L, which is 2**1023 - 2**917, i.e.,
half the value required by C23.
Presumably this discrepancy is due to the funky nature of the "double double"
arithmetic on this platform, where things get dicey above 2**1023 as overflow
can occur even before you get to 2**1024. However, the fact remains that
there's a disagreement between C23 and how GCC behaves. We ran across this
problem recently in some Gnulib test cases on GCC 15 powerpc64le.
One simple fix would be to change LDBL_MANT_DIG, LDBL_MAX_EXP, and
LDBL_NORM_MAX to equal DBL_MANT_DIG, DBL_MAX_EXP and DBL_NORM_MAX respectively.
There would be no need to change LDBL_MAX or any other part of the long double
implementation. This change would conform to C23, and would fix the problems we
ran into.
For an example of the problem, compile the following program test1.c with "gcc
-std=gnu23 test1.c":
#include
#include
int
main ()
{
long double epsilon = 1;
for (int i = 0; i < LDBL_MANT_DIG; i++)
epsilon /= FLT_RADIX;
long double one_minus_epsilon = 1 - epsilon;
long double ldbl_norm_max = one_minus_epsilon;
for (int i = 0; i < LDBL_MAX_EXP; i++)
ldbl_norm_max *= FLT_RADIX;
printf ("epsilon = %.27La\n", epsilon);
printf ("one_minus_epsilon = %.27La\n", one_minus_epsilon);
printf ("ldbl_norm_max = %.27La\n", ldbl_norm_max);
printf ("LDBL_NORM_MAX = %.27La\n", LDBL_NORM_MAX);
return ldbl_norm_max != LDBL_NORM_MAX;
}
This should exit with status 0 because all calculations are exact with no
rounding. However, on powerpc64le it exits with status 1 after outputting:
epsilon = 0x1.000p-106
one_minus_epsilon = 0x1.ff8p-1
ldbl_norm_max = inf
LDBL_NORM_MAX = 0x1.ff8p+1022
where the third output line is incorrect due to the funky nature of
calculations on this platform.
[Bug libstdc++/120994] New: [C++26] P2897R7 aligned_accessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120994 Bug ID: 120994 Summary: [C++26] P2897R7 aligned_accessor Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tkaminsk at gcc dot gnu.org Target Milestone: --- https://wg21.link/P2897R7
[Bug c++/120990] Narrowing conversion in std::function return value is not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990 --- Comment #6 from Rohan Suri --- That makes sense, thanks Jonathan.
[Bug libstdc++/120994] [C++26] P2897R7 aligned_accessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120994 Tomasz Kamiński changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-07-08 Status|UNCONFIRMED |NEW
[Bug tree-optimization/120972] restrict does not work for not-parameter pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
--- Comment #4 from Feng Xue ---
(In reply to Richard Biener from comment #3)
> (In reply to Feng Xue from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > Yes, it's not possible to implement the standards restrict qualification
> > > constraints reliably for pointers not in the outermost scope of a function
> > > and after the compiler was allowed to do CSE or other code transforms.
> > >
> > > For simplicity only function parameters (and select "global" cases)
> > > are handled in the implementation which resides in points-to analysis.
> > >
> > > In principle 'restrict' should be handled in the C/C++ language frontends
> > > instead.
> >
> > Maybe, I caught your point, w/o front-end scope information, we do not know
> > the effective lifetime of "__restrict__" pointer merely from def/use chain
> > in the gimple. An example:
> >
> > void foo (int *p)
> > {
> > int *a_escaped;
> >
> > {
> >int * __restrict__ a = ...;
> >
> >/* no alias between "a" and "p" */
> >*a = ...;
> >
> >/* Make "a" escaped from block scope */
> >a_escaped = a + offset;
> > }
> >
> > /* By source-level declaration syntax, "a_escaped" and "p" may be
> > aliased. But in the gimple, we do not know usage of "a_escaped" does not
> > belongs to lifetime constrainted by "__restrict__", and could lead to an
> > incorrect conclusion that "a_escaped" and "p" are alias-free. */
> >
> > *a_escaped = ...;
> >
> > ...
> > }
> >
> > But for the 2nd case, all pointers are defined in the outermost scope of
> > function. How about an enhancement? Besides parameters, we could also mark
> > all __restrict__ pointers declared in the outermost scope, and ignore others
> > in any enclosed scopes, as you said, probably this could be done that at the
> > front-end stage.
>
> Outermost scope would work as long as there is no inlining or optimization
> happening before since we happily elide scopes and "globalize" variables.
inline void goo()
{
int * __restrict__ p;
...
}
void foo()
{
goo();
}
->
void foo()
{
// goo();
{
// Would DECL_CONTEXT(p) become "foo" from "goo" after inline?
int * __restrict__ p;
...
}
}
I do not deep dive into related code how DECL_CONTEXT() varies with inline or
optimization. If this is quite compilicated to track, my thought is to
introduce another DECL_CONTEXT_RAW() or similar stuff, that is set to its
original function, when analyzing alias for a restrict var, we would also check
if DECL_CONTEXT and DECL_CONTEXT_RAW is matched or not.
> That is, it's quite difficult to prove handling user(!) variables in the
> outermost scope is correct. You'd check that DECL_CONTEXT of a variable
> is the same as DECL_INITIAL (cfun->decl), but I'm not sure this will
> never "break". Depending on frontends there might or might not be an
> additional "outer" scope from DECL_INITIAL IIRC.
>
> Does handling variables in the outermost scope matter in practice?
In reality, we encounter an application with a hot loop containing lots of
memory accesses, whose pointers are defined as __restrict__ variables
initialized in the outermost scope, and those fake aliasing relations prevent
vectorization.
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 --- Comment #11 from Filip Kastl --- (In reply to H.J. Lu from comment #9) > Created attachment 61803 [details] > A patch > > Please try this. Tried applying this on top of r16-1644-gaba3b9d3a48a07. With r16-1644-gaba3b9d3a48a07 ... 224s With r16-1644-gaba3b9d3a48a07 and the patch ... 161s (this is on the machine where I originally measured 24% slowdown) Looks like this patch gets us the original speed and even a bit more. Nice. (In reply to H.J. Lu from comment #10) > (In reply to Filip Kastl from comment #8) > > The same commit (r16-1644-gaba3b9d3a48a07) causes ~20% slowdown of 470lbm > > from 2006 SPEC on Zen5 with -Ofast -march=native -flto -fprofile-use. > > > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1283.240.0 > > Can you extra a small testcase to show the issue? I could try. But we already have a patch. So I think we don't have to search for a smaller testcase. What do you think?
[Bug target/120995] New: [RISC-V] ICE: unrecognizable insn UNSPEC_COMPARE_AND_SWAP with rv64gc_zabha_zacas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120995
Bug ID: 120995
Summary: [RISC-V] ICE: unrecognizable insn
UNSPEC_COMPARE_AND_SWAP with rv64gc_zabha_zacas
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sch...@linux-m68k.org
Target Milestone: ---
Target: riscv*-*-*
$ cat seeded_rng.i
_Bool atomic_bool_cmpxchg_v_0;
void atomic_bool_cmpxchg_old() {
__sync_bool_compare_and_swap(&atomic_bool_cmpxchg_v_0,
atomic_bool_cmpxchg_old, 0);
}
$ gcc/xgcc -B gcc/ -march=rv64gc_zabha_zacas -O2 -std=gnu11 -S seeded_rng.i
seeded_rng.i: In function ‘atomic_bool_cmpxchg_old’:
seeded_rng.i:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 7 6 8 2 (parallel [
(set (reg:QI 136)
(mem/v:QI (lo_sum:DI (reg:DI 135)
(symbol_ref:DI ("atomic_bool_cmpxchg_v_0") [flags 0x86]
)) [-1 S1 A8]))
(set (mem/v:QI (lo_sum:DI (reg:DI 135)
(symbol_ref:DI ("atomic_bool_cmpxchg_v_0") [flags 0x86]
)) [-1 S1 A8])
(unspec_volatile:QI [
(reg:QI 138)
(const_int 0 [0])
(const_int 32773 [0x8005]) repeated x2
] UNSPEC_COMPARE_AND_SWAP))
]) "seeded_rng.i":3:3 -1
(nil))
during RTL pass: vregs
seeded_rng.i:5:1: internal compiler error: in extract_insn, at recog.cc:2882
Bug in G++ 14.2.0
Hi I would like to report a critical issue with G++ 14.2.0, namely assigning from a variable declared in the same line as assignment is perfectly legal and compiles with G++; namely const uint32_t x1 = x1 + 1; // Is legal even though, there is no x declared previously regards, Zarko Asen ase...@gmail.com
[Bug target/120642] ICE: in validate_change_or_fail, at config/riscv/riscv-v.cc:5705 with -O -mcpu=xt-c920 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642
--- Comment #2 from Jin Ma ---
> Which doesn't match because the vector_length_operand predicate rejects
> nonzero constants for XTHEADVECTOR.
>
> I think the right fix here is to just guard the transformation in AVL
> propagation like this:
>
> ```
> diff --git a/gcc/config/riscv/riscv-avlprop.cc
> b/gcc/config/riscv/riscv-avlprop.cc
> index bb4aceb75064..3031c29ae63c 100644
> --- a/gcc/config/riscv/riscv-avlprop.cc
> +++ b/gcc/config/riscv/riscv-avlprop.cc
> @@ -508,7 +508,7 @@ pass_avlprop::execute (function *fn)
>simplify_replace_vlmax_avl (rinsn, prop.second);
> }
>
> - if (rvv_vector_bits == RVV_VECTOR_BITS_ZVL)
> + if (rvv_vector_bits == RVV_VECTOR_BITS_ZVL && !TARGET_XTHEADVECTOR)
> {
>/* Simplify VLMAX AVL into immediate AVL.
> E.g. Simplify this following case:
>
>
> ```
>
> But I've never really worked on theadvector.
>
> Jin Ma -- any thoughts here?
Hi,Jeff
Thank you for the feedback. Since XTheadVector lacks support for vsetivli,
your proposed method is the optimal workaround. By the way, if needed, I'd be
happy to submit a patch with test cases :)
