[Bug tree-optimization/117423] [13/14/15/16 Regression] union not written to with particular layout since r10-6321-g636e80eea24b78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117423 --- Comment #21 from pipcet at protonmail dot com --- Created attachment 61848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61848&action=edit patch documenting the problem This is obviously not something we should consider applying, but this patch contains a workaround which compares accesses bit-by-bit, determining whether each bit is in a hole or not. It appears to fix both testcases, but I'm not sure it's actually correct. The idea is that if two accesses differ in their hole patterns, we never merge them into the same access group, so the bug can't happen. Of course the actual comparison of the hole bit patterns could be made to be much faster, but is this the right approach? Or would it slow down code too much because copying a struct with a hole, for example, would no longer be scalarized?
[Bug libstdc++/121046] Asking is_constructible_v, NonTrivial*> is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046 --- Comment #3 from Jonathan Wakely --- https://cplusplus.github.io/LWG/issue4294
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #22 from Tom de Vries --- FYI, I've submitted a workaround for gdb that disables -fipa-modref for release gcc 12.0 - 16.0 ( https://sourceware.org/pipermail/gdb-patches/2025-July/219213.html ), assuming that his will be fixed in 16.1.
[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 119267, which changed state. Bug 119267 Summary: RISC-V: gcc generates vsetivli with wrong LMUL with extended assembly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267 What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |INVALID
[Bug target/119267] RISC-V: gcc generates vsetivli with wrong LMUL with extended assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267
Jeffrey A. Law changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Jeffrey A. Law ---
So we discussed this briefly in the RISC-V patchwork call last week.
First others confirmed that we do expose LMUL as part of the fake vlen/vtype
registers you can attach to an asm statement. That is the good news.
The bad news is I totally missed that you had multiple asm statements in your C
code. That is extradinarily bad. Nothing prevents code from moving between
distinct asm statements except data dependencies. ie, you can have
asm ("statement 1");
asm ("statement 2");
The asms will always be emitted in that order. But the compiler is free to
insert any code it wants between those two asms as long as it doesn't break
data dependencies. Your asms don't expose any of the vector configuration data
dependencies and thus is subject to the kinds of behavior you're seeing.
[Bug tree-optimization/121048] New: [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048 Bug ID: 121048 Summary: [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This change is causing regressions on the RISC-V port: commit 4b47acfe2b626d1276e229a0cf165e934813df6c (HEAD) Author: Richard Biener Date: Wed Jul 9 12:53:45 2025 +0200 Remove non-SLP vectorization factor determining The following removes the VF determining step from non-SLP stmts. For now we keep setting STMT_VINFO_VECTYPE for all stmts, there are too many places to fix, including some more complicated ones, so this is defered for a followup. [ ... ] With a riscv64-linux-gnu cross compiler: [jlaw@x11-dpi:~/test/obj/rv2/gcc$ make check-gcc RUNTESTFLAGS=rvv.exp=zve32f-1.c [ ... ] Running /home/jlaw/test/gcc/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp ... FAIL: gcc.target/riscv/rvv/autovec/zve32f-1.c -O3 -ftree-vectorize scan-tree-dump-times vect "vectorized 1 loops in function" 2 Reading the commit log in full, this may be somewhat expected as there are expected follow-ups.
[Bug libstdc++/119742] [C++26] Implement P2697R1, Interfacing bitset with string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742
--- Comment #5 from Jonathan Wakely ---
Also, do we want to make this change?
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -720,7 +720,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
namespace __bitset
{
-#if _GLIBCXX_HOSTED
+#ifdef __cpp_lib_bitset // ...construct from string_view
+template
+ using __string = std::basic_string_view<_CharT>;
+#elif _GLIBCXX_HOSTED
template
using __string = std::basic_string<_CharT>;
#else
It's cheaper to instantiate basic_string_view than basic_string, so it seems
useful.
[Bug target/121047] New: Possible hardware issue with Raptor Lake processors for code that gcc may generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121047
Bug ID: 121047
Summary: Possible hardware issue with Raptor Lake processors
for code that gcc may generate
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There is a blog post at
https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-intel-13th-14th-gen-cpus/
which says that Raptor Lake Intel processors have a bug which sometimes
lets the processor store the bits 7:0 (registers like cl or
dl) instead of bits 15:8 (ch or dh).
Source for which such code is generated is below, with-O2 -mbmi2.
This is not a gcc bug, so I am not sure what, if anything, gcc
should or should not do about this. I also cannot confirm this
on my own hardware, which is a different generation, but I thought
I'd record this anyway; this may be something that should be closed as
INVALID if gcc does not want to provide a workaround.
#include
void decode_five(uint8_t* dest, uint64_t& bits_ref, const uint16_t* table)
{
uint64_t bits = bits_ref;
uint16_t e;
e = table[bits & 2047];
bits >>= e & 63;
dest[0] = e >> 8;
e = table[bits & 2047];
bits >>= e & 63;
dest[1] = e >> 8;
e = table[bits & 2047];
bits >>= e & 63;
dest[2] = e >> 8;
e = table[bits & 2047];
bits >>= e & 63;
dest[3] = e >> 8;
e = table[bits & 2047];
bits >>= e & 63;
dest[4] = e >> 8;
bits_ref = bits;
}
[Bug libstdc++/121046] Asking is_constructible_v, NonTrivial*> is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-07-12 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jonathan Wakely --- --- a/libstdc++-v3/include/std/bitset +++ b/libstdc++-v3/include/std/bitset @@ -1046,7 +1046,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER * @throw std::invalid_argument If a character appears in the string *which is neither `__zero` nor `__one`. */ - template + template>> [[__gnu__::__nonnull__]] _GLIBCXX23_CONSTEXPR explicit
[Bug libstdc++/121046] New: Asking is_constructible_v, NonTrivial*> is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046
Bug ID: 121046
Summary: Asking is_constructible_v, NonTrivial*>
is ill-formed
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Found by the libc++ testsuite:
#include
struct NonTrivial { ~NonTrivial() { } };
static_assert( ! std::is_constructible_v, NonTrivial*> );
This fails outside the immediate context, due to the bitset(const CharT*)
constructor instantiating std::basic_string:
In file included from /home/jwakely/gcc/16/include/c++/16.0.0/string:56,
from /home/jwakely/gcc/16/include/c++/16.0.0/bitset:54,
from bitset.cc:1:
/home/jwakely/gcc/16/include/c++/16.0.0/bits/basic_string.h: In instantiation
of 'class std::__cxx11::basic_string,
std::allocator >':
/home/jwakely/gcc/16/include/c++/16.0.0/bitset:1053:2: required by
substitution of 'template std::bitset<1>::bitset(const _CharT*,
typename std::__bitset::__string<_CharT>::size_type, _CharT, _CharT) [with
_CharT = NonTrivial]'
1053 | bitset(const _CharT* __str,
| ^~
/home/jwakely/gcc/16/include/c++/16.0.0/type_traits:3621:46: required from
'constexpr const bool std::is_constructible_v, NonTrivial*>'
3621 | inline constexpr bool is_constructible_v = __is_constructible(_Tp,
_Args...);
|
^
bitset.cc:3:23: required from here
3 | static_assert( ! std::is_constructible_v, NonTrivial*>
);
| ^~~
/home/jwakely/gcc/16/include/c++/16.0.0/bits/basic_string.h:97:21: error:
static assertion failed
97 | static_assert(is_trivially_copyable_v<_CharT>
| ^~~
/home/jwakely/gcc/16/include/c++/16.0.0/bits/basic_string.h:97:21: note:
'std::is_trivially_copyable_v' evaluates to false
[Bug libstdc++/121046] Asking is_constructible_v, NonTrivial*> is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046 --- Comment #2 from Jonathan Wakely --- I think we should open a library issue to add a constraint to the standard.
[Bug target/121047] Possible hardware issue with Raptor Lake processors for code that gcc may generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121047 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-07-12 Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- This is most likely a won't fix. Do you if there is an errata issued for this yet?
[Bug fortran/121043] [15/16 Regression] Tests of OpenCoarray fail to pass, works on 14.3.1 20250701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #2 from Jerry DeLisle --- While bisecting on gcc-15 branch I can not reproduce the OpenCoarray test failure. However, I do see the following on gcc-15 pulled this morning. Clean build. FAIL: gfortran.dg/goacc/parameter-3.f90 -O (test for excess errors) FAIL: gfortran.dg/goacc/parameter-4.f90 -O (test for excess errors) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 11) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 13) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 15) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 17) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 19) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 21) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 25) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 31) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 36) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 39) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 40) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for warnings, line 41) FAIL: gfortran.dg/goacc/parameter.f95 -O (test for excess errors) I will continue to the current trunk (16) for OpenCoarrays related problem.
[Bug libstdc++/86015] Better handling of iterator distances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86015 --- Comment #16 from Jonathan Wakely --- The standard relaxed the rules slightly for iterator difference types, to permit integer-class types to be used as difference types (see [iterator.concept.winc]). However, those integer-class types are implementation-defined (so not arbitrary program-defined types) and they must support implicit conversion from all integer types. So _Distance __d = 0; is required to work. So I'm not seeing a bug here, and even if we decide to accept program-defined integer-like class types as iterator difference types, it seems to me that they should follow the same rules as integer-class types, and support implicit conversion from real integers. So I'm inclined to close this, as I don't see any reason to change libstdc++.
[Bug tree-optimization/121049] New: [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049
Bug ID: 121049
Summary: [16 regression] timezone-data miscompiled with -O3
-march=x86-64-v4 -mtune=znver4
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 61849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61849&action=edit
localtime.c
```
$ gcc z2.c -o z2 -O3 -march=x86-64-v4 -mtune=znver4 && ./z2
Aborted(core dumped) ./z2
```
```
[...]
Breakpoint 1, transtime (year=year@entry=2007,
rulep=rulep@entry=0x7fffd380, offset=offset@entry=-46800) at z2.c:46
46 {
(gdb) finish
Run till exit from #0 transtime (year=year@entry=2007,
rulep=rulep@entry=0x7fffd380, offset=offset@entry=-46800) at z2.c:46
0x441a in main () at z2.c:139
139 if (transtime(2007, &rulep, -46800) != 774)
Value returned is $1 = 5320800
```
---
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python
--enable-libphobos --enable-languages=c,c++,d,fortran,ada --enable-obsolete
--enable-secureplt --disable-werror --with-system-zlib --enable-nls
--without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 16.0. p, commit
fe1f0199d8773ec7dffa4b7b7c26b1dd56cf6fd6' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id
--with-build-config='bootstrap-O3 bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250712 (experimental)
f3186568d09c02a6d8915e43c0f5d7df704dfa0d (Gentoo Hardened 16.0. p, commit
fe1f0199d8773ec7dffa4b7b7c26b1dd56cf6fd6)
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Sam James changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |16.0
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 --- Comment #2 from Sam James --- Created attachment 61850 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61850&action=edit localtime.c Reduced it a bit more.
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Andrew Pinski changed: What|Removed |Added Attachment #61852|0 |1 is obsolete|| --- Comment #6 from Andrew Pinski --- Created attachment 61853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61853&action=edit Slightly more reduced Looks like only the first and last values of the array are added and missing the middle one.
[Bug libstdc++/88374] crash when stepping into for loop where iterators are created and compared with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88374 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #3 from Jonathan Wakely --- This was a GDB bug which has since been fixed, so closing.
[Bug libstdc++/90919] vector::iterator is constructible from a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90919 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2020-01-28 00:00:00 |2025-7-12 --- Comment #2 from Jonathan Wakely --- The least invasive change might be to make that constructor private, and then add every type that uses __normal_iterator as a friend (vector, string, stacktrace, optional, etc.) That way we wouldn't have to change every begin(), end() etc. function that constructs one of those iterators. That would break any users who are using __normal_iterator for their own containers, which we don't really support but we also don't prevent. We could add a new public two-parameter constructor that they could use instead.
[Bug gcov-profile/121045] [16 Regression] FAIL: g++.dg/torture/pr58552.C caused by r16-2197-g385d9937f0e23c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121045 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-12
[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600 --- Comment #12 from GCC Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:651845ceaae26a1b2c03f215e16e7e711dcea2cc commit r16-2214-g651845ceaae26a1b2c03f215e16e7e711dcea2cc Author: Xi Ruoyao Date: Tue Jul 8 14:07:21 2025 +0800 testsuite: Enable the PR 87600 tests for LoongArch I'm going to refine a part of the PR 87600 fix which seems triggering PR 120983 that LoongArch is particularly suffering. Enable the PR 87600 tests so I'll not regress PR 87600. gcc/testsuite/ChangeLog: PR rtl-optimization/87600 PR rtl-optimization/120983 * gcc.dg/pr87600.h [__loongarch__]: Define REG0 and REG1. * gcc.dg/pr87600-1.c (dg-do): Add loongarch. * gcc.dg/pr87600-2.c (dg-do): Likewise.
[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87600 --- Comment #13 from GCC Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:e6d3c88e7bb07f94308074f9751e4384a191e022 commit r16-2215-ge6d3c88e7bb07f94308074f9751e4384a191e022 Author: Xi Ruoyao Date: Tue Jul 8 14:39:11 2025 +0800 lra: Reallow reloading user hard registers if the insn is not asm [PR 120983] The PR 87600 fix has disallowed reloading user hard registers to resolve earlyclobber-induced conflict. However before reload, recog completely ignores the constraints of insns, so the RTL passes may produce insns where some user hard registers violate an earlyclobber. Then we'll get an ICE without reloading them, like what we are recently encountering in LoongArch test suite. IIUC "recog does not look at constraints until reload" has been a well-established rule in GCC for years and I don't have enough skill to challange it. So reallow reloading user hard registers (but still disallow doing so for asm) to fix the ICE. gcc/ChangeLog: PR rtl-optimization/120983 * lra-constraints.cc (process_alt_operands): Allow reloading user hard registers unless the insn is an asm.
[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983 --- Comment #9 from GCC Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:e6d3c88e7bb07f94308074f9751e4384a191e022 commit r16-2215-ge6d3c88e7bb07f94308074f9751e4384a191e022 Author: Xi Ruoyao Date: Tue Jul 8 14:39:11 2025 +0800 lra: Reallow reloading user hard registers if the insn is not asm [PR 120983] The PR 87600 fix has disallowed reloading user hard registers to resolve earlyclobber-induced conflict. However before reload, recog completely ignores the constraints of insns, so the RTL passes may produce insns where some user hard registers violate an earlyclobber. Then we'll get an ICE without reloading them, like what we are recently encountering in LoongArch test suite. IIUC "recog does not look at constraints until reload" has been a well-established rule in GCC for years and I don't have enough skill to challange it. So reallow reloading user hard registers (but still disallow doing so for asm) to fix the ICE. gcc/ChangeLog: PR rtl-optimization/120983 * lra-constraints.cc (process_alt_operands): Allow reloading user hard registers unless the insn is an asm.
[Bug rtl-optimization/120983] recog violates earlyclobber with user-defined hard register before reload (causing ICE on gcc.target/loongarch/bitwise-shift-reassoc-clobber.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120983 --- Comment #8 from GCC Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:651845ceaae26a1b2c03f215e16e7e711dcea2cc commit r16-2214-g651845ceaae26a1b2c03f215e16e7e711dcea2cc Author: Xi Ruoyao Date: Tue Jul 8 14:07:21 2025 +0800 testsuite: Enable the PR 87600 tests for LoongArch I'm going to refine a part of the PR 87600 fix which seems triggering PR 120983 that LoongArch is particularly suffering. Enable the PR 87600 tests so I'll not regress PR 87600. gcc/testsuite/ChangeLog: PR rtl-optimization/87600 PR rtl-optimization/120983 * gcc.dg/pr87600.h [__loongarch__]: Define REG0 and REG1. * gcc.dg/pr87600-1.c (dg-do): Add loongarch. * gcc.dg/pr87600-2.c (dg-do): Likewise.
[Bug libstdc++/117998] : views::counted misses difference casting for contiguous_iterator case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117998 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-12 Ever confirmed|0 |1
[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2025-07-12 Ever confirmed|0 |1 See Also||https://github.com/cplusplu ||s/papers/issues/1726 --- Comment #8 from Jonathan Wakely --- I'm suspending this, because I want to wait for P3059.
[Bug libstdc++/106610] elements_view::iterator::iterator_category invokes the operator*() && of the underlying iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106610 --- Comment #1 from Jonathan Wakely --- Isn't this invalid because of [concepts.equality] p6? The indirectly_readable concept requires that *it works on a const lvalue, which means it has to behave the same on lvalues and rvalues or the same type, const and non-const.
[Bug libstdc++/102181] [DR 3197] std::advance and std::views::iota don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102181
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
Target Milestone|--- |16.0
--- Comment #9 from Jonathan Wakely ---
The original testcase is missing , here's a slightly reduced form:
#include
int main() {
auto v = std::ranges::iota_view(0LL, 100LL);
auto b = v.begin();
std::advance(b, 1LL);
}
This compiles with -std=c++20 on trunk now, because is_integral_v<__int128> is
true since r16-2190-g4faa42ac0dee2c
But this still fails:
#include
int main() {
auto v = std::ranges::iota_view((__int128)0, (__int128)10);
auto b = v.begin();
std::advance(b, (__int128)1);
}
I have a patch though ...
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Andrew Pinski changed: What|Removed |Added Attachment #61851|0 |1 is obsolete|| --- Comment #4 from Andrew Pinski --- Created attachment 61852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61852&action=edit Removed the header
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Andrew Pinski changed: What|Removed |Added Attachment #61850|0 |1 is obsolete|| --- Comment #3 from Andrew Pinski --- Created attachment 61851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61851&action=edit Reduced further
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-07-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug debug/121045] [16 Regression] FAIL: g++.dg/torture/pr58552.C caused by r16-2197-g385d9937f0e23c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121045 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Keywords||compare-debug-failure, ||testsuite-fail Component|gcov-profile|debug CC||pinskia at gcc dot gnu.org
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 --- Comment #1 from Sam James --- May have overreduced, sec.
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-2088-ge9079e4f43d135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Sam James changed: What|Removed |Added Keywords|needs-bisection | CC||rguenth at gcc dot gnu.org Summary|[16 regression] |[16 regression] |timezone-data miscompiled |timezone-data miscompiled |with -O3 -march=x86-64-v4 |with -O3 -march=x86-64-v4 |-mtune=znver4 |-mtune=znver4 since ||r16-2088-ge9079e4f43d135 --- Comment #7 from Sam James --- r16-2088-ge9079e4f43d135
