[Bug c++/120123] [12/13/14/15 Regression] Implicit this is not used in a requires clause in nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- Printing error since r12-6063-g30c286aa937785
[Bug target/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 --- Comment #1 from Manuel Lauss --- Bisection points to a670ebde3995481225ec62b29686ec07a21e5c10 (Drop targetm.promote_prototypes from C, C++ and Ada frontends) as culprit.
[Bug target/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 --- Comment #3 from Manuel Lauss --- Created attachment 61334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61334&action=edit fixed example code Fixed example code: removed the custom header and exchanged it with stdint.h
[Bug target/120119] [15/16 Regression] GCC 15.1.0 ICEs (segfaults) compiling VK-GL-CTS on aarch64 with -O2 -mcpu=cortex-a57 since r15-5422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120119 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target|x86_6 |x86_64-*-* --- Comment #2 from Richard Biener --- I assume you identified the core bits with the example code? Can you either reduce it to not require the not included header to compile or provide preprocesed source? Is there any obvious difference with what is reported by -fopt-info in this functions area?
[Bug tree-optimization/120122] [14/15/16 Regression] wrong code due to VCE of bool being pulled out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120122 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/120125] New: ICE when using -Os and std module together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125
Bug ID: 120125
Summary: ICE when using -Os and std module together
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: winmikedows at hotmail dot com
Target Milestone: ---
Any usage of std:: things results in an instant ICE when using `import std`
together with -Os in GCC 15.1 and above.
MVP:
```cpp
import std;
int main() {
std::vector vec;
return 0;
}
```
Reproduce commands:
```
g++ -std=c++23 -fmodules -Os -c -fmodule-only -fsearch-include-path bits/std.cc
g++ -std=c++23 -fmodules -Os hello.cpp -o hello.out
```
Output:
```
In file included from
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/bits/cpp_type_traits.h:42,
from
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/bits/stl_algobase.h:61,
from
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/algorithm:62,
from
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/x86_64-linux-gnu/bits/stdc++.h:53,
from
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/bits/std.cc:30,
of module std, imported at ../hello.cpp:1:
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/type_traits: In
substitution of 'template
std::__detail::__first_t, typename
std::enable_if<(!(bool)(_Bn::value)), void>::type ...>
std::__detail::__or_fn(int) [with _Bn = {std::is_reference
>, std::is_function >, std::is_void >,
std::__is_array_unknown_bounds >}]':
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/type_traits:199:41:
required from 'struct std::__or_ >,
std::is_function >, std::is_void >,
std::__is_array_unknown_bounds > >'
199 | : decltype(__detail::__or_fn<_Bn...>(0))
|~^~~
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/type_traits:311:13:
required by substitution of 'template
constexpr typename std::__or_,
std::is_function<_NestedType>, std::is_void<_NestedType>,
std::__is_array_unknown_bounds<_NestedType> >::type
std::__is_complete_or_unbounded(_TypeIdentity) [with _TypeIdentity =
std::__type_identity >; _NestedType = std::allocator]'
311 | >::type __is_complete_or_unbounded(_TypeIdentity)
| ^~
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/type_traits:1246:52:
required from 'struct std::is_nothrow_default_constructible
>'
1246 |
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
|
~~~^~~~
../hello.cpp:4:22: recursively required from 'constexpr std::vector<_Tp,
_Alloc>::vector() [with _Tp = int; _Alloc = std::allocator]'
4 | std::vector vec;
| ^~~
../hello.cpp:4:22: required from here
/opt/compiler-explorer/gcc-15.1.0/include/c++/15.1.0/type_traits:180:12:
internal compiler error: Segmentation fault
180 | auto __or_fn(int) -> __first_t**, int)
???:0
0x9d8b3e finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug ipa/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15 since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 Richard Biener changed: What|Removed |Added Component|target |ipa CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #5 from Richard Biener --- GCC 15 does t.c:257:10: optimized: Inlined codec47_block.constprop/17 into codec47_comp2/16 which now has time 40289.130615 and size 157, net change of -15. while GCC 16 no longer does this. Adding -fno-ipa-cp to GCC 15 causes us to recursively inline instead. But the important difference is likely that with the inlining we get a lot of complete unrolling but not without. I can imagine that IPA CP is maybe confused by the frontend no longer promoting arguments to codec47_block which receives uint16_t size.
[Bug target/80881] Implement Windows native TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 Sam James changed: What|Removed |Added Target Milestone|--- |16.0 Assignee|unassigned at gcc dot gnu.org |tanksherman27 at gmail dot com Status|NEW |ASSIGNED --- Comment #104 from Sam James --- Committed in r16-398-g0aea633e146b75.
[Bug tree-optimization/120031] Fails to pattern match ctz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120031 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5e363ffefaceb9ff8fdeeead247c8337538e01db commit r16-400-g5e363ffefaceb9ff8fdeeead247c8337538e01db Author: Richard Biener Date: Tue May 6 08:36:01 2025 +0200 tree-optimization/120031 - CTZ pattern matching fails a case This PR is about the pattern matching in tree-ssa-forwprop.cc not working for the fallback implementation in ZSTD which uses a cast aroud the negation of the value to be tested. There's a pattern eliding casts in (T')-(T)x already but that only covered an inner widening conversion. The following extends this to other conversions given the negation will then be carried out in an unsigned type. PR tree-optimization/120031 * match.pd ((nop_outer_cast)-(inner_cast)var -> -(outer_cast)(var)): Allow inner conversions that are not widenings when the outer type is unsigned. * gcc.target/i386/pr120031.c: New testcase.
[Bug target/80881] Implement Windows native TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #105 from Sam James --- The libstdc++ changes still need to be committed. I don't know what the status of those is (not looked if posted, reviewed yet, etc). I'd suggest handling that in a new bug but up to you.
[Bug target/120067] RISC-V: x264 sub4x4_dct high icount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120067 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #4 from Robin Dapp --- (In reply to Paul-Antoine Arras from comment #3) > (In reply to rdapp.gcc from comment #2) > > There is indeed a problem with =zvl that we have been discussing in the > > patchwork sync call for a while already. The issue is that we're handling > > VLS > > modes as VLA modes in certain situations resulting in unfortunate codegen. > > The > > vector extracts (slidedowns) are one example of it. > > I guess this is related to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361#c2 then. > Is there anything I could do to help with that? Yes, that's it. I don't think right now there is a lot to do for this particular issue. I have a local patch that still needs to be thoroughly tested. Going to pick it up again in a few weeks. But it will surely be helpful if you continue to weed through SPEC looking for cases where our vectorization seems dubious - either vs aarch64 or vs LLVM. SPECfp in particular hasn't seen much attention AFAICT. Same with SPEC 2006. I have looked at some of its integer benchmarks (or rather the open source applications they are derived from) but didn't spend a lot of time on it. Maybe just wait a bit before drawing definite conclusion from pure icount numbers :)
[Bug target/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15 since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 --- Comment #4 from Manuel Lauss --- I bisected and tested with the full source, but the core loop is function codec47_comp2() in example.c. The code for this function is noticeable smaller (4kB vs 6kB) with "gcc-16 -O3" compared to gcc-14/15 -O3, regardless of target (I test with haswell and znver5).
[Bug target/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #18 from Eric Botcazou --- > I believe this bug is fixed by the following commit: > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=8b26ee407613cdbfc3fb2095c09ae28b4642fd63 > > This change enables generation of GNU stack notes in gcc-12. As > similar commit was done for gcc-13. Great, thanks!
[Bug pch/14940] PCH largefile test fails on various platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 --- Comment #59 from GCC Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:16e301adf7b653c72d5c3cae1c7287877f3f20ff commit r16-399-g16e301adf7b653c72d5c3cae1c7287877f3f20ff Author: LIU Hao Date: Wed May 11 22:42:53 2022 +0800 Allow a PCH to be mapped to a different address First, try mapping the PCH to its original address. If that fails, try letting the system choose one; the PCH can be relocated thereafter. Reference: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594556.html 2022-05-11 LIU Hao Signed-off-by: Jonathan Yong <10wa...@gmail.com> PR pch/14940 gcc/ChangeLog: * config/i386/host-mingw32.cc (mingw32_gt_pch_use_address): Replace the loop that attempted to map the PCH only to its original address with more adaptive operations
[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061
--- Comment #20 from Jakub Jelinek ---
14 version:
--- gcc/testsuite/gcc.dg/plugin/plugin.exp.jj 2024-04-26 11:46:58.650218626
+0200
+++ gcc/testsuite/gcc.dg/plugin/plugin.exp 2025-05-06 10:01:10.543208267
+0200
@@ -126,7 +126,9 @@ set plugin_test_list [list \
{ location_overflow_plugin.c \
location-overflow-test-1.c \
location-overflow-test-2.c \
- location-overflow-test-pr83173.c } \
+ location-overflow-test-pr83173.c \
+ location-overflow-test-pr116047.c \
+ location-overflow-test-pr120061.c } \
{ must_tail_call_plugin.c \
must-tail-call-1.c \
must-tail-call-2.c } \
--- gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c.jj 2024-04-26
11:46:58.650218626 +0200
+++ gcc/testsuite/gcc.dg/plugin/location_overflow_plugin.c 2025-05-06
10:01:23.602029841 +0200
@@ -101,7 +101,7 @@ plugin_init (struct plugin_name_args *pl
break;
default:
- error_at (UNKNOWN_LOCATION, "unrecognized value for plugin argument");
+ break;
}
return 0;
--- gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c.jj
2025-05-06 08:56:14.311445940 +0200
+++ gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047.c
2025-05-06 09:52:37.909212363 +0200
@@ -0,0 +1,5 @@
+/* PR preprocessor/116047 */
+/* { dg-do preprocess } */
+/* { dg-options "-nostdinc -std=c23
-fplugin-arg-location_overflow_plugin-value=0x4fff8080" } */
+#include "location-overflow-test-pr116047-1.h"
+/* { dg-final { scan-file location-overflow-test-pr116047.i
"static_assert\[^\n\r]\*6\[^\n\r]\*== 6" } } */
--- gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h.jj
2025-05-06 08:57:39.624279475 +0200
+++ gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-1.h
2025-05-06 09:47:57.586042403 +0200
@@ -0,0 +1,6 @@
+
+
+
+
+#include "location-overflow-test-pr116047-2.h"
+static_assert (__LINE__ == 6, "");
--- gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h.jj
2025-05-06 08:57:52.869098384 +0200
+++ gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr116047-2.h
2025-05-05 12:27:34.907854863 +0200
@@ -0,0 +1 @@
+int i;
--- gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c.jj
2025-05-06 09:49:58.153395094 +0200
+++ gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061.c
2025-05-06 09:55:41.382705568 +0200
@@ -0,0 +1,6 @@
+/* PR preprocessor/120061 */
+/* { dg-do preprocess } */
+/* { dg-options "-nostdinc -std=c23
-fplugin-arg-location_overflow_plugin-value=0x6100" } */
+#include "location-overflow-test-pr120061-1.h"
+static_assert (__LINE__ == 5, "");
+/* { dg-final { scan-file location-overflow-test-pr120061.i
"static_assert\[^\n\r]\*5\[^\n\r]\*== 5" } } */
--- gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h.jj
2025-05-06 08:57:39.624279475 +0200
+++ gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-1.h
2025-05-06 09:55:48.417609451 +0200
@@ -0,0 +1,6 @@
+
+
+
+
+#include "location-overflow-test-pr120061-2.h"
+
--- gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h.jj
2025-05-06 08:57:52.869098384 +0200
+++ gcc/testsuite/gcc.dg/plugin/location-overflow-test-pr120061-2.h
2025-05-05 12:27:34.907854863 +0200
@@ -0,0 +1 @@
+int i;
WIth pre- r14-11679 I get on make check-gcc RUNTESTFLAGS=plugin.exp
Running /usr/src/gcc-14/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c
-fplugin=./location_overflow_plugin.so scan-file
static_assert[^\n\r]*6[^\n\r]*== 6
=== gcc Summary ===
# of expected passes916
# of unexpected failures1
# of expected failures 11
# of unsupported tests 4
and with current gcc 14 branch
Running /usr/src/gcc-14/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c
-fplugin=./location_overflow_plugin.so scan-file
static_assert[^\n\r]*5[^\n\r]*== 5
=== gcc Summary ===
# of expected passes916
# of unexpected failures1
# of expected failures 11
# of unsupported tests 4
and with patched 14 branch
Running /usr/src/gcc-14/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
=== gcc Summary ===
# of expected passes917
# of expected failures 11
# of unsupported tests 4
Now to port the test to trunk with 64-bit location_t...
[Bug ada/120110] Instantiation error record aggregate must use (), not []
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120110 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |15.0 CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixed in GCC 15 and later. I'd suggest reporting Ada 2022 issues against GCC 15 only.
[Bug c++/120126] New: Title: ICE in GCC with pack-dependent decltype in lambda: cp_type_quals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120126
Bug ID: 120126
Summary: Title: ICE in GCC with pack-dependent decltype in
lambda: cp_type_quals
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
GCC crashes when deducing the type of a lambda-captured pack using
decltype(args) inside a lambda body.
```
#include
#include
template
auto sum(Args... args){
return [args...] {
typename std::remove_reference::type
temp{std::move(args)...};
};
}
int main() {
auto min = sum(1, 10);
}
```
Stack dump
```
:6:70: internal compiler error: Segmentation fault
6 | typename std::remove_reference::type
temp{std::move(args)...};
|
^~~~
0x2031cbc internal_error(char const*, ...)
???:0
0x98c804 cp_type_quals(tree_node const*)
???:0
0x939b30 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x93cea7 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x939b7e tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9448a6 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x93247f instantiate_decl(tree_node*, bool, bool)
???:0
0x8320b7 maybe_instantiate_decl(tree_node*)
???:0
0x833277 mark_used(tree_node*, int)
???:0
0x7a0efe build_new_function_call(tree_node*, vec**, int)
???:0
0x960f4a finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x90ee14 c_parse_file()
???:0
0xa0d1b9 c_common_parse_file()
???:0
```
To reproduce:
Happens until 14.2
https://gcc.godbolt.org/z/116K67dhe
[Bug target/80881] Implement Windows native TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #106 from LIU Hao --- Both the other two patches are on the ML: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670425.html https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681957.html
[Bug c++/120127] New: ICE in GCC when calling destructor of undefined type name in lambda (lookup_template_class crash)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120127
Bug ID: 120127
Summary: ICE in GCC when calling destructor of undefined type
name in lambda (lookup_template_class crash)
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE on this code:
```
#include
struct Bomb{
};
int main(){
[[maybe_unused]] auto test = []( auto t){
return [t = std::move(t)](){t.~T();};
};
Bomb b;
auto test_with_bomb = test(std::move(b));
}
```
Stack dump
```
:6:39: internal compiler error: in lookup_template_class, at
cp/pt.cc:10406
6 | return [t = std::move(t)](){t.~T();};
| ^~
0x2287465 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x22989b6 internal_error(char const*, ...)
???:0
0x7d443e fancy_abort(char const*, int, char const*)
???:0
0x9ab456 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9ab9bc tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9abc1c tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9b8831 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x99f62f instantiate_decl(tree_node*, bool, bool)
???:0
0x894821 maybe_instantiate_decl(tree_node*)
???:0
0x895b67 mark_used(tree_node*, int)
???:0
0x806f93 build_op_call(tree_node*, vec**, int)
???:0
0x9d8b67 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x981ebd c_parse_file()
???:0
0xa8b739 c_common_parse_file()
???:0
```
To quickly reproduce, it happens in all version since 12.1, including 15.1 and
trunk
https://gcc.godbolt.org/z/rfs8qPMWv
[Bug c++/120128] New: Excesive output in recursive lambda composition, that can lead to g++:fatal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120128
Bug ID: 120128
Summary: Excesive output in recursive lambda composition, that
can lead to g++:fatal error
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
The initial program returns excesive ouput that has to be truncated by gcc
bolt, and when removing ```auto``` a ```g++: fatal error``` arises
```
#include
auto sum(const int n, auto f) {
if(n == 0) return f(2 + n);
return sum(n - 1, [&](auto i) { return f(n, i); });
}
int main() { sum(2, [](auto i, auto n) { return ns::n++; }); return 0; }
```
To reproduce excesive output:
https://gcc.godbolt.org/z/MqMbPzEbP
To reproduce g++: fatal error:
https://gcc.godbolt.org/z/M1Y6ePGTE
[Bug tree-optimization/120065] [14/15/16 Regression] profile info corrupted by dom2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120065
--- Comment #4 from Alex Coplan ---
Thanks for the analysis. I think this shows that the testcase I gave above was
overly-reduced. I should have mentioned in the initial report that this code
came from gcc/testsuite/gcc.c-torture/execute/20060420-1.c, where the loop was
originally:
for (j = 0; j < n && (((unsigned long) dst + j) & m); ++j)
{
float t = src[0][j];
for (i = 1; i < a; ++i)
t += src[i][j];
dst[j] = t;
}
which is not trivially useless code, but still ends up with an invalid profile.
It should be possible to construct a reduced testcase from the test which
shows the problem but isn't a degenerate case.
[Bug c++/120129] New: Internal Compiler Error (ICE) with decltype(auto) and nested initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129
Bug ID: 120129
Summary: Internal Compiler Error (ICE) with decltype(auto) and
nested initializer list
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Using decltype(auto) to initialize from a nested initializer list causes an
internal compiler error in GCC.
```
#include
int main(int, char**)
{
decltype(auto) m = {{"john", "doe"}};
}
```
```
:4:38: internal compiler error: in convert_like_internal, at
cp/call.cc:8874
4 | decltype(auto) m = {{"john", "doe"}};
| ^
0x293a4f5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2951766 internal_error(char const*, ...)
???:0
0xad7334 fancy_abort(char const*, int, char const*)
???:0
0xb03073 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
???:0
0xbd0b9e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xcfb063 c_parse_file()
???:0
0xe5db29 c_common_parse_file()
???:0
```
It happens since 11.3 until trunk version included.
https://gcc.godbolt.org/z/v4jbn8Pfe
[Bug c++/120130] New: Cannot declare function template as friend in the presence of same named member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120130
Bug ID: 120130
Summary: Cannot declare function template as friend in the
presence of same named member function
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program:
```
template
struct Foo;
template
void g(const Foo&) {}
template
struct Foo {
Foo g() { return *this; }
friend void g<>(const Foo&);
};
int main() {
Foo{}.g();
g(Foo{});
}
```
is accepted by Clang, but GCC rejects it with
> error: template-id 'g<>' for 'void g(const Foo&)' does not match any
> template declaration
Online demo: https://gcc.godbolt.org/z/fE9Eeoabz
Note that swapping the lines inside struct Foo makes GCC happy as well.
Found in https://stackoverflow.com/q/79607696/7325599
[Bug target/120067] RISC-V: x264 sub4x4_dct high icount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120067 Paul-Antoine Arras changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Paul-Antoine Arras --- (In reply to Robin Dapp from comment #4) > But it will surely be helpful if you continue to weed through SPEC looking > for cases where our vectorization seems dubious - either vs aarch64 or vs > LLVM. SPECfp in particular hasn't seen much attention AFAICT. Same with > SPEC 2006. I have looked at some of its integer benchmarks (or rather the > open source applications they are derived from) but didn't spend a lot of > time on it. > > Maybe just wait a bit before drawing definite conclusion from pure icount > numbers :) Thanks for the pointers, will do :) *** This bug has been marked as a duplicate of bug 119361 ***
[Bug target/119361] RISC-V: x264 satd_4x4 stack spilling with mtune=generic-ooo for vls code but not on vla code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361 Paul-Antoine Arras changed: What|Removed |Added CC||parras at gcc dot gnu.org --- Comment #5 from Paul-Antoine Arras --- *** Bug 120067 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/120031] Fails to pattern match ctz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120031 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |16.0 --- Comment #5 from Richard Biener --- Fixed.
[Bug fortran/120131] New: Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 Bug ID: 120131 Summary: Misleading and unnecessary error message due to range check Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vterzi1996 at gmail dot com Target Milestone: --- `gfortran` fails to compile the following code: ``` print*,-2147483648;end ``` It prints the error message: ``` Error: Integer too big for its kind at (1). This check can be disabled with the option ‘-fno-range-check’ ``` This error message is misleading and unnecessary, since -2147483648 is not too big for its kind and can be successfully generated with `-huge(0)-1`. `ifx` and `nvfortran` compile this code without any problems.
[Bug tree-optimization/120074] [15/16 regression] ICE on valid code at -O1 with "-fno-tree-copy-prop -fno-tree-forwprop -fno-tree-ccp" on x86_64-linux-gnu: in decompose, at wide-int.h:1049 since r15-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120074
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:81475602c3dd57ff6987e5f902814e8e3a0a0dde
commit r16-402-g81475602c3dd57ff6987e5f902814e8e3a0a0dde
Author: Jakub Jelinek
Date: Tue May 6 13:00:10 2025 +0200
gimple-fold: Fix fold_truth_andor_for_ifcombine [PR120074]
The following testcase ICEs because of a mismatch between wide_int
precision, in particular lr_and_mask has 32-bit precision while sign has
16-bit.
decode_field_reference ensures that {ll,lr,rl,rr}_and_mask has
{ll,lr,rl,rr}_bitsize precision, so the
ll_and_mask |= sign;
and
rl_and_mask |= sign;
and
ll_and_mask &= sign;
and
rl_and_mask &= sign;
cases should work right, sign has in those cases {ll,rl}_bitsize
precision. The problem is that nothing until much later guarantees
that ll_bitsize == lr_bitsize or rl_bitsize == rr_bitsize.
In the testcase there is
((b ^ a) & 3) < 0
where a is 16-bit and b is 32-bit, so it is the lsignbit handling,
and because of the xor the xor operand is moved to the *r_and_mask, so
with ll_and_mask being 16-bit 3 and lr_and_mask being 32-bit 3.
Now, either b in the above case would be INTEGER_CST, in that case
if rr_arg was also INTEGER_CST we'd use the l_const && r_const case
and try to handle it, or we'd run into (though much later)
if (ll_bitsize != lr_bitsize || rl_bitsize != rr_bitsize
...
return 0;
One possibility is dealing with a different precision using wide_int::from.
Another option used in this patch as it is safest is
+ if (ll_bitsize != lr_bitsize)
+ return 0;
if (!lr_and_mask.get_precision ())
lr_and_mask = sign;
else
lr_and_mask &= sign;
and similarly in the other hunk, i.e. punt if there is a mismatch
early.
And yet another option would be to compute
the sign
wide_int sign = wi::mask (ll_bitsize - 1, true, ll_bitsize);
/* If ll_arg is zero-extended and we're testing the sign bit, we know
what the result should be. Shifting the sign bit out of sign will
get
us to mask the entire field out, yielding zero, i.e., the sign bit
of
the zero-extended value. We know the masked value is being
compared
with zero, so the compare will get us the result we're looking
for: TRUE if EQ_EXPR, FALSE if NE_EXPR. */
if (lsignbit > ll_bitsize && ll_unsignedp)
sign <<= 1;
once again for the lr_and_mask and rr_and_mask cases using rl_bitsize.
As we just return 0; anyway unless l_const && r_const, if l_const & r_const
are false it doesn't really matter what is chosen, but for the const
cases it matters and I'm not sure what is right. So the second option
might be safest.
2025-05-06 Jakub Jelinek
PR tree-optimization/120074
* gimple-fold.cc (fold_truth_andor_for_ifcombine): For
lsignbit && l_xor case, punt if ll_bitsize != lr_bitsize.
Similarly
for rsignbit && r_xor case, punt if rl_bitsize != rr_bitsize.
Formatting fix.
* gcc.dg/pr120074.c: New test.
[Bug tree-optimization/120074] [15/16 regression] ICE on valid code at -O1 with "-fno-tree-copy-prop -fno-tree-forwprop -fno-tree-ccp" on x86_64-linux-gnu: in decompose, at wide-int.h:1049 since r15-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120074
--- Comment #6 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a14d65f81e18e70144ceddfc3142a8103984919d
commit r15-9625-ga14d65f81e18e70144ceddfc3142a8103984919d
Author: Jakub Jelinek
Date: Tue May 6 13:00:10 2025 +0200
gimple-fold: Fix fold_truth_andor_for_ifcombine [PR120074]
The following testcase ICEs because of a mismatch between wide_int
precision, in particular lr_and_mask has 32-bit precision while sign has
16-bit.
decode_field_reference ensures that {ll,lr,rl,rr}_and_mask has
{ll,lr,rl,rr}_bitsize precision, so the
ll_and_mask |= sign;
and
rl_and_mask |= sign;
and
ll_and_mask &= sign;
and
rl_and_mask &= sign;
cases should work right, sign has in those cases {ll,rl}_bitsize
precision. The problem is that nothing until much later guarantees
that ll_bitsize == lr_bitsize or rl_bitsize == rr_bitsize.
In the testcase there is
((b ^ a) & 3) < 0
where a is 16-bit and b is 32-bit, so it is the lsignbit handling,
and because of the xor the xor operand is moved to the *r_and_mask, so
with ll_and_mask being 16-bit 3 and lr_and_mask being 32-bit 3.
Now, either b in the above case would be INTEGER_CST, in that case
if rr_arg was also INTEGER_CST we'd use the l_const && r_const case
and try to handle it, or we'd run into (though much later)
if (ll_bitsize != lr_bitsize || rl_bitsize != rr_bitsize
...
return 0;
One possibility is dealing with a different precision using wide_int::from.
Another option used in this patch as it is safest is
+ if (ll_bitsize != lr_bitsize)
+ return 0;
if (!lr_and_mask.get_precision ())
lr_and_mask = sign;
else
lr_and_mask &= sign;
and similarly in the other hunk, i.e. punt if there is a mismatch
early.
And yet another option would be to compute
the sign
wide_int sign = wi::mask (ll_bitsize - 1, true, ll_bitsize);
/* If ll_arg is zero-extended and we're testing the sign bit, we know
what the result should be. Shifting the sign bit out of sign will
get
us to mask the entire field out, yielding zero, i.e., the sign bit
of
the zero-extended value. We know the masked value is being
compared
with zero, so the compare will get us the result we're looking
for: TRUE if EQ_EXPR, FALSE if NE_EXPR. */
if (lsignbit > ll_bitsize && ll_unsignedp)
sign <<= 1;
once again for the lr_and_mask and rr_and_mask cases using rl_bitsize.
As we just return 0; anyway unless l_const && r_const, if l_const & r_const
are false it doesn't really matter what is chosen, but for the const
cases it matters and I'm not sure what is right. So the second option
might be safest.
2025-05-06 Jakub Jelinek
PR tree-optimization/120074
* gimple-fold.cc (fold_truth_andor_for_ifcombine): For
lsignbit && l_xor case, punt if ll_bitsize != lr_bitsize.
Similarly
for rsignbit && r_xor case, punt if rl_bitsize != rr_bitsize.
Formatting fix.
* gcc.dg/pr120074.c: New test.
(cherry picked from commit 81475602c3dd57ff6987e5f902814e8e3a0a0dde)
[Bug tree-optimization/119977] [16 regression] Bootstrap comparison failure with -march=znver4 -ggdb3 and bootstrap-lto since r16-152-g4f7b3c24112016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119977 --- Comment #20 from Sam James --- (In reply to Sam James from comment #18) > * Bisecting between basepoints/gcc-15 and trunk for a difference in a > constant source file (reduced gimple-match-6.cc from > r16-152-g4f7b3c24112016) yields r15-7652-ga2755339c6c983. Reverting that doesn't help though at r16-152-g4f7b3c24112016, so maybe it was bogus.
[Bug ipa/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15 since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 --- Comment #6 from Manuel Lauss --- it seems the recursion of codec47_block() is confusing gcc-16 here. The full source contains other decoders structured very similar to codec47_block() but without recursion, these are as fast with gcc-16 as they are with gcc-15. The only other decoder with recursion suffers the same slowdown.
[Bug tree-optimization/120074] [15/16 regression] ICE on valid code at -O1 with "-fno-tree-copy-prop -fno-tree-forwprop -fno-tree-ccp" on x86_64-linux-gnu: in decompose, at wide-int.h:1049 since r15-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120074 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Fixed now (the more conservative way, if Alex disagrees and knows what to do for the l_const && r_const cases, it can be changed incrementally).
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086 --- Comment #9 from Jørgen Kvalsvik --- Created attachment 61335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61335&action=edit Patch: fix, printf properly on systems without %zu I just posted this on gcc-patches. It should fix the issue in gcov, could you please test it, John?
[Bug c++/120129] Internal Compiler Error (ICE) with decltype(auto) and nested initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from mcccs at gmx dot com --- Bisecting ...
[Bug target/115777] [12/13/14/15/16 regression] Severe performance regression on insertion sort at -O2 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115777 --- Comment #13 from Richard Biener --- commit 76c33109074b8e7cf6c326116b46792070122c7b (origin/master, origin/HEAD) Author: Richard Biener Date: Mon Mar 17 15:04:28 2025 +0100 tree-optimization/115 - STLF fails with BB vectorization of loop The following tries to address us BB vectorizing a loop body that swaps consecutive elements of an array like for bubble-sort. This causes the vector store in the previous iteration to fail to forward to the vector load in the current iteration since there's a partial overlap. We try to detect this situation by looking for a load to store data dependence and analyze this with respect to the containing loop for a proven problematic access. Currently the search for a problematic pair is limited to loads and stores in the same SLP instance which means the problematic load happens in the next loop iteration and larger dependence distances are not considered. On x86 with generic costing this avoids vectorizing the loop body, but once you do core-specific tuning the saved cost for the vector store vs. the scalar stores makes vectorization still profitable, but at least the STLF issue is avoided. For example on my Zen4 machine with -O2 -march=znver4 the testcase in the PR is improving from insertion_sort => 2327 to insertion_sort => 997 but plain -O2 (or -fno-tree-slp-vectorize) gives insertion_sort => 183 In the end a better target-side cost model for small vector vectorization is needed to reject this vectorization from this side. I'll note this is a machine independent heuristic (similar to the avoid-store-forwarding RTL optimization pass), I expect that uarchs implementing vectors will suffer from this kind of issue. I know some aarch64 uarchs can forward from upper/lower part stores, this isn't considered at the moment. The actual vector size/overlap distance check could be moved to a target hook if it turns out necessary. There might be the chance to use a smaller vector size for the loads avoiding the penalty rather than falling back to elementwise accesses, that's not implemented either. PR tree-optimization/115 * tree-vectorizer.h (_slp_tree::avoid_stlf_fail): New member. * tree-vect-slp.cc (_slp_tree::_slp_tree): Initialize it. (vect_print_slp_tree): Dump it. * tree-vect-data-refs.cc (vect_slp_analyze_instance_dependence): For dataflow dependent loads of a store check whether there's a cross-iteration data dependence that for sure prohibits store-to-load forwarding and mark involved loads. * tree-vect-stmts.cc (get_group_load_store_type): For avoid_stlf_fail marked loads use VMAT_ELEMENTWISE. * gcc.dg/vect/bb-slp-pr115777.c: New testcase.
[Bug target/115777] [12/13/14/15/16 regression] Severe performance regression on insertion sort at -O2 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115777 --- Comment #14 from Richard Biener --- It's not fully fixed unless you use generic tuning, so let's keep it open. Mitigation in source should be to place #pragma GCC novector before the loop. Note this only works for GCC 14 and up (that fix might be backportable, see PR25).
[Bug jit/101491] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #13 from Jason Merrill --- I would think you want just $(libsubdir)/include rather than a slightly different repetition of $(libsubdir). David, how are these headers used? Are they always compiled with the matching version of GCC (which therefore would be able to find them in $(libsubdir))?
[Bug ipa/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15 since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120
--- Comment #8 from Jan Hubicka ---
The difference is that tailr1 pass now turns recursion into loop.
GCC15 does:
Basic block 11 has extra exit edges
Basic block 33 has extra exit edges
Basic block 28 has extra exit edges
Basic block 23 has extra exit edges
Cannot handle *_15 = _16;
Basic block 19 has extra exit edges
while trunk:
Basic block 11 has extra exit edges
Basic block 33 has extra exit edges
Basic block 28 has extra exit edges
Basic block 23 has extra exit edges
Cannot handle *_15 = _16;
Basic block 19 has extra exit edges
Eliminated tail recursion in bb 6 : src_181 = codec47_block (ctx_168(D),
src_179, _40, _38, _36, w_157(D), coltbl_170(D), size_167);
It is not 100% clear to me why this happens. The recursive call in GCC 15 is
:
size_175 = size_168(D) >> 1;
_17 = (int) size_175;
_18 = (int) w_165(D);
src_180 = codec47_block (ctx_176(D), src_162, dst_172(D), p1_177(D),
p2_171(D), _18, coltbl_178(D), _17);
_21 = (sizetype) size_175;
_22 = p2_171(D) + _21;
_24 = p1_177(D) + _21;
_26 = dst_172(D) + _21;
src_182 = codec47_block (ctx_176(D), src_180, _26, _24, _22, _18,
coltbl_178(D), _17);
_29 = _17 * _18;
_30 = (sizetype) _29;
dst_183 = dst_172(D) + _30;
p1_184 = p1_177(D) + _30;
p2_185 = p2_171(D) + _30;
src_187 = codec47_block (ctx_176(D), src_182, dst_183, p1_184, p2_185, _18,
coltbl_178(D), _17);
_44 = p2_185 + _21;
_46 = p1_184 + _21;
_48 = dst_183 + _21;
src_189 = codec47_block (ctx_176(D), src_187, _48, _46, _44, _18,
coltbl_178(D), _17);
goto ; [INV]
...
:
# src_136 = PHI
col ={v} {CLOBBER(eos)};
return src_136;
while trunk:
:
size_175 = size_168(D) >> 1;
_17 = (int) size_175;
_18 = (int) w_165(D);
src_180 = codec47_block (ctx_176(D), src_162, dst_172(D), p1_177(D),
p2_171(D), _18, coltbl_178(D), _17);
_21 = (sizetype) size_175;
_22 = p2_171(D) + _21;
_24 = p1_177(D) + _21;
_26 = dst_172(D) + _21;
src_182 = codec47_block (ctx_176(D), src_180, _26, _24, _22, _18,
coltbl_178(D), _17);
_29 = _17 * _18;
_30 = (sizetype) _29;
dst_183 = dst_172(D) + _30;
p1_184 = p1_177(D) + _30;
p2_185 = p2_171(D) + _30;
src_187 = codec47_block (ctx_176(D), src_182, dst_183, p1_184, p2_185, _18,
coltbl_178(D), _17);
_44 = p2_185 + _21;
_46 = p1_184 + _21;
_48 = dst_183 + _21;
src_189 = codec47_block (ctx_176(D), src_187, _48, _46, _44, _18,
coltbl_178(D), _17);
goto ; [INV]
...
:
# src_128 = PHI
col ={v} {CLOBBER(eos)};
return src_128;
but the loop introduced by the tail recursion pass turns pass-thru to
non-pass-thru and we lose recursive cloning opurtunity.
[Bug c++/120130] Cannot declare function template as friend in the presence of same named member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120130 --- Comment #1 from Andrew Pinski --- MSVC and EDG both reject it too for similar reasons as GCC.
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #7) > I will verify now that the M2 issue is related to enabling LRA. The M2 issue is indeed related to LRA. Will test Fortran now.
[Bug ipa/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15 since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 Jan Hubicka changed: What|Removed |Added Last reconfirmed||2025-05-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #7 from Jan Hubicka --- It is indeed jump function gone missing. we also seem to lose a value range info. Jump functions: Jump functions of caller codec47_comp2/16: @@ -216,7 +198,7 @@ Unknown VR param 6: PASS THROUGH: 6, op nop_expr Unknown VR - param 7: UNKNOWN + param 7: PASS THROUGH: 7, op rshift_expr 1 (in type uint16_t) [irange] uint16_t [0, 32767] MASK 0x7fff VALUE 0x0 callsite codec47_block/15 -> codec47_block/15 : param 0: PASS THROUGH: 0, op nop_expr @@ -233,13 +215,13 @@ Unknown VR param 6: PASS THROUGH: 6, op nop_expr Unknown VR - param 7: UNKNOWN + param 7: PASS THROUGH: 7, op rshift_expr 1 (in type uint16_t) [irange] uint16_t [0, 32767] MASK 0x7fff VALUE 0x0 callsite codec47_block/15 -> codec47_block/15 : param 0: PASS THROUGH: 0, op nop_expr Unknown VR param 1: UNKNOWN -[prange] uint8_t * [1, +INF] + Unknown VR @@ -250,25 +232,58 @@ Unknown VR param 6: PASS THROUGH: 6, op nop_expr Unknown VR - param 7: UNKNOWN + param 7: PASS THROUGH: 7, op rshift_expr 1 (in type uint16_t) +[irange] uint16_t [0, 32767] MASK 0x7fff VALUE 0x0 +callsite codec47_block/15 -> codec47_block/15 : + param 0: PASS THROUGH: 0, op nop_expr, agg_preserved + Unknown VR + param 1: PASS THROUGH: 1, op pointer_plus_expr 1 (in type uint8_t *) +[prange] uint8_t * [1, +INF] + param 2: PASS THROUGH: 2, op nop_expr, agg_preserved + Unknown VR + param 3: PASS THROUGH: 3, op nop_expr, agg_preserved + Unknown VR + param 4: PASS THROUGH: 4, op nop_expr, agg_preserved + Unknown VR + param 5: PASS THROUGH: 5, op nop_expr + Unknown VR + param 6: PASS THROUGH: 6, op nop_expr, agg_preserved + Unknown VR + param 7: PASS THROUGH: 7, op rshift_expr 1 (in type uint16_t)
[Bug tree-optimization/120132] New: JMP to target function from the middle of the current if the results layout are compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120132
Bug ID: 120132
Summary: JMP to target function from the middle of the current
if the results layout are compatible
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following example:
struct A {
int i;
};
const A& f();
A g();
int test1(bool cond) {
const A& a = cond ? f() : g();
return a.i;
}
GCC-15 produces the following assembly:
test1(bool):
sub rsp, 8
test dil, dil
je .L2
call f()
mov eax, DWORD PTR [rax]
add rsp, 8
ret
.L2:
call g()
add rsp, 8
ret
However, a more optimal assembly would be:
test1(bool):
test dil, dil
je g()
sub rsp, 8
call f()
mov eax, DWORD PTR [rax]
add rsp, 8
ret
There's now less instructions in total and g() is now faster to execute if cond
== false.
Godbolt playground: https://godbolt.org/z/64xsq738s
[Bug target/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #19 from John David Anglin --- This fixed problems with my ada build which doesn't have the Debian patches: === acats Summary === # of expected passes2328 # of unexpected failures0 Native configuration is hppa-unknown-linux-gnu But there are numerous problems with Debian build... === acats tests === Running chapter a ... FAIL: ac3106a FAIL: ad7001b FAIL: ad7101c FAIL: ae2113b Running chapter c2 ... FAIL: c23006d FAIL: c23006g FAIL: c24003a FAIL: c24203a
[Bug c++/120134] New: internal compiler error: in coerce_template_parms, at cp/pt.cc:9488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120134
Bug ID: 120134
Summary: internal compiler error: in coerce_template_parms, at
cp/pt.cc:9488
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 61338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61338&action=edit
reduced test case
Encountered this ICE while trying to cvise a different ICE.
template struct A;
template int B;
B < {
Compile with -std=gnu++20.
:3:5: internal compiler error: in coerce_template_parms, at
cp/pt.cc:9488
3 | B < {
| ^
0x293a4f5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2951766 internal_error(char const*, ...)
???:0
0xad7334 fancy_abort(char const*, int, char const*)
???:0
0xd1f83b lookup_template_variable(tree_node*, tree_node*, int)
???:0
0xcfb063 c_parse_file()
???:0
0xe5db29 c_common_parse_file()
???:0
Live: https://godbolt.org/z/9sasMYKbc [May 6th, 2025]
[Bug other/116176] SARIF output doesn't yet capture nesting of logical locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116176 --- Comment #3 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f25e178b8c2cc868168b0a29ab03260fbefa4ff7 commit r16-414-gf25e178b8c2cc868168b0a29ab03260fbefa4ff7 Author: David Malcolm Date: Tue May 6 09:26:18 2025 -0400 sarif output: capture nesting of logical locations [PR116176] Previously our SARIF output did not capture nesting of logical locations: any time a result or event referred to a logical location it would simply put a copy of the logical location into the pertinent location object without a "parentIndex" property. With this patch we instead populate such locations with minimal logical locations with an "index" that refers to theRuns.logicalLocations, populating theRuns.logicalLocations with the full logical locations, including "parentIndex", recursively adding entries for the ancestor locations as needed, so that the SARIF output captures the hierarchical structure of the logical locations. gcc/ChangeLog: PR other/116176 * diagnostic-format-sarif.cc (class sarif_array_of_unique): New template. (class sarif_logical_location): Move here from diagnostic-format-sarif.h. (sarif_builder::m_cached_logical_locs): New. (sarif_builder::sarif_builder): Initialize it. (sarif_builder::set_any_logical_locs_arr): Call make_minimal_sarif_logical_location rather than make_sarif_logical_location_object. (sarif_property_bag::set_logical_location): Likewise. (make_sarif_logical_location_object): Replace with... (sarif_builder::ensure_sarif_logical_location_for): ...this. Capture "parentIndex" property. Consolidate into theRuns.logicalLocations. (sarif_builder::make_minimal_sarif_logical_location): New. (sarif_builder::make_run_object): Add "index" properties to m_cached_logical_locs and move it to theRuns.logicalLocations. (selftest::test_sarif_array_of_unique_1): New. (selftest::test_sarif_array_of_unique_2): New. (selftest::diagnostic_format_sarif_cc_tests): Call the new selftests. * diagnostic-format-sarif.h (class sarif_logical_location): Move to diagnostic-format-sarif.cc. (make_sarif_logical_location_object): Drop decl. * json.cc (value::compare): New. (object::compare): New. (selftest::fail_comparison): New. (selftest::assert_json_equal): New. (ASSERT_JSON_EQ): New. (selftest::assert_json_non_equal): New. (ASSERT_JSON_NE): New. (selftest::test_comparisons): New. (selftest::json_cc_tests): Call the new selftest. * json.h (json::value::dyn_cast_object): New vfunc. (json::object::dyn_cast_object): New vfunc impl. (json::object::compare): New decl. * libgdiagnostics.cc (impl_logical_location_manager::get_parent): New. * logical-location.h (logical_location_manager::get_parent): New vfunc impl. * selftest-logical-location.h (test_logical_location_manager::get_parent): New vfunc impl. * tree-logical-location.cc (assert_valid_tree): New. (tree_logical_location_manager::get_short_name): Support types as well as decls. (tree_logical_location_manager::get_name_with_scope): Gracefully handle non-decl nodes. (tree_logical_location_manager::get_internal_name): Likewise. (tree_logical_location_manager::get_kind): Don't attempt to handle null nodes. Handle NAMESPACE_DECL and RECORD_TYPE. (tree_logical_location_manager::get_name_for_path_output): Gracefully handle non-decl nodes. (tree_logical_location_manager::get_parent): New. * tree-logical-location.h (tree_logical_location_manager::get_parent): New vfunc impl. gcc/testsuite/ChangeLog: PR other/116176 * g++.dg/sarif-output/logical-locations-1.C: New test. * g++.dg/sarif-output/logical-locations-1.py: New test script. * g++.dg/sarif-output/logical-locations-2.C: New test. * g++.dg/sarif-output/logical-locations-2.py: New test script. * g++.dg/sarif-output/logical-locations-3.C: New test. * g++.dg/sarif-output/logical-locations-3.py: New test script. * g++.dg/sarif-output/sarif-output.exp: New script, adapted from gcc.dg/sarif-output/sarif-output.exp. * libgdiagnostics.dg/test-logical-location-c.py: Update for using theRun.logicalLocations. * libgdiagnostics.dg/test-warning-with-path-c.py: Likewise. S
[Bug tree-optimization/120032] Fails to pattern match clz from DeBruijn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120032 --- Comment #2 from Richard Biener --- I'll note that we might want to match 31 - clz (val) aka the table lookup, not 31 - table_lookup, as that will better in case the result is offset by a constant or a variable where the latter would eventually re-associate the '31 - ..' from the expression.
[Bug sarif-replay/117988] RFE: Logical locations for sarif-replay errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117988 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:52fe9502eb153f87154cfcb6a58ab84164d7e1d9 commit r16-416-g52fe9502eb153f87154cfcb6a58ab84164d7e1d9 Author: David Malcolm Date: Tue May 6 09:26:19 2025 -0400 json: implement JSON pointer; use it in sarif-replay [PR117988] This patch extends our json class to track JSON pointers (RFC 6901), and then uses this within sarif-replay to provide logical locations within the JSON when reporting on issues in the SARIF. gcc/ChangeLog: PR sarif-replay/117988 * json.cc (json::pointer::token::token): New ctors. (json::pointer::token::~token): New. (json::pointer::token::operator=): New. (json::object::set): Set the value's m_pointer_token. (json::array::append): Likewise. * json.h (json::pointer::token): New struct. (json::value::get_pointer_token): New accessor. (json::value::m_pointer_token): New field. * libsarifreplay.cc (get_logical_location_kind_for_json_kind): New. (make_logical_location_from_jv): New. (sarif_replayer::report_problem): Set the logical location of the diagnostic. gcc/testsuite/ChangeLog: PR sarif-replay/117988 * sarif-replay.dg/2.1.0-invalid/3.1-not-an-object.sarif: Add expected logical location. * sarif-replay.dg/2.1.0-invalid/3.11.11-missing-arguments-for-placeholders.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.11.11-not-enough-arguments-for-placeholders.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.11.5-unescaped-braces.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.13.2-no-version.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.13.2-version-not-a-string.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.13.4-bad-runs.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.13.4-no-runs.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.13.4-non-object-in-runs.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.27.10-bad-level.sarif: Likewise. * sarif-replay.dg/2.1.0-invalid/3.33.3-index-out-of-range.sarif: Likewise. * sarif-replay.dg/2.1.0-unhandled/3.27.10-none-level.sarif: Likewise. Signed-off-by: David Malcolm
[Bug sarif-replay/117988] RFE: Logical locations for sarif-replay errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117988
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #3 from David Malcolm ---
Implemented by the above patch for GCC 16.
Example:
$ LD_LIBRARY_PATH=. ./sarif-replay -fjson-comments
../../src/gcc/testsuite/sarif-replay.dg/2.1.0-invalid/3.27.10-bad-level.sarif
In JSON property '/runs/0/results/0/level':
../../src/gcc/testsuite/sarif-replay.dg/2.1.0-invalid/3.27.10-bad-level.sarif:12:20:
error: unrecognized value for 'level': 'mostly harmless' [SARIF v2.1.0
§3.27.10]
12 | "level": "mostly harmless", /* { dg-error "unrecognized value
for 'level': 'mostly harmless' \\\[SARIF v2.1.0 §3.27.10\\\]" } */
|^
[Bug other/116176] SARIF output doesn't yet capture nesting of logical locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116176 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be implemented by the above patch for GCC 16.
[Bug c++/120108] Feature request: Command-line option to rename module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120108 Nathaniel Shead changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114461 Severity|normal |enhancement Blocks||103524 CC||nshead at gcc dot gnu.org --- Comment #1 from Nathaniel Shead --- As you say, given that the restriction is designed to assist build systems, for a build system where this is not needed having some way to work around this as an extension seems potentially reasonable. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125
Nathaniel Shead changed:
What|Removed |Added
Last reconfirmed||2025-05-06
Status|UNCONFIRMED |NEW
CC||nshead at gcc dot gnu.org
Ever confirmed|0 |1
Keywords|needs-reduction |ice-on-valid-code
Summary|ICE when using -Os and std |[15/16 Regression] ICE in
|module together |add_to_same_comdat_group
||when using -Os or
||-fdeclone-ctor-dtor
--- Comment #1 from Nathaniel Shead ---
Reduced:
// vector.cpp
export module vector;
export extern "C++" {
template struct __shared_ptr {
__shared_ptr() {}
};
template class __shared_ptr;
template
struct vector {
friend __shared_ptr;
};
}
// main.cpp
import vector;
vector vec;
$ g++ -fmodules -S -fdeclone-ctor-dtor vector.cpp main.cpp
main.cpp:2:1: internal compiler error: Segmentation fault
2 | vector vec;
| ^~
0x3d40fdf internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x1d6f7a8 crash_signal
../../gcc/gcc/toplev.cc:321
0x7f52dc05b32f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x15ca46f symtab_node::add_to_same_comdat_group(symtab_node*)
../../gcc/gcc/symtab.cc:492
0x11d3505 maybe_thunk_body
../../gcc/gcc/cp/optimize.cc:314
0x11d5580 maybe_clone_body(tree_node*)
../../gcc/gcc/cp/optimize.cc:561
0x135039f expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.cc:5508
0x13506e4 expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.cc:5543
0x11855fc post_load_processing
../../gcc/gcc/cp/module.cc:19241
0x118bb92 lazy_load_binding(unsigned int, tree_node*, tree_node*,
binding_slot*)
../../gcc/gcc/cp/module.cc:21122
0x11a8459 name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.cc:929
0x11a9226 name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.cc:1159
0x11c5d9c lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.cc:8128
0xf3d11d lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:410
0x12207c5 cp_parser_lookup_name
../../gcc/gcc/cp/parser.cc:33039
0x12027ff cp_parser_template_name
../../gcc/gcc/cp/parser.cc:19930
0x1201ad4 cp_parser_template_id
../../gcc/gcc/cp/parser.cc:19537
0x1213477 cp_parser_class_name
../../gcc/gcc/cp/parser.cc:27434
0x11e4803 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.cc:7704
0x11e3bac cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.cc:7390
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982 since r16-244-gce489c870bf28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048 --- Comment #12 from GCC Commits --- The releases/gcc-15 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:b6f68c04f440f981b281c5ad4c335761bc7d2882 commit r15-9629-gb6f68c04f440f981b281c5ad4c335761bc7d2882 Author: Andrew MacLeod Date: Fri May 2 15:48:08 2025 -0400 Allow IPA_CP to handle UNDEFINED as VARYING. When applying a bitmask to reflect ranges, it is sometimes deferred and this can result in an UNDEFINED result. IPA is not expecting this, and add a check for it, and convert to VARYING if encountered. PR tree-optimization/120048 gcc/ * ipa-cp.cc (ipcp_store_vr_results): Check for UNDEFINED. gcc/testsuite/ * gcc.dg/pr120048.c: New.
[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982 since r16-244-gce489c870bf28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048 --- Comment #13 from GCC Commits --- The releases/gcc-14 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:93b85bdf830477fec8db1d8afcaca13530776161 commit r14-11745-g93b85bdf830477fec8db1d8afcaca13530776161 Author: Andrew MacLeod Date: Mon May 5 12:17:13 2025 -0400 Allow IPA_CP to handle UNDEFINED as VARYING. When applying a bitmask to reflect ranges, it is sometimes deferred and this can result in an UNDEFINED result. IPA is not expecting this, and add a check for it, and convert to VARYING if encountered. PR tree-optimization/120048 gcc/ * ipa-cp.cc (ipcp_store_vr_results): Check for UNDEFINED. gcc/testsuite/ * gcc.dg/pr120048.c: New.
[Bug c++/120129] Internal Compiler Error (ICE) with decltype(auto) and nested initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129 --- Comment #2 from mcccs at gmx dot com --- Bisection-found commit: r12-6008-g06d5dcef72542b Reducing
[Bug c++/120135] New: Strange -Wunitialized behavior with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135 Bug ID: 120135 Summary: Strange -Wunitialized behavior with struct Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andrew.bell.ia at gmail dot com Target Milestone: --- The following code (Goldbolt) reports a warning with -Wuninitialized despite the fact that an explicit constructor has been called. Strangely, this only happens if the structure is an aggregate. If the structure only contains a single member, no warning is emitted. I would think that invoking an explicit constructor would eliminate any -Wuninitialized warnings and I would at least expect it to work consistently. https://godbolt.org/z/1G46r7785 This behavior seems to exist from 13.1 -> current trunk.
[Bug c++/120129] Internal Compiler Error (ICE) with decltype(auto) and nested initializer list since r12-6008-g06d5dcef72542b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129 Sam James changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Summary|Internal Compiler Error |Internal Compiler Error |(ICE) with decltype(auto) |(ICE) with decltype(auto) |and nested initializer list |and nested initializer list ||since ||r12-6008-g06d5dcef72542b --- Comment #3 from Sam James --- Rejected in 11.2, ICEs in 11.3+.
[Bug c++/120129] Internal Compiler Error (ICE) with decltype(auto) and nested initializer list since r12-6008-g06d5dcef72542b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129 --- Comment #5 from mcccs at gmx dot com --- Created attachment 61339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61339&action=edit reduced.cpp
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 --- Comment #5 from Vladimir Terzi --- After a fruitful discussion in Stack Overflow, I understand that the model set of integers in Fortran is symmetric about zero according to the formula in section 16.4 of https://j3-fortran.org/doc/year/24/24-007.pdf , and, therefore, `gfortran` may reject the literal -2147483648 (although it is inconvenient and there are no technical reasons to reject it). But it was already known in 2006 that this change will cause "bogus bug reports" (like written in https://gcc.gnu.org/legacy-ml/fortran/2006-09/msg8.html) and there are already multiple of such reports on this site. Then why wasn't the error message clarified?
[Bug c++/120135] Strange -Wuninitialized behavior with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135 --- Comment #1 from Andrew Pinski --- Created attachment 61340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61340&action=edit Testcase from the godbolt link Next time please attach the testcase. Note bugzilla has a way to paste in the attachment so you can use that if you want not to upload a file.
[Bug ipa/119852] The output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119852 --- Comment #3 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:fb5829a01651d427a63a12c44ecc8baa47dbfc83 commit r16-420-gfb5829a01651d427a63a12c44ecc8baa47dbfc83 Author: Martin Jambor Date: Tue May 6 17:28:43 2025 +0200 ipa: Do not emit info about temporary clones to ipa-clones dump (PR119852) As described in PR 119852, the output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning when we need to create a clone to hold the original function during recursive inlining. Such clone is never output and so should not be part of the dump output either. gcc/ChangeLog: 2025-04-23 Martin Jambor PR ipa/119852 * cgraphclones.cc (dump_callgraph_transformation): Document the function. Do not dump if suffix is NULL. gcc/testsuite/ChangeLog: 2025-04-23 Martin Jambor PR ipa/119852 * gcc.dg/ipa/pr119852.c: New test.
[Bug c++/120129] Internal Compiler Error (ICE) with decltype(auto) and nested initializer list since r12-6008-g06d5dcef72542b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2025-05-06 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Marek Polacek --- Mine then.
[Bug ipa/119852] The output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119852 --- Comment #4 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:76c882e341cb330a4e9f677a8c3541d573820255 commit r16-422-g76c882e341cb330a4e9f677a8c3541d573820255 Author: Martin Jambor Date: Tue May 6 17:28:44 2025 +0200 ipa: Drop the default value of suffix parameter of create_clone (PR119852) In PR 119852 we agreed that since the NULL-ness of the suffix parameter should prevent creation of a record in the ipa-clones dump (which is implemented by a previous patch), it should not default to NULL. gcc/ChangeLog: 2025-04-25 Martin Jambor PR ipa/119852 * cgraph.h (cgraph_node::create_clone): Remove the default value of argument suffix. Update function comment. * cgraphclones.cc (cgraph_node::create_clone): Update function comment. * ipa-inline-transform.cc (clone_inlined_nodes): Pass NULL to suffix of create_clone explicitely. * ipa-inline.cc (recursive_inlining): Likewise. * lto-cgraph.cc (input_node): Likewise.
[Bug c++/120133] internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120133 --- Comment #2 from mcccs at gmx dot com --- bisecting
[Bug fortran/119928] [15/16 Regression] Bogus "Interface mismatch" in gfortran.dg/proc_ptr_52.f90 with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928 --- Comment #2 from GCC Commits --- The master branch has been updated by Thomas Koenig : https://gcc.gnu.org/g:e7a2b8b76ae0c8f1e49c780aa82ebb5f0325f515 commit r16-423-ge7a2b8b76ae0c8f1e49c780aa82ebb5f0325f515 Author: Thomas Koenig Date: Tue May 6 18:05:41 2025 +0200 Fix PR 119928, formal arguments used to wrongly inferred for CLASS. The problem was indeed that generating a formal from an actual arglist is a bad idea when classes are involved. Fixed in the attached patch. I think it still makes sense to remove the checks when the other attributes are present (or PR96073 may come back in different guise, even if I have to test case at present). I have also converted the test to a run-time check. gcc/fortran/ChangeLog: PR fortran/119928 * interface.cc (gfc_check_dummy_characteristics): Do not issue error if one dummy symbol has been generated from an actual argument and the other one has OPTIONAL, INTENT, ALLOCATABLE, POINTER, TARGET, VALUE, ASYNCHRONOUS or CONTIGUOUS. (gfc_get_formal_from_actual_arglist): Do nothing if symbol is a class. gcc/testsuite/ChangeLog: PR fortran/119928 * gfortran.dg/interface_60.f90: New test.
[Bug c++/120136] New: internal compiler error: tree check: accessed elt 1 of 'tree_vec' with -1 elts in add_to_template_args, at cp/pt.cc:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120136
Bug ID: 120136
Summary: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with -1 elts in add_to_template_args, at
cp/pt.cc:612
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Created attachment 61341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61341&action=edit
reduced test case
Encountered via cvise while trying to reduce a difference ICE. Compile with
c++20.
```
template
concept car = true;
template
struct set {
static auto contains(car auto x) {
return ((x == xs) || ...);
}
};
template
struct foo {
template
friend bool operator==(foo, foo);
};
template foo foobar;
auto a = foobar<1>;
auto b = set{};
auto c = b.contains(a);
```
Live: https://godbolt.org/z/q1b6746vb [May 6th, 2025]
: In substitution of 'template, >]
c> bool operator==(foo<1>, foo) [with auto [requires ::car<, >]
c = ]':
:7:20: required from 'static auto set::contains(auto:1) [with
auto:1 = foo<1>; auto ...xs = {foo<1>()}]'
7 | return ((x == xs) || ...);
| ~~~^~
:21:20: required from here
21 | auto c = b.contains(a);
| ~~^~~
:7:20: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with -1 elts in add_to_template_args, at cp/pt.cc:612
7 | return ((x == xs) || ...);
| ~~~^~
0x293a4f5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2951766 internal_error(char const*, ...)
???:0
0x9e0ef3 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
???:0
0xd1c098 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int, tree_node*)
???:0
0xd5ac0f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xb114d6 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xdbbcf2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xd444e4 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0xd25add instantiate_decl(tree_node*, bool, bool)
???:0
0xbdea93 maybe_instantiate_decl(tree_node*)
???:0
0xbe0787 mark_used(tree_node*, int)
???:0
0xaf7ed3 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xd7c639 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xcfb063 c_parse_file()
???:0
0xe5db29 c_common_parse_file()
???:0
[Bug tree-optimization/120135] Strange -Wuninitialized behavior with struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135 --- Comment #2 from Andrew Pinski --- The warning is correct. SRA makes some odd decisions which causes the diagnostic to sometimes show up and sometimes does not show up.
[Bug c++/120112] -Wmismatched-tags -Wnamespaces leads to internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120112 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ccf0b93b3ccf67b98fbd5096852c369d2cac7904 commit r16-424-gccf0b93b3ccf67b98fbd5096852c369d2cac7904 Author: Jonathan Wakely Date: Tue May 6 12:47:32 2025 +0100 libstdc++: Fix -Wmismatched-tags warnings for _Safe_iterator [PR120112] This causes an ICE as shown in the PR, but it should be fixed in the library code anyway. libstdc++-v3/ChangeLog: PR c++/120112 * include/bits/ptr_traits.h (_Safe_iterator_base): Use class keyword in class-head of declaration. * include/debug/debug.h (_Safe_iterator): Likewise.
[Bug libstdc++/119667] libstdc++ configure checks for libbacktrace need atomics for void* and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119667 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:86627faec10da53d7532805019e5296fcf15ac09 commit r16-427-g86627faec10da53d7532805019e5296fcf15ac09 Author: Jonathan Wakely Date: Fri Apr 25 21:09:18 2025 +0100 libstdc++: Rewrite atomic builtin checks [PR70560] Currently the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro checks for a variety of __atomic built-ins for bool, short and int. If all those checks pass, then it defines _GLIBCXX_ATOMIC_BUILTINS and uses the definitions from config/cpu/generic/atomicity_builtins/atomicity.h for the non-inline versions of __exchange_and_add and __atomic_add that get compiled into libsupc++. However, the config/cpu/generic/atomicity_builtins/atomicity.h definitions only depend on __atomic_fetch_add not on __atomic_test_and_set or __atomic_compare_exchange. And they only operate on a variable of type _Atomic word, which is not necessarily one of bool, short or int (e.g. for sparcv9 _Atomic_word is 64-bit long). This means that for a target where _Atomic_word is int but there are no 1-byte or 2-byte atomic instructions, GLIBCXX_ENABLE_ATOMIC_BUILTINS will fail the checks for bool and short and not define the macro _GLIBCXX_ATOMIC_BUILTINS. That means that we will use a single global mutex for reference counting in the COW std::string and std::locale, even though we could use __atomic_fetch_add to do it lock-free. This commit removes most of the GLIBCXX_ENABLE_ATOMIC_BUILTINS checks, so that it only checks __atomic_fetch_add on _Atomic_word. The macro defined by GLIBCXX_ENABLE_ATOMIC_BUILTINS is renamed from _GLIBCXX_ATOMIC_BUILTINS to _GLIBCXX_ATOMIC_WORD_BUILTINS to better reflect what it really means. This will enable the inline versions of __exchange_and_add and __atomic_add for more targets. This is not an ABI change, because targets which didn't previously use the inline definitions of those functions made non-inlined calls to the functions in the library. If the definitions of those functions now start using atomics, that doesn't change the semantics for the code calling those functions. On affected targets, new code compiled after this change will see the _GLIBCXX_ATOMIC_WORD_BUILTINS macro and so will use the always-inline versions of __exchange_and_add and __atomic_add, which use __atomic_fetch_add directly. That is also compatible with older code which still calls the non-inline definitions, because those non-inline definitions now also use __atomic_fetch_add. The only configuration where this could be an ABI change is for a target which previously defined _GLIBCXX_ATOMIC_BUILTINS (because all the atomic built-ins for bool, short and int are supported), but which defines _Atomic_word to some other type for which __atomic_fetch_add is /not/ supported. Such a target would have called the inline functions using __atomic_fetch_add, which would actually have depended on libatomic (which is what the configure checks were supposed to prevent!). After this change, that target would not define the new macro, _GLIBCXX_ATOMIC_WORD_BUILTINS, and so would make non-inline calls into the library where __exchange_and_add and __atomic_add would use the global mutex. That would be an ABI break. I don't consider that a realistic scenario, because it wouldn't have made any sense to define _Atomic_word to a wider type than int, when doing so would have required libatomic to make libstdc++.so work. Surely such a target would have just used int for its _Atomic_word type. The GLIBCXX_ENABLE_BACKTRACE macro currently uses the glibcxx_ac_atomic_int variable defined by the checks that this commit removes from GLIBCXX_ENABLE_ATOMIC_BUILTINS. That wasn't a good check anyway, because libbacktrace actually depends on atomic loads+stores for pointers as well as int, and for atomic stores for size_t. This commit replaces the glibcxx_ac_atomic_int check with a proper test for all the required atomic operations on all three of int, void* and size_t. This ensures that the libbacktrace code used for std::stacktrace will either use native atomics, or implement those loads and stores only in terms of __sync_bool_compare_and_swap (possibly requiring that to come from libatomic or elsewhere). libstdc++-v3/ChangeLog: PR libstdc++/70560 PR libstdc++/119667 * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Only check for __atomic_fetch_add on _Atomic_word. Define new macro _GLIBCXX_ATOMIC_WORD_BUILTINS and stop defining macro _GLIBCXX_ATOMIC_BUILTINS. (GLIBCXX_ENABLE_BACKTRACE): Check for __atomic_load_n and __atomic_store_n on int, void* and siz
[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029 --- Comment #8 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a067cbcdcc5f599a2b7d607e89674533d23c652d commit r16-425-ga067cbcdcc5f599a2b7d607e89674533d23c652d Author: Jonathan Wakely Date: Wed Apr 30 17:31:01 2025 +0100 libstdc++: Fix dangling pointer in fs::path::operator+=(*this) [PR120029] When concatenating a path we reallocate the left operand's storage to make room for the new components being added. When the two operands are the same object, or the right operand is one of the components of the left operand, the reallocation invalidates the pointers that refer into the right operand's storage. The solution in this commit is to detect these aliasing cases and just do the concatenation in terms of the contained string, as that code already handles the case where the string aliases the path. The standard specifies the concatenation in terms of the native() string, so all this change does is disable the optimized implementation of concatenation for path objects which attempts to avoid re-parsing the path from the concatenated string. The potential loss of performance for this case isn't likely to be an issue, because concatenating a path with itself (or one of its existing components) probably isn't a common use case. The Filesystem TS implementation doesn't have the optimized form of concatenation and always does it in terms of the native string and reparsing the whole thing, so doesn't have this bug. A test is added to confirm that anyway (that test has some slightly different results due to different behaviour for trailing slashes and implicit "." filenames in the TS spec). libstdc++-v3/ChangeLog: PR libstdc++/120029 * src/c++17/fs_path.cc (path::operator+=(const path&)): Handle parameters that alias the path or one of its components. * testsuite/27_io/filesystem/path/concat/120029.cc: New test. * testsuite/experimental/filesystem/path/concat/120029.cc: New test.
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 --- Comment #9 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:86627faec10da53d7532805019e5296fcf15ac09 commit r16-427-g86627faec10da53d7532805019e5296fcf15ac09 Author: Jonathan Wakely Date: Fri Apr 25 21:09:18 2025 +0100 libstdc++: Rewrite atomic builtin checks [PR70560] Currently the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro checks for a variety of __atomic built-ins for bool, short and int. If all those checks pass, then it defines _GLIBCXX_ATOMIC_BUILTINS and uses the definitions from config/cpu/generic/atomicity_builtins/atomicity.h for the non-inline versions of __exchange_and_add and __atomic_add that get compiled into libsupc++. However, the config/cpu/generic/atomicity_builtins/atomicity.h definitions only depend on __atomic_fetch_add not on __atomic_test_and_set or __atomic_compare_exchange. And they only operate on a variable of type _Atomic word, which is not necessarily one of bool, short or int (e.g. for sparcv9 _Atomic_word is 64-bit long). This means that for a target where _Atomic_word is int but there are no 1-byte or 2-byte atomic instructions, GLIBCXX_ENABLE_ATOMIC_BUILTINS will fail the checks for bool and short and not define the macro _GLIBCXX_ATOMIC_BUILTINS. That means that we will use a single global mutex for reference counting in the COW std::string and std::locale, even though we could use __atomic_fetch_add to do it lock-free. This commit removes most of the GLIBCXX_ENABLE_ATOMIC_BUILTINS checks, so that it only checks __atomic_fetch_add on _Atomic_word. The macro defined by GLIBCXX_ENABLE_ATOMIC_BUILTINS is renamed from _GLIBCXX_ATOMIC_BUILTINS to _GLIBCXX_ATOMIC_WORD_BUILTINS to better reflect what it really means. This will enable the inline versions of __exchange_and_add and __atomic_add for more targets. This is not an ABI change, because targets which didn't previously use the inline definitions of those functions made non-inlined calls to the functions in the library. If the definitions of those functions now start using atomics, that doesn't change the semantics for the code calling those functions. On affected targets, new code compiled after this change will see the _GLIBCXX_ATOMIC_WORD_BUILTINS macro and so will use the always-inline versions of __exchange_and_add and __atomic_add, which use __atomic_fetch_add directly. That is also compatible with older code which still calls the non-inline definitions, because those non-inline definitions now also use __atomic_fetch_add. The only configuration where this could be an ABI change is for a target which previously defined _GLIBCXX_ATOMIC_BUILTINS (because all the atomic built-ins for bool, short and int are supported), but which defines _Atomic_word to some other type for which __atomic_fetch_add is /not/ supported. Such a target would have called the inline functions using __atomic_fetch_add, which would actually have depended on libatomic (which is what the configure checks were supposed to prevent!). After this change, that target would not define the new macro, _GLIBCXX_ATOMIC_WORD_BUILTINS, and so would make non-inline calls into the library where __exchange_and_add and __atomic_add would use the global mutex. That would be an ABI break. I don't consider that a realistic scenario, because it wouldn't have made any sense to define _Atomic_word to a wider type than int, when doing so would have required libatomic to make libstdc++.so work. Surely such a target would have just used int for its _Atomic_word type. The GLIBCXX_ENABLE_BACKTRACE macro currently uses the glibcxx_ac_atomic_int variable defined by the checks that this commit removes from GLIBCXX_ENABLE_ATOMIC_BUILTINS. That wasn't a good check anyway, because libbacktrace actually depends on atomic loads+stores for pointers as well as int, and for atomic stores for size_t. This commit replaces the glibcxx_ac_atomic_int check with a proper test for all the required atomic operations on all three of int, void* and size_t. This ensures that the libbacktrace code used for std::stacktrace will either use native atomics, or implement those loads and stores only in terms of __sync_bool_compare_and_swap (possibly requiring that to come from libatomic or elsewhere). libstdc++-v3/ChangeLog: PR libstdc++/70560 PR libstdc++/119667 * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Only check for __atomic_fetch_add on _Atomic_word. Define new macro _GLIBCXX_ATOMIC_WORD_BUILTINS and stop defining macro _GLIBCXX_ATOMIC_BUILTINS. (GLIBCXX_ENABLE_BACKTRACE): Check for __atomic_load_n and __atomic_store_n on int, void* and size
[Bug libstdc++/117905] PSTL algos in require copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117905 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:df1d436d17c8280bd835b045bd7babf5058a7154 commit r16-426-gdf1d436d17c8280bd835b045bd7babf5058a7154 Author: Jonathan Wakely Date: Wed Dec 4 21:50:22 2024 + libstdc++: Fix parallel algos for move-only values [PR117905] All of reduce, transform_reduce, exclusive_scan, and inclusive_scan, transform_exclusive_scan, and transform_inclusive_scan have a precondition that the type of init meets the Cpp17MoveConstructible requirements. It isn't required to be copy constructible, so when passing it to the next internal function it needs to be moved, not copied. We also need to move when creating local variables on the stack, and when returning as part of a pair. libstdc++-v3/ChangeLog: PR libstdc++/117905 * include/pstl/glue_numeric_impl.h (reduce, transform_reduce) (transform_reduce, inclusive_scan, transform_exclusive_scan) (transform_inclusive_scan): Use std::move for __init parameter. * include/pstl/numeric_impl.h (__brick_transform_reduce) (__pattern_transform_reduce, __brick_transform_scan) (__pattern_transform_scan): Likewise. * include/std/numeric (inclusive_scan, transform_exclusive_scan): Use std::move to create local copy of the first element. * testsuite/26_numerics/pstl/numeric_ops/108236.cc: Move test using move-only type to ... * testsuite/26_numerics/pstl/numeric_ops/move_only.cc: New test.
[Bug c++/120136] internal compiler error: tree check: accessed elt 1 of 'tree_vec' with -1 elts in add_to_template_args, at cp/pt.cc:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120136 --- Comment #1 from Luke Dalessandro --- Created attachment 61342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61342&action=edit actual cvise output (also ICEs 13,14,15) This was the test case that cvise actually returned. It's messier with more actual names from the original code and has some wasted stuff, but I'm including it because it also ICEs 13,14,15 as "internal compiler error: in tsubst, at cp/pt.cc:16670." The one I cleaned up and submitted as the original doesn't seem to ICE those three.
[Bug tree-optimization/120065] [14/15/16 Regression] profile info corrupted by dom2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120065
--- Comment #5 from Alex Coplan ---
FWIW, the following testcase seems to be more representative of the original
problem I saw when looking at gcc.c-torture/execute/20060420-1.c:
$ cat t2.c
void foo(float *dst, float *src)
{
int j;
for (j = 0; j < 16 && src[j]; j++)
dst[j] = src[j];
for (; j < 1; j++)
dst[j] = src[j];
}
$ mkdir dmp
$ ./xgcc -B . -c t2.c -S -o dmp/a.s -O3 -fdump-tree-all-blocks-details
$ grep -Irn "Invalid sum" dmp | sort -n | head -n 4
dmp/a.c.122t.threadfull1:140:;; Invalid sum of incoming counts 114571471
(estimated locally, freq 0.9700), should be 955630223 (estimated locally, freq
8.0909)
dmp/a.c.122t.threadfull1:148:;; Invalid sum of incoming counts 959170352
(estimated locally, freq 8.1209), should be 118111600 (estimated locally, freq
1.)
dmp/a.c.123t.vrp1:273:;; Invalid sum of incoming counts 114571471 (estimated
locally, freq 0.9700), should be 955630223 (estimated locally, freq 8.0909)
dmp/a.c.123t.vrp1:281:;; Invalid sum of incoming counts 959170352 (estimated
locally, freq 8.1209), should be 118111600 (estimated locally, freq 1.)
so this testcase (and indeed the original gcc.c-torture test) start failing in
threadfull1 (not dom2) and it looks to have started with a different change,
too (r14-376-g47a7643991192a756d0fb9057a0a2bfce338a09f). Perhaps we want a
separate PR for this one.
Apologies for the bad reduction in the initial report.
[Bug fortran/33285] integer too big compile error in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285 Andrew Pinski changed: What|Removed |Added CC||vterzi1996 at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 120131 has been marked as a duplicate of this bug. ***
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 Vladimir Terzi changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #3 from Vladimir Terzi --- I changed the status from `RESOLVED` to `UNCONFIRMED`, because the error message is still misleading. -2147483648 is certainly not too big for the storage size of 4 bytes. If `gfortran` is unable to represent it as a literal (while other compilers seemingly can), it is a completely different matter and is an implementation detail of the compiler, so the error message should be changed.
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- No gfortran is correct this code is invalid without an extra option. *** This bug has been marked as a duplicate of bug 33285 ***
[Bug c++/118526] infinite compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118526 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- c-vise found the simple testcase in pr119954 with 4 variables (such as "a < b < c < d"), probably fixing that would allow debugging this easier
[Bug fortran/33285] integer too big compile error in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285 Andrew Pinski changed: What|Removed |Added CC||gsocshubham at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 92639 has been marked as a duplicate of this bug. ***
[Bug fortran/92639] Error: Integer too big for its kind at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 33285 ***
[Bug c++/120130] Cannot declare function template as friend in the presence of same named member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120130 --- Comment #2 from Andrew Pinski --- clang started to acecpt this for -std=c++2a in clang 9. Would be interesting to make sure this is not a clang bug since 3 major compilers reject it while clang is the odd one out.
[Bug lto/113208] [15 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #38 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6d5a6a26e28d15ac05f59ee4d3c3d7d4d42acac3 commit r14-11743-g6d5a6a26e28d15ac05f59ee4d3c3d7d4d42acac3 Author: Jakub Jelinek Date: Wed May 15 18:50:11 2024 +0200 c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208] This patch reworks the cdtor alias optimization, such that we can create aliases even when maybe_clone_body is called not at at_eof time, without trying to repeat it in maybe_optimize_cdtor. 2024-05-15 Jakub Jelinek Jason Merrill PR lto/113208 * cp-tree.h (maybe_optimize_cdtor): Remove. * decl2.cc (tentative_decl_linkage): Call maybe_make_one_only for implicit instantiations of maybe in charge ctors/dtors declared inline. (import_export_decl): Don't call maybe_optimize_cdtor. (c_parse_final_cleanups): Formatting fixes. * optimize.cc (can_alias_cdtor): Adjust condition, for HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even if not DECL_INTERFACE_KNOWN. (maybe_clone_body): Don't clear DECL_SAVED_TREE, instead set it to void_node. (maybe_clone_body): Remove. * decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already set. * g++.dg/abi/comdat3.C: New test. * g++.dg/abi/comdat4.C: New test. (cherry picked from commit 6ad7ca1bb905736c0f57688e93e9e77cbc71a325)
[Bug tree-optimization/120132] JMP to target function from the middle of the current if the results layout are compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120132
--- Comment #1 from Antony Polukhin ---
Another example:
struct A {
int i;
int j;
};
A g();
int test1() {
A a = g();
return a.i;
}
GCC-15 produces the following assembly:
test1():
sub rsp, 8
call g()
add rsp, 8
ret
A more optimal one would be:
test1():
jmp g()
Godbolt playground: https://godbolt.org/z/sPdxbjPxK
[Bug ipa/120120] [16 Regression] gcc-16: performance regression with -O3 compared to gcc-15 since r16-170-ga670ebde399548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120120 --- Comment #9 from Jan Hubicka --- Forgot to say, -fno-optimize-sibbling-calls re-enables the cloning & inline.
[Bug c++/119305] [14 Regression] ICE in add_to_same_comdat_group with constexpr virtual and constexpr instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119305 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- https://gcc.gnu.org/g:6d5a6a26e28d15ac05f59ee4d3c3d7d4d42acac3 commit r14-11743-g6d5a6a26e28d15ac05f59ee4d3c3d7d4d42acac3 Author: Jakub Jelinek Date: Wed May 15 18:50:11 2024 +0200 c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208] This patch reworks the cdtor alias optimization, such that we can create aliases even when maybe_clone_body is called not at at_eof time, without trying to repeat it in maybe_optimize_cdtor. 2024-05-15 Jakub Jelinek Jason Merrill PR lto/113208 * cp-tree.h (maybe_optimize_cdtor): Remove. * decl2.cc (tentative_decl_linkage): Call maybe_make_one_only for implicit instantiations of maybe in charge ctors/dtors declared inline. (import_export_decl): Don't call maybe_optimize_cdtor. (c_parse_final_cleanups): Formatting fixes. * optimize.cc (can_alias_cdtor): Adjust condition, for HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even if not DECL_INTERFACE_KNOWN. (maybe_clone_body): Don't clear DECL_SAVED_TREE, instead set it to void_node. (maybe_clone_body): Remove. * decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already set. * g++.dg/abi/comdat3.C: New test. * g++.dg/abi/comdat4.C: New test. (cherry picked from commit 6ad7ca1bb905736c0f57688e93e9e77cbc71a325)
[Bug c++/109464] gcc does not instantiate constructor for explicitly instantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109464 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d9800938ef61b7978abb33a8b202beeb3efed6b commit r14-11744-g9d9800938ef61b7978abb33a8b202beeb3efed6b Author: Patrick Palka Date: Fri Jul 19 11:08:09 2024 -0400 c++: add fixed testcase [PR109464] Seems to be fixed by r15-521-g6ad7ca1bb90573. PR c++/109464 gcc/testsuite/ChangeLog: * g++.dg/template/explicit-instantiation8.C: New test. (cherry picked from commit 58a9f3ded1a0ccc2c8b0a42f976950041734798e)
[Bug middle-end/114512] Optimization on "test if bit N is set" pattern ((C >> x) & 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114512 --- Comment #1 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:4cd741dcbd3729863ab005d7ec61a890e0a193f1 commit r16-411-g4cd741dcbd3729863ab005d7ec61a890e0a193f1 Author: Shreya Munnangi Date: Tue May 6 06:38:00 2025 -0600 [RISC-V][PR middle-end/114512] Recognize more bext idioms for RISC-V This is Shreya's next chunk of work. When I was looking for good bugs for her to chase down I cam across PR114512. While the bug isn't necessarily a RISC-V specific bug, its testcases did show how we were failing to recognize certain bit extraction idioms and how the lispy nature of RTL allows us to tackle these issues in the combiner. First, the bit position may be masked. The RISC-V port does not define SHIFT_COUNT_TRUNCATED for valid reasons. So if we want to optimize away a mask that matches what the hardware will do, we need suitable insns that include that explicit masking. In addition to needing to incorporate masking, the masking may happen in a subword mode. So we need to recognize the mask wrapped in a zero extension. Those two captured the most common cases. We can also have a single bit extraction implemented as a left shift of the bit into the sign bit, then a right shift by the size of a word - 1. These are less common, but we did cover the case derived from the upstream bug report as well as one class seen reviewing the instruction stream for spec2017. Finally, extracting a single bit at a variable position from a constant as seen with some regularity in spec2017. In that scenario, combine's chosen split point wasn't ideal (I forget what it selected, but it definitely wasn't helpful). So we've got a new splitter for this case as well. Earlier versions of this have gone through my tester as well as a bootstrap and regression cycle. This version has just gone through a cycle in my tester (but missed today's bootstrap cycle). Waiting on the upstream pre-commit tester to render its verdict, but the plan is to commit on Shreya's behalf once that's clean. Co-authored-by: Jeff Law PR middle-end/114512 gcc/ * config/riscv/bitmanip.md (bext* patterns): New patterns for bext recognition plus splitter for extracting variable bit from a constant. * config/riscv/predicates.md (bitpos_mask_operand): New predicate. gcc/testsuite/ * gcc.target/riscv/pr114512.c: New test.
[Bug c++/117813] [14 Regression] GCC14 + -fsanitize=undefined + -Os + recursive_directory_iterator results in undefined reference since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117813 --- Comment #13 from Jakub Jelinek --- https://gcc.gnu.org/g:6d5a6a26e28d15ac05f59ee4d3c3d7d4d42acac3 commit r14-11743-g6d5a6a26e28d15ac05f59ee4d3c3d7d4d42acac3 Author: Jakub Jelinek Date: Wed May 15 18:50:11 2024 +0200 c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208] This patch reworks the cdtor alias optimization, such that we can create aliases even when maybe_clone_body is called not at at_eof time, without trying to repeat it in maybe_optimize_cdtor. 2024-05-15 Jakub Jelinek Jason Merrill PR lto/113208 * cp-tree.h (maybe_optimize_cdtor): Remove. * decl2.cc (tentative_decl_linkage): Call maybe_make_one_only for implicit instantiations of maybe in charge ctors/dtors declared inline. (import_export_decl): Don't call maybe_optimize_cdtor. (c_parse_final_cleanups): Formatting fixes. * optimize.cc (can_alias_cdtor): Adjust condition, for HAVE_COMDAT_GROUP && DECL_ONE_ONLY && DECL_WEAK return true even if not DECL_INTERFACE_KNOWN. (maybe_clone_body): Don't clear DECL_SAVED_TREE, instead set it to void_node. (maybe_clone_body): Remove. * decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already set. * g++.dg/abi/comdat3.C: New test. * g++.dg/abi/comdat4.C: New test. (cherry picked from commit 6ad7ca1bb905736c0f57688e93e9e77cbc71a325)
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 --- Comment #2 from Vladimir Terzi --- (In reply to Andrew Pinski from comment #1) > No gfortran is correct this code is invalid without an extra option. > > *** This bug has been marked as a duplicate of bug 33285 *** So you are implying that this code is invalid according to the Fortran standard and other compilers are wrong, right? I understand that `gfortran` treats it as the negation operation applied to a positive integer. But is it not possible to treat it like a literal `b'1000'`? Also I still find the error message misleading, since this value fits in the storage size of the kind and I can use this value (generated through different means) without any problem in the code. Incidentally, `ifx` generates a warning in the case of `2147483648` but not in the case of `-2147483648`, which is intuitively clear for a simple user, who is unaware of the inner workings of a compiler. If the standard doesn't specify the numeric ranges for integer types, I find this limitation inconvenient. I need to perform bit operations using `transfer` with an array of integers (which is generated automatically and copied to the code using compile definitions) as the source and am forced to replace every `-2147483648` with `-huge(0)-1` only because of `gfortran`. (For clarification, I need to use only the default compilation flags.)
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086 --- Comment #11 from John David Anglin --- (In reply to Jørgen Kvalsvik from comment #9) > Created attachment 61335 [details] > Patch: fix, printf properly on systems without %zu > > I just posted this on gcc-patches. It should fix the issue in gcov, could > you please test it, John? I'll test.
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #10 from John David Anglin ---
(In reply to Richard Biener from comment #7)
> Possibly using %llu and (unsigned long long) casts on the value would be a
> good fix.
I tested this and it didn't completely fix fails:
FAIL: expected: '33'
FAIL: expected: '{112(true) 113 114} {112(false) 114}'
FAIL: expected: '{125(true) 126 129} {125(false) 128 129}'
FAIL: expected: '{141(true) 142 147} {141(false) 143(true) 144 147} {141(false)
143(false) 146 147}'
FAIL: expected: '{162 162(true) 163} {162 162(false) 164} {163 162(true) 163}
{163 162(false) 164} {162(true) 163 162}'
FAIL: expected: '{180 180(true) 181} {180 180(false) 182} {181 180(true) 181}
{181 180(false) 182} {180(true) 181 180}'
FAIL: expected: '{194 197(false) 198} {197(true) 197}'
FAIL: expected: '{213 216(true) 220} {213 216(false) 222} {216(true) 220 216}
{220 216(true) 220} {220 216(false) 222}'
FAIL: expected: '{243(false) 247 247(true) 247(true) 249(true) 250 253}
{243(false) 247 247(true) 247(false) 253} {243(false) 247 247(false) 253}
{243(true) 253} {249(false) 247(true) 247(true) 249} {249(false) 247(true)
247(false) 253} {247(true) 247(true) 249(false) 247} {247(true) 249(false)
247(true) 247} {247(true) 249(false) 247(false) 253}'
FAIL: expected: '{48(true) 49 52} {48(false) 51 52}'
FAIL: expected: '{63(false) 66 67}'
FAIL: expected: '{78(true) 79 82}'
FAIL: gcc.misc-tests/gcov-30.c (test for excess errors)
FAIL: gcc.misc-tests/gcov-30.c gcov: 0 failures in line counts, 0 in branch
percentages, 0 in condition/decision, 12 in prime-paths, 0 in return
percentages, 0 in intermediate format, 0 failed in filters
What did work was revising format to "%lu" on hpux.
I'm also testing:
diff --git a/gcc/testsuite/gcc.misc-tests/gcov-30.c
b/gcc/testsuite/gcc.misc-tests/gcov-30.c
index dbc168186b7..9b7847bd943 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov-30.c
+++ b/gcc/testsuite/gcc.misc-tests/gcov-30.c
@@ -1,4 +1,5 @@
/* { dg-options "--coverage -fpath-coverage -fprofile-update=atomic" } */
+/* { dg-require-effective-target profile_update_atomic } */
/* { dg-do run { target native } } */
void
[Bug c++/119252] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119252 Luke Dalessandro changed: What|Removed |Added CC||ldalessandro at gmail dot com --- Comment #1 from Luke Dalessandro --- Created attachment 61336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61336&action=edit test case
[Bug c++/119252] g++: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119252 --- Comment #2 from Luke Dalessandro --- Sorry, this test case went to the wrong PR. Meant to go to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120133.
[Bug c++/120133] New: internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120133 Bug ID: 120133 Summary: internal compiler error: Segmentation fault signal terminated program cc1plus Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldalessandro at gmail dot com Target Milestone: --- Created attachment 61337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61337&action=edit test case I encountered this segfault while trying to reduce a different ICE with cvise. template concept indirectly_swappable = ; iter_swap() (indirectly_swappable< Compile with g++ -std=gnu20. :2:32: error: expected primary-expression before ';' token 2 | concept indirectly_swappable = ; |^ :3:25: error: expected 'auto' or 'decltype(auto)' after 'indirectly_swappable' 3 | iter_swap() (indirectly_swappable< | ^~~~ g++: internal compiler error: Segmentation fault signal terminated program cc1plus Live: https://godbolt.org/z/nrhKEcexx [May 6th, 2025]
[Bug c++/120133] internal compiler error: Segmentation fault signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120133 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from mcccs at gmx dot com --- [needs-bisection] works with 9.5, fails with 10.1. -std=c++2a -fconcepts
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #4 from kargls at comcast dot net --- (In reply to Vladimir Terzi from comment #3) > I changed the status from `RESOLVED` to `UNCONFIRMED`, because the error > message is still misleading. -2147483648 is certainly not too big for the > storage size of 4 bytes. If `gfortran` is unable to represent it as a > literal (while other compilers seemingly can), it is a completely different > matter and is an implementation detail of the compiler, so the error message > should be changed. Please change this back to RESOLVED. See Fortran 2033, 7.4.3.1 and 10.1.2.5 (in particular the Note).
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #17 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:d0571638a6bad932b226ada98b167fa47a47d838 commit r16-428-gd0571638a6bad932b226ada98b167fa47a47d838 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.
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 --- Comment #6 from kargls at comcast dot net --- (In reply to Vladimir Terzi from comment #5) > After a fruitful discussion in Stack Overflow, I understand that the model > set of integers in Fortran is symmetric about zero according to the formula > in section 16.4 of https://j3-fortran.org/doc/year/24/24-007.pdf , and, > therefore, `gfortran` may reject the literal -2147483648 (although it is > inconvenient and there are no technical reasons to reject it). But it was > already known in 2006 that this change will cause "bogus bug reports" (like > written in https://gcc.gnu.org/legacy-ml/fortran/2006-09/msg8.html) and > there are already multiple of such reports on this site. Then why wasn't > the error message clarified? The original error message was % gfortran14 -o z a.f90 a.f90:1:21: 1 | print *, -2147483648 | 1 Error: Integer too big for its kind at (1). Then this commit happen. 2007-08-09 Tobias Burnus PR fortran/33001 * arith.c (arith_error): Point in the error message to -fno-range-check. which gives (with courtesy wrap of a long line) % gfortran14 -o z a.f90 a.f90:1:21: 1 | print *, -2147483648 | 1 Error: Integer too big for its kind at (1). This check can be disabled with the option '-fno-range-check' Then this commit happen 2007-11-29 Steven G. Kargl PR fortran/34230 * fortran/arith.c (gfc_check_real_range): Set intermediate values to +-Inf and 0 when -fno-range-check is in effect. * fortran/invoke.texi: Improve -fno-range-check description. I suppose it is somewhat naive of gfortran contributors to expect that users read the documentation supplied with the compiler. ‘-fno-range-check’ Disable range checking on results of simplification of constant expressions during compilation. For example, GNU Fortran gives an error at compile time when simplifying ‘a = 1. / 0’. With this option, no error is given and ‘a’ is assigned the value ‘+Infinity’. If an expression evaluates to a value outside of the relevant range of [‘-HUGE()’:‘HUGE()’], then the expression is replaced by ‘-Inf’ or ‘+Inf’ as appropriate. Similarly, ‘DATA i/Z''/’ results in an integer overflow on most systems, but with ‘-fno-range-check’ the value "wraps around" and ‘i’ is initialized to -1 instead. Those last two sentences are important. Consider the simple example, % cat b.f90 print *, 1 + -1 end % gfortran14 -o z b.f90 && ./z b.f90:1:15: 1 | print *, 1 + -1 | 1 Warning: Extension: Unary operator following arithmetic operator (use parentheses) at (1) 0 % ~/tmp/root/build/bin/flang -o z b.f90 && ./z 0 gfortran gives a warning while flang does not; but, it can be forced to tell you that the program is invalid % ~/tmp/root/build/bin/flang -o z -pedantic b.f90 && ./z ./b.f90:1:14: portability: nonstandard usage: signed mult-operand print *, 1 + -1 ^^ % ~/lfortran/work/bin/lfortran -o z b.f90 % ./z 0 There appears to be no option with lfortran to diagnose the invalid code. Now, returning to a.f90 above. gfortran14 -o z a.f90 && ./z a.f90:1:21: 1 | print *, -2147483648 | 1 Error: Integer too big for its kind at (1). This check can be disabled with the option '-fno-range-check' % gfortran14 -o z -fno-range-check a.f90 && ./z -2147483648 % gfortran14 -o z -fno-range-check -pedantic a.f90 && ./z a.f90:1:21: 1 | print *, -2147483648 | 1 Warning: Integer outside symmetric range implied by Standard Fortran at (1) -2147483648 So, yes, more than one gfortran contributor has thought about the corner case of -huge(1) - 1.
[Bug fortran/120131] Misleading and unnecessary error message due to range check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120131 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #7 from Andrew Pinski --- Still a dup. *** This bug has been marked as a duplicate of bug 33285 ***
[Bug fortran/33285] integer too big compile error in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285 --- Comment #10 from Andrew Pinski --- *** Bug 120131 has been marked as a duplicate of this bug. ***
