[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #9 from Thomas Petazzoni --- FYI, this is still happening at least with GCC 13.3.0. We got again the build issue in our autobuilder today: https://autobuild.buildroot.org/results/f37b03dc47da8f54c583b33cac960daeed72c29f/build-end.log
[Bug ipa/60865] ICE: verify_cgraph_node failed: comdat-local function called by outside its comdat with -fdeclone-ctor-dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60865 --- Comment #5 from Zdenek Sojka --- This does not fail for any version since at least 6.5.0 (or even 5.5.0 according to Known to work), can be likely closed as fixed.
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #10 from Sam James --- Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032#c5.
[Bug gcov-profile/120321] New: Inconsistent line coverage for "for(;;)" "while(1)" etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120321
Bug ID: 120321
Summary: Inconsistent line coverage for "for(;;)" "while(1)"
etc
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: wentaoz5 at illinois dot edu
Target Milestone: ---
Hit the issue when measuring
https://sources.debian.org/src/iproute2/6.1.0-3/lib/libnetlink.c/#L872
etc
How to reproduce:
$ gcc --version
gcc (GCC) 16.0.0 20250511 (experimental)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat > test.c << 'EOF'
int g, h;
int one = 1;
void foo() {
g = 0;
while(1) { // C1 - C2 ?
g++; // C1
int dummy;
if (g >= 7)
break; // C2
h++; // C1 - C2
}
g = 0;
while(1) { // No code ?
g++; // C1
// int dummy;
if (g >= 7)
break; // C2
h++; // C1 - C2
}
g = 0;
while(one) { // C1 ?
g++; // C1
int dummy;
if (g >= 7)
break; // C2
h++; // C1 - C2
}
}
int main(void) {
for (int i = 0; i < 5; i++)
foo();
}
EOF
$ gcc --coverage test.c -o test
$ ./test
$ gcov test
$ cat test.c.gcov
...
5:5:void foo() {
5:6:g = 0;
30:7:while(1) { // C1 - C2 ?
35:8:g++; // C1
-:9:int dummy;
35: 10:if (g >= 7)
5: 11:break; // C2
30: 12:h++; // C1 - C2
-: 13:}
-: 14:
5: 15:g = 0;
-: 16:while(1) { // No code ?
35: 17:g++; // C1
-: 18:// int dummy;
35: 19:if (g >= 7)
5: 20:break; // C2
30: 21:h++; // C1 - C2
-: 22:}
-: 23:
5: 24:g = 0;
35: 25:while(one) { // C1 ?
35: 26:g++; // C1
-: 27:int dummy;
35: 28:if (g >= 7)
5: 29:break; // C2
30: 30:h++; // C1 - C2
-: 31:}
5: 32:}
...
Despite the same semantic, line coverage for line 7, 16, 25 refers to
different things. At line 7, line coverage seems to connect to the end of
loop body. This behavior is also affected by the presence or absence of
variable declaration inside the loop ("int dummy;" in the examples).
[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120186 --- Comment #10 from John Paul Adrian Glaubitz --- (In reply to John David Anglin from comment #9) > I was not able to reproduce this on c8000 So, the LRA-enabled bootstrap works for you without any problems?
[Bug tree-optimization/120322] [16 regression] wrong code at -O{s,2,3} with "-fno-early-inlining" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120322
Sam James changed:
What|Removed |Added
Summary|wrong code at -O{s,2,3} |[16 regression] wrong code
|with "-fno-early-inlining" |at -O{s,2,3} with
|on x86_64-linux-gnu |"-fno-early-inlining" on
||x86_64-linux-gnu
Keywords||wrong-code
Target Milestone|--- |16.0
[Bug c++/120323] New: ICE when mixing #include and import std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120323
Bug ID: 120323
Summary: ICE when mixing #include and import std
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.lelyakin at googlemail dot com
Target Milestone: ---
Following program:
-
import std;
#include
int main() {
std::cout << "Hello World!\n";
return 0;
}
-
Produces internal compiler error. See attachment.
Almost the same program have no problems.
-
#include
import std;
int main() {
std::cout << "Hello World!\n";
return 0;
}
-
[Bug tree-optimization/120322] New: wrong code at -O{s,2,3} with "-fno-early-inlining" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120322
Bug ID: 120322
Summary: wrong code at -O{s,2,3} with "-fno-early-inlining" on
x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/j1Msea9M4
It appears to be a recent regression as it doesn't reproduce with 15.1.
[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250517 (experimental) (GCC)
[509] %
[509] % gcctk -O3 small.c; ./a.out
[510] %
[510] % gcctk -O3 -fno-early-inlining small.c
[511] % ./a.out
Segmentation fault
[512] %
[512] % cat small.c
int a, b, c;
void d(int e) {
if (e > 0)
while (b)
;
}
void f(unsigned short e) { d(e); }
static void g(short e) {
f(e);
c = a;
}
int main() { g(-1); }
[Bug c++/120323] ICE when mixing #include and import std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120323 --- Comment #1 from Alexander Lelyakin --- Created attachment 61455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61455&action=edit Result of compilation with -freport-bug
[Bug target/120260] dyld runtime error for gfortran code on Mac OS X Sequoia 15.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120260 --- Comment #2 from Markus Winterer --- I could not find a simple solution to the problem such as a compiler option, instead there seems to be a limit of about 2 GByte static memory at which programs no longer run reliably although the physically available memory is much larger (in my case 24 GByte). However, dynamic allocation of memory (by change the Fortran code) seems to eliminate the problem. Here I present the results of two similar testprograms generating the same result but using either static or dynamic memory allocation for a 2D array (matrix). The small testprogram teststatic generates a similar behavior than the rmcxas code: only sometime starting, otherwise failing with the error code. Although this will help only after recoding part of the program, I hope it will also be useful for other users of fortran legacy codes on Apple Mac computers withs ARM/Silicon CPUs and recent operating systems. ./teststatic dyld[4001]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed dyld[4001]: Library not loaded: /usr/lib/libSystem.B.dylib Referenced from: <68776642-137C-37BD-A260-F21A304027E6> /Users/markuswinterer/Documents/2025/25may/fortran_test/teststatic Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache), '/usr/local/lib/libSystem.B.dylib' (no such file) zsh: abort ./teststatic program teststatic implicit none integer i,j,m,l,k parameter(m=16200) real*8 a(m,m) write(*,*) 'array dimension l, k: ' read (*,*) l,k do i=1,l do j=1,k a(i,j)=real(i+j-1) enddo enddo call out(m,l,k,a) end subroutine out(m,l,k,a) implicit none integer i,j,m,l,k real*8 a(m,m) open(20,file='teststatic.dat',status='unknown') do i =1,l write(20,*)(int(a(i,j)),j=1,k) enddo close(20,status='keep') return end Using the "size" command: size teststatic __TEXT __DATA __OBJC others dec hex 16384 2099527680 0 429564 6394544128 17d25 shows a size of more than 2GByte memory. Running teststatic with m = n = 16200 uses a similar memory (RSS) according to the "ps" command ps -vc PID STAT TIME SL RE PAGEIN VSZRSS LIM TSIZ %CPU %MEM COMMAND 3991 R+ 0:02.34 0 0 0 412787136 2052224 -0 99,3 8,2 teststatic The small testprogram testallocate generates no error code and allows the dynamic memory allocation: program testallocate implicit none integer i,j,m,n real*8, dimension(:,:), allocatable :: a write(*,*) 'array dimension m, n: ' read (*,*) m,n allocate(a(m,n)) write(*,*) shape(a) do i=1,m do j=1,n a(i,j)=real(i+j-1) enddo enddo call out(m,n,a) deallocate(a) end subroutine out(m,n,a) implicit none integer i,j,m,n real*8 a(m,n) open(20,file='testallocate.dat',status='unknown') do i =1,m write(20,*)(int(a(i,j)),j=1,n) enddo close(20,status='keep') return end Using the "size" command: size testallocate __TEXT __DATA __OBJC others dec hex 16384 0 0 429564 4295016448 1c000 shows a the us of no memory when not running. Running testallocate with m = n = 16200 uses a identical memory (RSS) according to the "ps" command than teststatic ps -vc PID STAT TIME SL RE PAGEIN VSZRSS LIM TSIZ %CPU %MEM COMMAND 3972 R+ 0:02.60 0 0 0 412787152 2052224 -0 99,7 8,2 testallocate But memory allocation is dynamic and the program always starts with no error.
[Bug c++/120318] Module deduced return type error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120318 Nathaniel Shead changed: What|Removed |Added Keywords||needs-bisection CC||nshead at gcc dot gnu.org --- Comment #1 from Nathaniel Shead --- This compiles fine on trunk, but errors on 15. I'm not sure what fixed the bug; r16-652-g9694bb129c0dbf seemed likely but reverting it locally didn't cause trunk to error.
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #31 from Jerry DeLisle --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2025-May/062177.html
[Bug c/120327] New: OpenMP, triangular collapsed for-loop, maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120327
Bug ID: 120327
Summary: OpenMP, triangular collapsed for-loop,
maybe-uninitialized warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jukka.suomela at aalto dot fi
Target Milestone: ---
Created attachment 61458
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61458&action=edit
Source code
It seems that when compiling OpenMP code with collapsed triangular for-loops
with optimization levels -O or -Og, I get the warning "'({anonymous})' may be
used uninitialized".
Moreover, it seems that "#pragma GCC diagnostic ignored" cannot be used to
silence this warning or turn it into a non-error (if I have -Werror enabled).
Source code:
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
int main(void) {
int n = 100;
#pragma omp parallel for collapse(2)
for (int i = 0; i < n; ++i) {
for (int j = i; j < n; ++j) {
}
}
}
Compiler output:
% gcc-14 -Wall -Werror -fopenmp -O test.c
In function 'main._omp_fn.0':
cc1: error: '({anonymous})' may be used uninitialized
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
% gcc-12 -Wall -Werror -fopenmp -O test.c
In function 'main._omp_fn.0':
cc1: error: '({anonymous})' may be used uninitialized
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
% gcc-11 -Wall -Werror -fopenmp -Og test.c
test.c: In function 'main._omp_fn.0':
cc1: error: '({anonymous})' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
Compiler versions:
% gcc-14 --version
gcc-14 (Homebrew GCC 14.2.0_1) 14.2.0
% gcc-12 --version
gcc-12 (Homebrew GCC 12.4.0) 12.4.0
% gcc-11 --version
gcc-11 (Homebrew GCC 11.5.0) 11.5.0
System: aarch64-apple-darwin24, macOS 15.4.1 (but this doesn't seem to be
important, as I can reproduce this also on x86 Intel Linux).
The main problem for me is that #pragma GCC diagnostic ignored is not working,
so this leads to challenges in workflows that use -Werror.
[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305 --- Comment #16 from Jonathan Wakely --- (In reply to aneris from comment #13) > (In reply to Jonathan Wakely from comment #12) > > tl;dr if you want to compile with strict -std=c++20 -pedantic settings, you > > need to strictly follow the rules of the standard. > > I understand, though, at the very least, couldn't this be made a warning for > -pedantic? I think that would be immensely useful. I don't see how. The library code is just C++ code, it doesn't know what your intention was when writing the code, or whether you wanted to use __int128 without warnings or not. And I don't think there's any preprocessor macro that the library can even check to see if you used -pedantic or not. > On another note, this code does compile with Clang. Apparently godbolt > defaults to libstdc++ for clang instead of libc++ and that caused all the > confusion. Yes, we've been asking them to make that more obvious for years: https://github.com/compiler-explorer/compiler-explorer/issues/3682 > Here: https://godbolt.org/z/j6fYMdjeo > > I did some digging and this is because std::is_integral_v<__int128_t> is > unconditionally true in libc++, unlike in libstdc++ where it's only true > when the GNU extensions are enabled. Yes, which is not conforming to the C++20 (and earlier) standards. It is allowed by C++23 though, and I plan to treat that as a DR for earlier standards. That's the topic of PR 96710. > So I was wondering, is it really out of the question to promote __int128_t > to an integer type by default like Clang? It'd make some code more > compatible. That's PR 96710. It was not allowed by the standard, but we fixed that: https://cplusplus.github.io/LWG/issue3828 (I reported that issue myself, specifically because I want to resolve this problem). (In reply to aneris from comment #14) > (In reply to aneris from comment #13) > > > I did some digging and this is because std::is_integral_v<__int128_t> is > > unconditionally true in libc++, unlike in libstdc++ where it's only true > > when the GNU extensions are enabled. > > Ok this is not it at all. > > looks like libc++ defaults to a long long unsigned as the difference type > for an iota_view with long unsigned. Right, for libc++ std::integral<__int128> is always true, but it also looks like they chose not to use the mechanisms introduced by https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1522r1.pdf for iota_view, so that range_difference_t> cannot represent the size of some views. https://godbolt.org/z/3M7sxh5qn
[Bug c++/120320] g++ freezes forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120320
--- Comment #2 from Patrick Palka ---
The problem is the CNF/DNF of the constraints in
template
requires(DenseMatrix || DenseMatrix || SparseMatrix ||
SparseMatrix)
struct storage_mul
template
struct storage_mul
template
struct storage_mul
are all huge, which makes determining which of these partial specializations is
most constrained not feasible via the ordinary subsumption algorithm.
Assuming the intent is to make the second and third partial specializations
above preferred over the first one, a workaround is to make this preference
more obvious, e.g. by adding potentially redundant constraints:
@@ -1187,7 +1187,7 @@ struct storage_mul
Specialization for DenseMatrix * Matrix or Matrix * DenseMatrix or
SparseMatrix * Matrix or
Matrix * SparseMatrix. */
template
-requires(DenseMatrix || DenseMatrix || SparseMatrix ||
SparseMatrix)
+requires(!DiagonalMatrix) && (!DiagonalMatrix) && (DenseMatrix ||
DenseMatrix || SparseMatrix || SparseMatrix)
struct storage_mul
{
storage_mul() = delete;
[Bug c++/120320] g++ freezes forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120320
--- Comment #3 from Patrick Palka ---
or rather:
--- a/matrix.h
+++ b/matrix.h
@@ -1187,7 +1187,9 @@ struct storage_mul
Specialization for DenseMatrix * Matrix or Matrix * DenseMatrix or
SparseMatrix * Matrix or
Matrix * SparseMatrix. */
template
-requires(DenseMatrix || DenseMatrix || SparseMatrix ||
SparseMatrix)
+requires(DenseMatrix || DenseMatrix
+ || (!DiagonalMatrix && !DiagonalMatrix
+ && (SparseMatrix || SparseMatrix)))
struct storage_mul
{
storage_mul() = delete;
[Bug c/120326] New: problems with attribute __ms_struct__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120326
Bug ID: 120326
Summary: problems with attribute __ms_struct__
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
struct {
unsigned char a : 3;
unsigned char b : 4;
unsigned short c : 6
};
struct {
unsigned char a : 3;
unsigned char b : 4;
unsigned short c : 6
} __attribute__((__ms_struct__));
lightly derived from clang/test/CodeGen/ms_struct-bitfield.c,
gcc does this:
foundBugs $ ../results/bin/gcc -c -w bug1100.c
foundBugs $ ../results/bin/gcc -c -w -g bug1100.c
bug1100.c:10:1: error: ‘TYPE_CANONICAL’ is not compatible
10 | } __attribute__((__ms_struct__));
| ^
[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305 --- Comment #15 from aneris --- (In reply to aneris from comment #14) > (In reply to aneris from comment #13) > So I was wondering, is it really out of the question to promote __int128_t to > an integer type by default like Clang? It'd make some code more compatible. I missed that you have tagged 96710 in "Depends on", sorry.
[Bug ipa/120307] [16 regression] ICE in combine_with_ipa_count_within, at profile-count.cc:410 during aarch64 -O3 profiledbootstrap since r16-101-g132d01d96ea9d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120307 Sam James changed: What|Removed |Added Target Milestone|--- |16.0 Summary|ICE in |[16 regression] ICE in |combine_with_ipa_count_with |combine_with_ipa_count_with |in, at profile-count.cc:410 |in, at profile-count.cc:410 |during aarch64 -O3 |during aarch64 -O3 |profiledbootstrap |profiledbootstrap since ||r16-101-g132d01d96ea9d6 Keywords|needs-bisection |
[Bug c++/120324] New: Code rejected as constant due to invalid read through reference member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120324
Bug ID: 120324
Summary: Code rejected as constant due to invalid read through
reference member
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This might actually be a CWG issue rather than a GCC one, as Clang rejects for
the same reason, but I thought I'd post here first just in case.
Here is an example that somebody sent me, which I reduced/restructured a bit:
struct A3 {
constexpr auto size() const -> int { return 3; }
};
template
struct wrap {
T target;
constexpr auto size1() const -> int { return target.size(); }
friend constexpr auto size2(wrap const& w) -> int { return w.target.size();
}
constexpr auto size3(this wrap const& w) -> int { return w.target.size(); }
};
void test(A3 const& a) {
static_assert(a.size() == 3); // ok
auto w0 = wrap{a};
static_assert(w0.size1() == 3); // ok
static_assert(size2(w0) == 3); // ok
static_assert(w0.size3() == 3); // ok
auto w1 = wrap{a};
static_assert(w1.size1() == 3); // ok
static_assert(size2(w1) == 3); // ok
static_assert(w1.size3() == 3); // ok
auto w2 = wrap{a};
static_assert(w2.size1() == 3); // error
static_assert(size2(w2) == 3); // error
static_assert(w2.size3() == 3); // error
}
Both gcc and clang reject the last set of assertions (wrote it every
interesting way, just in case) for trying to read through w2.target as not
being constexpr. But w2.target is an A3 const&, just like a is. And the intent
of the proposal was to allow this
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2280r4.html#the-this-pointer)
— after all we never have to read *through* the reference, we're basically just
operating on its type.
Why is this failing? Are we still missing wording to allow this or is this a
gcc/clang bug to reject?
[Bug libstdc++/120325] New: [Regression] GCC-15 cannot build LLVM 20.1.5 with CMAKE_CXX_STANDARD=20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120325
Bug ID: 120325
Summary: [Regression] GCC-15 cannot build LLVM 20.1.5 with
CMAKE_CXX_STANDARD=20
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: calvin at wbinvd dot org
Target Milestone: ---
Created attachment 61457
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61457&action=edit
Two errors
Hello all,
Building llvm-20.1.5 under the C++20 standard fails with gcc-15.1. The same
LLVM source builds successfully as C++20 with gcc-14.2.
I'm filing this for visibility, but per Jonathan Wakely's comment on the LLVM
Github issue, this likely needs to be fixed in LLVM:
https://github.com/llvm/llvm-project/issues/139072#issuecomment-2887806531
--
I ran an overnight git-bisect on gcc, and it landed here in libstdc++:
https://github.com/gcc-mirror/gcc/commit/3abe751ea86e3472fa2c97bf2014f9f93f569019
(full bisect log is in attachments).
The two error messages from GCC are attached: the first is the message I see on
the commit blamed by the bisect; the second is the error I see on the current
gcc-15 release branch. Using LLVM to build itself against libstdc++ results in
nearly identical errors as seen with gcc-15 (both compilers agree).
I'm building GCC as follows:
./configure \
--prefix="${HOME}/gcc-bisect/" \
--disable-multilib \
--enable-default-pie \
--disable-bootstrap
BOOT_CFLAGS="-Os -pipe" make -j33 -s
make install -s
...and building LLVM as follows:
cmake -G Ninja \
-DCMAKE_INSTALL_PREFIX="${HOME}/bisect-llvm-test" \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_FLAGS="-Os -pipe" \
-DCMAKE_C_COMPILER="${HOME}/gcc-bisect/bin/gcc" \
-DCMAKE_CXX_FLAGS="-Os -pipe" \
-DCMAKE_CXX_COMPILER="${HOME}/gcc-bisect/bin/g++" \
-DCMAKE_CXX_STANDARD=20 \
-DLLVM_ENABLE_PROJECTS=all \
-DLLVM_ENABLE_RUNTIMES=all \
../llvm
ninja all
[Bug target/120186] [pa] internal compiler error: in fail, at selftest.cc:47 during bootstrap with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120186 --- Comment #11 from John David Anglin --- Yes. Test results with LRA at git revision d0571638a6b are here: https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/847159.html I've just about finished check with reload at same commit.
[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013 Nathaniel Shead changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 120323, which changed state. Bug 120323 Summary: ICE when mixing #include and import std https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120323 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/120323] ICE when mixing #include and import std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120323 Nathaniel Shead changed: What|Removed |Added Resolution|--- |DUPLICATE See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99000 CC||nshead at gcc dot gnu.org Blocks||103524 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Nathaniel Shead --- Thanks for the report! This is a known issue in GCC's module implementation, see https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html: Textual merging of reachable GM entities Entities may be multiply defined across different header-units. These must be de-duplicated, and this is implemented across imports, or when an import redefines a textually-defined entity. However the reverse is not implemented—textually redefining an entity that has been defined in an imported header-unit. A redefinition error is emitted. --- In general, for now try to ensure that all #includes come before any imports that may declare the same entities; this will be particularly relevant for standard library headers of course. *** This bug has been marked as a duplicate of bug 99000 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/99000] [modules] merging of textual redefinitions: declaration std::__copy_move_a2 conflicts with import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99000 Nathaniel Shead changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120323 CC||alexander.lelyakin@googlema ||il.com --- Comment #5 from Nathaniel Shead --- *** Bug 120323 has been marked as a duplicate of this bug. ***
[Bug cobol/120328] New: Building gcobol fails in non English systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120328
Bug ID: 120328
Summary: Building gcobol fails in non English systems
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: desforn at tuta dot com
Target Milestone: ---
When building gcobol in a non English system an error message appears:
awk '! /warning, dangerous trailing context/ {print > "/dev/stderr"; nerr++}
\
END {print "flex:", NR, "messages" > "/dev/stderr";\
exit nerr}' cobol/scan.cc~
../../source/gcc/cobol/scan.l:1199: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1522: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1205: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1205: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1522: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1522: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1522: warning, Context posterior perillós
../../source/gcc/cobol/scan.l:1629: warning, Context posterior perillós
flex: 8 messages
make[3]: *** [../../source/gcc/cobol/Make-lang.in:161: cobol/scan.cc] Error 8
Using export LANGUAGE=C before building solves the problem. Adding
LC_ALL=C
export LC_ALL
LANGUAGE=C
export LANGUAGE
at gcc/cobol/Make-lang.in would solve the problem.
[Bug target/120326] problems with attribute __ms_struct__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120326 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from Andrew Pinski --- This should be rejected as the ms struct is not on the first tag.
[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305 --- Comment #17 from aneris --- Alright, I understand. Thank you again.
[Bug libstdc++/120325] [Regression] GCC-15 cannot build LLVM 20.1.5 with CMAKE_CXX_STANDARD=20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120325 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- So closing as moved.
[Bug rtl-optimization/120329] New: Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329
Bug ID: 120329
Summary: Combine temporarily creates paradoxical mem subregs
for strict-alignment targets
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitar at gcc dot gnu.org
Target Milestone: ---
Investigation for PR119966 uncovered an unusual behaviour in combine.
Paradoxical mem subregs are created for aarch64 target. But since
aarch64 is both a strict-alignment target and defines INSN_SCHEDULING,
it does not seem valid to create such paradoxical mem subregs.
To illustrate, compile the following C snippet with -O2 for aarch64:
struct S {
unsigned char c1;
unsigned char c2;
};
unsigned test(struct S *p)
{
return p->c1 | p->c2;
}
Function expand_compound_operation is called with the following insn:
(gdb) pr x
(zero_extend:SI (mem:QI (reg/f:SI 105 [ p ]) [0 p_5(D)->c1+0 S1 A8]))
Then the insn is transformed into paradoxical mem subreg, which does not seem
correct
for strict-alignment targets like aarch64:
(gdb) list
7411 tem = gen_lowpart (mode, XEXP (x, 0));
7412 if (!tem || GET_CODE (tem) == CLOBBER)
7413return x;
7414 tem = simplify_shift_const (NULL_RTX, ASHIFT, mode,
7415 tem, modewidth - pos - len);
7416 tem = simplify_shift_const (NULL_RTX, unsignedp ? LSHIFTRT :
ASHIFTRT,
7417 mode, tem, modewidth - len);
(gdb) pr tem
(subreg:SI (mem:QI (reg/f:SI 105 [ p ]) [0 p_5(D)->c1+0 S1 A8]) 0)
This is all benign because function combine_simplify_rtx invoked in subst
eventually simplifies the paradoxical mem subreg back to zero_extend:
(gdb) list
5656 /* If X is sufficiently simple, don't bother trying to do
anything
5657 with it. */
5658 if (code != CONST_INT && code != REG && code != CLOBBER)
5659x = combine_simplify_rtx (x, op0_mode, in_dest, in_cond);
5660
5661 if (GET_CODE (x) == code)
5662break;
5663
(gdb) pr x
(set (reg:SI 101 [ p_5(D)->c1 ])
(subreg:SI (mem:QI (reg/f:SI 105 [ p ]) [0 p_5(D)->c1+0 S1 A8]) 0))
(gdb) next
5661 if (GET_CODE (x) == code)
(gdb) pr x
(set (reg:SI 101 [ p_5(D)->c1 ])
(zero_extend:SI (mem:QI (reg/f:SI 105 [ p ]) [0 p_5(D)->c1+0 S1 A8])))
[Bug rtl-optimization/120329] Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329 --- Comment #1 from Andrew Pinski --- I assume you mean with -mstrict-align (otherwise STRICT_ALIGNMENT is not true for aarch64).
[Bug rtl-optimization/120329] Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329 --- Comment #2 from Dimitar Dimitrov --- Created attachment 61459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61459&action=edit validate_subreg_hardening.patch
[Bug c++/120324] Code rejected as constant due to invalid read through reference member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120324 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=118249 --- Comment #1 from Andrew Pinski --- Isn't this the same issue as mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118249#c5 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117849#c12 )?
[Bug rtl-optimization/120329] Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329 --- Comment #3 from Dimitar Dimitrov --- Alternative way to reproduce the issue is to apply the attached validate_subreg_hardening.patch to increase the checks for subregs. When the snippet from the description is built, it results in ICE: during RTL pass: combine /home/dinux/tmp/c120/test.c: In function ‘test’: /home/dinux/tmp/c120/test.c:9:1: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1042 9 | } | ^ 0x21006df internal_error(char const*, ...) ../../gcc/gcc/diagnostic-global-context.cc:517 0x83dbe9 fancy_abort(char const*, int, char const*) ../../gcc/gcc/diagnostic.cc:1815 0x480b6e gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) ../../gcc/gcc/emit-rtl.cc:1042 0x480b6e gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) ../../gcc/gcc/emit-rtl.cc:1040 0x1dfe31b expand_compound_operation ../../gcc/gcc/combine.cc:7411 0x1e0f837 subst ../../gcc/gcc/combine.cc:5659 0x1e0f696 subst ../../gcc/gcc/combine.cc:5586 0x1e13b8b try_combine ../../gcc/gcc/combine.cc:3319 0x1e1b4e1 combine_instructions ../../gcc/gcc/combine.cc:1271 0x1e1b4e1 rest_of_handle_combine ../../gcc/gcc/combine.cc:15214 0x1e1b4e1 execute ../../gcc/gcc/combine.cc:15258
[Bug tree-optimization/120322] [16 regression] wrong code at -O{s,2,3} with "-fno-early-inlining" on x86_64-linux-gnu since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120322 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120295 --- Comment #2 from Andrew Pinski --- (In reply to Sam James from comment #1) > -fno-ipa-cp works, which reminds me of PR120120, so it's probably something > latent that comes up with the missed opt? Actually it reminds me of PR 120295.
[Bug rtl-optimization/120329] Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329 --- Comment #5 from Andrew Pinski --- (In reply to Dimitar Dimitrov from comment #4) > (In reply to Andrew Pinski from comment #1) > > I assume you mean with -mstrict-align (otherwise STRICT_ALIGNMENT is not > > true for aarch64). > > I'm cross-building for armv8l-unknown-linux-gnueabihf, and STRICT_ALIGNMENT > is true by default. Sorry, I'm not well versed in the ARM variants. Am I > wrong to consider aarch64 equivalent to armv8l? Oh, armv8l is not aarch64; they are 2 different things. armv8l is still the arm (aarch32) backend but defaulting to armv8 little-endian. aarch64 is a totally different backend from the arm backend. yes it is confusing :).
[Bug tree-optimization/120322] [16 regression] wrong code at -O{s,2,3} with "-fno-early-inlining" on x86_64-linux-gnu since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120322 --- Comment #3 from Andrew Pinski --- Adding -funreachable-traps : main: .LFB3: .cfi_startproc ud2 .cfi_endproc
[Bug rtl-optimization/120329] Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329 --- Comment #4 from Dimitar Dimitrov --- (In reply to Andrew Pinski from comment #1) > I assume you mean with -mstrict-align (otherwise STRICT_ALIGNMENT is not > true for aarch64). I'm cross-building for armv8l-unknown-linux-gnueabihf, and STRICT_ALIGNMENT is true by default. Sorry, I'm not well versed in the ARM variants. Am I wrong to consider aarch64 equivalent to armv8l?
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #32 from GCC Commits --- The releases/gcc-15 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:dc21caefbc2d63be1315ca062e977affa74eacc2 commit r15-9695-gdc21caefbc2d63be1315ca062e977affa74eacc2 Author: Jerry DeLisle Date: Mon May 5 20:05:22 2025 -0700 Fortran: Fix ICE with use of c_associated. PR fortran/120049 gcc/fortran/ChangeLog: * check.cc (gfc_check_c_associated): Modify checks to avoid ICE and allow use, intrinsic :: iso_c_binding from a separate module file. gcc/testsuite/ChangeLog: * gfortran.dg/pr120049_a.f90: New test. * gfortran.dg/pr120049_b.f90: New test. (cherry picked from commit d0571638a6bad932b226ada98b167fa47a47d838)
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #33 from Jerry DeLisle --- (In reply to GCC Commits from comment #32) > The releases/gcc-15 branch has been updated by Jerry DeLisle > : Preparing for the backport of the follow-on patch.
[Bug c++/120275] [12/13/14/15/16 Regression] ICE in write_type at cp/mangle.cc:2687 when using decltype(auto) with initializer list since 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120275 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #4 from mcccs at gmx dot com --- r12-6008-g06d5dcef72542b
[Bug tree-optimization/120322] [16 regression] wrong code at -O{s,2,3} with "-fno-early-inlining" on x86_64-linux-gnu since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120322
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=120120
Version|unknown |16.0
Summary|[16 regression] wrong code |[16 regression] wrong code
|at -O{s,2,3} with |at -O{s,2,3} with
|"-fno-early-inlining" on|"-fno-early-inlining" on
|x86_64-linux-gnu|x86_64-linux-gnu since
||r16-170-ga670ebde399548
CC||hjl.tools at gmail dot com
--- Comment #1 from Sam James ---
-fno-ipa-cp works, which reminds me of PR120120, so it's probably something
latent that comes up with the missed opt?
[Bug debug/120310] Missing location for initially addressable variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120310
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Guess one case is when tree DSE removes all stores to some automatic
> addressable variable, in that case it would be nice to populate debug stmts
> to all those removed locs and state what values it had there.
> Another case is where DSE keeps some stores to it and removes others.
> If it removes the last store before the var goes out of scope, perhaps
> adding debug stmt for that is fine too, but not sure what to do in case it
> removes a store because it is overwritten by a later store, say
> void qux (int *);
> void
> baz (void)
> {
> int a = 42;
> a = 43;
> qux (&a);
> }
> Because there dse1 does
># DEBUG BEGIN_STMT
> - a = 42;
># DEBUG BEGIN_STMT
>a = 43;
> and if we add # DEBUG a => 42 we'd need to add some debug stmt to say from
> this point on, value of a is in the a variable. Not sure if # DEBUG a => a
> would do it or if we'd need something else.
Since 'a' is still in memory we do not need any # DEBUG stmts for 'a', only
when there's a time where 'a' does not reflect the value in the abstract
machine - like for example when applying loop store motion, then inside
the loop we'd technically need debug stmts. Of course I have no idea
how that will work in the end on the consumer side.
So for the original DSE issue:
a = 1; <-- DSEd
...
a = 2; <-- kept
# DEBUG a = 1
...
a = 2;
do we correctly track stores to 'a' here and get correct location lists?
IIRC the patched from Richard S. simply kept the stores?
[Bug c++/120320] g++ freezes forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120320 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-17 Status|UNCONFIRMED |NEW Keywords||compile-time-hog, ||needs-reduction CC||ppalka at gcc dot gnu.org --- Comment #1 from Richard Biener --- Confirmed. It never finishes subsumes_constraints_nonnull (), thus proving some constraints.
[Bug tree-optimization/120322] [16 regression] wrong code at -O{s,2,3} with "-fno-early-inlining" on x86_64-linux-gnu since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120322 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-17 Priority|P3 |P1 Target||x86_64-*-*
[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305 --- Comment #13 from aneris --- (In reply to Jonathan Wakely from comment #12) > tl;dr if you want to compile with strict -std=c++20 -pedantic settings, you > need to strictly follow the rules of the standard. I understand, though, at the very least, couldn't this be made a warning for -pedantic? I think that would be immensely useful. On another note, this code does compile with Clang. Apparently godbolt defaults to libstdc++ for clang instead of libc++ and that caused all the confusion. Here: https://godbolt.org/z/j6fYMdjeo I did some digging and this is because std::is_integral_v<__int128_t> is unconditionally true in libc++, unlike in libstdc++ where it's only true when the GNU extensions are enabled. So I was wondering, is it really out of the question to promote __int128_t to an integer type by default like Clang? It'd make some code more compatible.
[Bug c++/120323] ICE when mixing #include and import std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120323 Alexander Lelyakin changed: What|Removed |Added Attachment #61455|0 |1 is obsolete|| --- Comment #2 from Alexander Lelyakin --- Created attachment 61456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61456&action=edit Result of compilation with -freport-bug, gzipped
[Bug libstdc++/120305] Cannot create a std::vector from a std::ranges::transform_view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120305 --- Comment #14 from aneris --- (In reply to aneris from comment #13) > I did some digging and this is because std::is_integral_v<__int128_t> is > unconditionally true in libc++, unlike in libstdc++ where it's only true > when the GNU extensions are enabled. Ok this is not it at all. looks like libc++ defaults to a long long unsigned as the difference type for an iota_view with long unsigned.
[Bug tree-optimization/115423] Inlined strcmp optimizes poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115423 Kael Franco changed: What|Removed |Added CC||kaelfandrew at gmail dot com --- Comment #4 from Kael Franco --- Duplicate of bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313
[Bug tree-optimization/31313] consecutive strcmps are not merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313 Andrew Pinski changed: What|Removed |Added CC||blubban at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 115423 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/115423] Inlined strcmp optimizes poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115423 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Yes it is a dup. *** This bug has been marked as a duplicate of bug 31313 ***
[Bug tree-optimization/120331] match causes an extra assignment sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 --- Comment #3 from Andrew Pinski --- I think I have a patch to do this. It undoes the push but only if there is one statement in the sequence. Though we could extend it later on.
[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #13 from Andrew Pinski --- This has worked for so many other folks in the last 9 years. And there is no obvious way of reproduce it so closing as worksforme. It might be xg++ is being miscompiled by the host compiler but without any further analysis who knows.
[Bug bootstrap/53240] gcc 4.7 cross compiler build fails in libssp; link test not allowed after GCC_NO_EXECUTABLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53240 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED Severity|major |normal --- Comment #4 from Andrew Pinski --- Building cross compilers for linux has been working since GCC 5 (and the corresponding glibc release) easiler. So closing as worksforme.
[Bug target/39601] xstormy16 target broken, cannot build newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed eons ago.
[Bug bootstrap/93765] Bootstrap comparison failure; gcc/tree-vect-loop.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93765 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- I have bootstrapped on powerpc64-linux-gnu with no issues lately and so have many other folks so closing as works for me.
[Bug libstdc++/120330] New: regex: [\B] should be legal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120330
Bug ID: 120330
Summary: regex: [\B] should be legal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
int main()
{
std::regex("[\\B]");
}
Expected: Successfully construct the object; \B means nothing in [], and should
be an identity escape like \Z.
Actual:
terminate called after throwing an instance of 'std::regex_error'
what(): Unexpected character within '[...]' in regular expression
https://godbolt.org/z/z8EWWY8hP
libc++ throws the same error, but for a different reason - it doesn't implement
https://cplusplus.github.io/LWG/issue2584 at all, it throws the same error for
[\Z]. https://github.com/llvm/llvm-project/issues/99976
[Bug tree-optimization/120331] useless NON_LVALUE not fully elided by genmatch generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-17 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- I will take a look either this weekend or next.
[Bug tree-optimization/120331] New: useless NON_LVALUE not fully elided by genmatch generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331
Bug ID: 120331
Summary: useless NON_LVALUE not fully elided by genmatch
generated code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement, 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: ---
Take:
```
void g();
void f(int maxlen)
{
maxlen = maxlen > 264 ? 264 : maxlen;
if (maxlen > 16)
g();
}
```
We end up with:
```
Matching expression match.pd:197, gimple-match-6.cc:22
Matching expression match.pd:181, gimple-match-7.cc:45
Matching expression match.pd:181, gimple-match-7.cc:45
Matching expression match.pd:199, gimple-match-6.cc:54
Applying pattern match.pd:1690, gimple-match-3.cc:18989
Applying pattern match.pd:4777, gimple-match-6.cc:5116
gimple_simplified to _6 = maxlen_2(D) > 16;
_1 = _6;
```
This comes from:
```
/* x & ~0 -> x */
(simplify
(bit_and @0 integer_all_onesp)
(non_lvalue @0))
```
pattern.
The non_lvalue here is useless for gimple.
I noticed this while working on PR 120206 .
[Bug tree-optimization/120331] match causes an extra assignment sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 Andrew Pinski changed: What|Removed |Added Summary|useless NON_LVALUE not |match causes an extra |fully elided by genmatch|assignment sometimes |generated code | Keywords||compile-time-hog See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120206 Blocks|120206 | Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- So it is not due to NON_LVALUE. The problem is we start with: `MIN_EXPR > 16` gets simplified into: `_t = maxlen_2(D) > 16 _t & ~0 ` and then ~0 is removed. There is nothing to undo the removal of _t. So this is less important than I thought, I will leave it for another day. It has a small compile time performance issue though. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206 [Bug 120206] Removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison
[Bug target/44884] RX tst insn has been not fixed yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44884 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Seems to have been fixed. No clue when: _func: tst #4, r1 bne .L6 tst #1, r1 bne .L7 tst #2, r1 beq .L4 bra _f3 .balign 8,3,7 .L7: bra _f2 .balign 8,3,7 .L6: bra _f1 .balign 8,3,7 .L4: bra _f4
[Bug tree-optimization/120331] match causes an extra assignment sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 --- Comment #4 from Andrew Pinski --- Created attachment 61460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61460&action=edit Patch which I am testing
[Bug target/45000] RX signed extened unsigned char or short return value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jeffrey A. Law --- Per c#5.
[Bug target/57767] rx-unknown-elf ice of invalid %-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57767 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Jeffrey A. Law --- Tried with the trunk and gcc-4.9. Couldn't trigger in either context.
[Bug c++/120311] [12/13/14/15/16 Regression] internal compiler error: in lookup_base, at cp/search.cc:251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120311 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.5 Summary|internal compiler error: in |[12/13/14/15/16 Regression] |lookup_base, at |internal compiler error: in |cp/search.cc:251|lookup_base, at ||cp/search.cc:251 Known to work||6.3.0 Known to fail||6.4.0
[Bug c++/120311] [12/13/14/15/16 Regression] internal compiler error: in lookup_base, at cp/search.cc:251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120311 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-18 --- Comment #1 from Andrew Pinski --- Confirmed, this is 2/3 extensions which is required to get the ICE.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86811, which changed state. Bug 86811 Summary: Vax port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86811] Vax port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed long ago.
[Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |13.3 Resolution|--- |FIXED --- Comment #8 from Andrew Pinski --- Work around installed for GCC 13.3.0 so closing as fixed. It is up to clang to fix their bug ...
[Bug gcov-profile/120332] New: Line coverage for labels refers to implicit "else" clauses before it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120332
Bug ID: 120332
Summary: Line coverage for labels refers to implicit "else"
clauses before it
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: wentaoz5 at illinois dot edu
Target Milestone: ---
Hit the issue when measuring
https://sources.debian.org/src/lzo2/2.10-2/src/lzo1x_d.ch/#L166
How to reproduce:
$ gcc --version
gcc (GCC) 16.0.0 20250511 (experimental)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat > test.c << 'EOF'
int g;
void foo(int a, int b) {
if (a) {
g++;
if (b) {
g++;
} // C_else_2
} // C_else_1
// g++; // Uncommenting this changes the behavior
L1: // C_else_1 + C_else_2
if (a) {
g++;
if (b) {
g++;
} else {
g--; // C_else_2
}
} // C_else_1
// g++; // Uncommenting this changes the behavior
L2: // C_else_1
return;
}
int main(void) {
for (int i = 0; i < 1; i++)
foo(0, 0);
for (int i = 0; i < 20; i++)
foo(1, 0);
for (int i = 0; i < 300; i++)
foo(0, 1);
for (int i = 0; i < 4000; i++)
foo(1, 1);
}
EOF
$ gcc --coverage test.c -o test
$ ./test
$ gcov test
$ cat test.c.gcov
...
4321:3:void foo(int a, int b) {
4321:4:if (a) {
4020:5:g++;
4020:6:if (b) {
4000:7:g++;
-:8:} // C_else_2
-:9:} // C_else_1
-: 10:
-: 11:// g++; // Uncommenting this changes the behavior
-: 12:
321: 13:L1: // C_else_1 + C_else_2
-: 14:
4321: 15:if (a) {
4020: 16:g++;
4020: 17:if (b) {
4000: 18:g++;
-: 19:} else {
20: 20:g--; // C_else_2
-: 21:}
-: 22:} // C_else_1
-: 23:
-: 24:// g++; // Uncommenting this changes the behavior
-: 25:
301: 26:L2: // C_else_1
-: 27:
4321: 28:return;
-: 29:}
...
This is suboptimal as users generally expect (1) the same number as the next
statement (2) (less commonly) how many times this label is goto'ed.
I don't know for sure at the stage of gcov instrumentation is there still
ways of doing such mapping?
[Bug tree-optimization/120331] match causes an extra assignment sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 Andrew Pinski changed: What|Removed |Added Attachment #61460|0 |1 is obsolete|| --- Comment #6 from Andrew Pinski --- Created attachment 61461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61461&action=edit New patch which I am testing We now only undo it for gimple_simplify which takes an `gimple_match_op *` operand.
[Bug tree-optimization/120331] match causes an extra assignment sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Created attachment 61460 [details] > Patch which I am testing It has one regression though: gcc.dg/builtins-61.c . That is due to this pattern: /* cexp(x+yi) -> exp(x)*cexpi(y). */ (for cexps (CEXP) exps (EXP) cexpis (CEXPI) (simplify (cexps compositional_complex@0) (if (targetm.libc_has_function (function_c99_math_complex, TREE_TYPE (@0))) (complex (mult (exps@1 (realpart @0)) (realpart (cexpis:type@2 (imagpart @0 (mult @1 (imagpart @2))) I didn't realize you could capture part of the result and reuse that. That might be the only pattern which does that. I guess I need to rethink where to place this part.
