[Bug libstdc++/120934] views::concat is ill-formed depending on argument order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120934
--- Comment #3 from François Hamonic ---
(In reply to Patrick Palka from comment #1)
> Confirmed, it seems this gets fixed if we implement the updated proposed
> resolution for LWG 4166 (https://wg21.link/lwg4166). We currently implement
> the original proposed resolution (in r15-4555), which isn't sufficient here
> (as Hewill Kang pointed out earlier in PR115209#c7).
Thanks a lot for your work and your fast reply!
I'm glad to hear that this issue seems to already be addressed by the updated
resolution for LWG 4166 and that a fix is expected in GCC 15.2.
In the meantime, I'm using the following workaround for my specific use case:
template
constexpr auto unordered_concat(R1&& r1, R2&& r2) {
if constexpr (std::ranges::range(r1), std::forward(r2)))>) {
return std::views::concat(std::forward(r1), std::forward(r2));
} else {
return std::views::concat(std::forward(r2), std::forward(r1));
}
}
Best regards,
[Bug c++/120940] New: [15 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940
Bug ID: 120940
Summary: [15 Regression] False positive -Wduplicated-branches
warning
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This small code snippet warns with r15-9900 (r15-9866 was still OK):
static const char Names[16][8]= { "ac0", "ac1", "ac2", "ac3", "t0", "t1",
"t2", "t3", "ar0", "ar1", "ar2", "ar3", "ar4", "ar5", "ar6", "ar7" };
static const char NamesPh2[16][8] = { "ac0", "ac1", "ac2", "ac3", "dr0", "dr1",
"dr2", "dr3", "ar0", "ar1", "ar2", "ar3", "ar4", "ar5", "ar6", "ar7" };
const char * test(int mode, int idx)
{
return (mode ? Names : NamesPh2)[idx];
}
# g++-15 -c -Wduplicated-branches test-Wduplicated-branches.cpp -O2
test-Wduplicated-branches.cpp: In function 'const char* test(int, int)':
test-Wduplicated-branches.cpp:7:45: warning: this condition has identical
branches [-Wduplicated-branches]
7 | return (mode ? Names : NamesPh2)[idx];
| ^
test-Wduplicated-branches.cpp:7:45: warning: this condition has identical
branches [-Wduplicated-branches]
7 | return (mode ? Names : NamesPh2)[idx];
|~^
Looking at the changelog it seems like this change maybe the culprit:
commit r15-9896-g7fdf47538a659f6af8dadbecbb63c8a226b63754
Author: Jakub Jelinek
Date: Tue Jul 1 15:28:10 2025 +0200
c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471]
The following testcase is miscompiled since the introduction of UBSan,
cp_build_array_ref COND_EXPR handling replaces
(cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are
SAVE_EXPRs inside of idx, they will be evaluated just in one of the
branches and the other uses uninitialized temporaries.
Fixed by keeping doing what it did if idx doesn't have side effects
and is invariant. Otherwise if op1/op2 are ARRAY_TYPE arrays with
invariant addresses or pointers with invariant values, use
SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as a new condition
and SAVE_EXPR instead of idx for the recursive calls.
Otherwise punt, but if op1/op2 are ARRAY_TYPE, furthermore call
cp_default_conversion on array, so that COND_EXPR with ARRAY_TYPE doesn't
survive in the IL until expansion.
2025-07-01 Jakub Jelinek
PR c++/120471
gcc/cp/
* typeck.cc (cp_build_array_ref) : If idx is not
INTEGER_CST, don't optimize the case (but cp_default_conversion on
array early if it has ARRAY_TYPE) or use
SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as new op0
depending
on flag_strong_eval_order and whether op1 and op2 are arrays with
invariant address or tree invariant pointers. Formatting fixes.
gcc/testsuite/
* g++.dg/ubsan/pr120471.C: New test.
* g++.dg/parse/pr120471.C: New test.
Since this was backported to the other release branches as well, they might be
also affected.
[Bug c++/120940] [15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 Sam James changed: What|Removed |Added Summary|[15 Regression] False |[15/16 Regression] False |positive|positive |-Wduplicated-branches |-Wduplicated-branches |warning |warning Target Milestone|--- |15.2 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120471 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929 --- Comment #16 from qinzhao at gcc dot gnu.org --- (In reply to Siddhesh Poyarekar from comment #12) > This is interesting here's the IR dump right after objsz: > > The key bit is: > > map2_4 = __builtin_malloc (8); > pin_pointer (&buf); > _1 = &map2_4->magic; > _9 = __builtin_malloc (9); > *_1 = _9; > goto ; [100.00%] > >[local count: 1073741824]: > b = ""; > ptr_10 = *_1; > _11 = 8; > __builtin___memcpy_chk (ptr_10, &b, 9, _11); > > where *_1 gets updated to _9, but when one follows the *_1 through ptr_10, > it doesn't end up with _9, the def statement is: > > _1 = &map2_4->magic; > > which leads to the incorrect value for the object size. This is because the > pass doesn't know that a MEM_REF could be the LHS (for the zero byte offset > case like it is here) for an assignment, i.e. this: > > *_1 = _9; There are two possible solutions to the above issue: A. Add handling for *_1 = _9 to enable the object size propagate through the correct data flow path. Or B. in my latest change that triggered this issue: /* Handle the following stmt #2 to propagate the size from the stmt #1 to #3: 1 _1 = .ACCESS_WITH_SIZE (_3, _4, 1, 0, -1, 0B); 2 _5 = *_1; 3 _6 = __builtin_dynamic_object_size (_5, 1); */ else if (TREE_CODE (rhs) == MEM_REF && POINTER_TYPE_P (TREE_TYPE (rhs)) && TREE_CODE (TREE_OPERAND (rhs, 0)) == SSA_NAME && integer_zerop (TREE_OPERAND (rhs, 1))) reexamine = merge_object_sizes (osi, var, TREE_OPERAND (rhs, 0)); I feel that propagating the size through _5 = *_1 might not be correct in general, we should only limit it to the case when the RHS is a pointer defined by .ACCESS_WITH_SIZE? what do you think?
[Bug tree-optimization/120945] New: Missed optimization opportunity with std::bind_front
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120945
Bug ID: 120945
Summary: Missed optimization opportunity with std::bind_front
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Mark_B53 at yahoo dot com
Target Milestone: ---
In the following code compiled using -O2, test2() is fully optimized to "mov
eax, 10" followed by "ret", whereas test1() invokes Foo::test in a loop. The
difference between the functions is the use of an explicit lambda (test2) vs. a
call wrapper generated by std::bind_front (test1).
#include
#include
#include
struct Foo {
bool test(int idx) const { return data[idx] == 0; }
int data[10];
int count1() const {
auto fn = std::bind_front(&Foo::test, this);
return std::ranges::count_if(std::views::iota(0, 10), fn);
}
int count2() const {
auto fn = [this](int idx) { return test(idx); };
return std::ranges::count_if(std::views::iota(0, 10), fn);
}
};
__attribute__((noinline)) int test1() {
Foo foo{};
return foo.count1();
}
__attribute__((noinline)) int test2() {
Foo foo{};
return foo.count2();
}
---
clang 19.1 is able to optimize both implementations. Although this fact is
likely not relevant, I'm including it here since I am not a language lawyer on
perfect forwarding call wrappers.
[Bug debug/120938] discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938 --- Comment #8 from Jan Hubicka --- Porlbem goes away with diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc index d1a55dbcbcb..52ca189531e 100644 --- a/gcc/dwarf2out.cc +++ b/gcc/dwarf2out.cc @@ -25012,9 +25012,8 @@ add_call_src_coords_attributes (tree stmt, dw_die_ref die) add_AT_unsigned (die, DW_AT_call_line, s.line); if (debug_column_info && s.column) add_AT_unsigned (die, DW_AT_call_column, s.column); - unsigned discr = get_discriminator_from_loc (locus); - if (discr != 0) - add_AT_unsigned (die, DW_AT_GNU_discriminator, discr); + add_AT_unsigned (die, DW_AT_GNU_discriminator, + get_discriminator_from_loc (locus)); } }
[Bug tree-optimization/120944] New: Incorrect optimization with accessing a volatile structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120944
Bug ID: 120944
Summary: Incorrect optimization with accessing a volatile
structure member
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bmei at broadcom dot com
Target Milestone: ---
For the following snippet, in function foo, v is wrongly optimized to always
true and abort is called unconditionally despite the volatile structure and
pointer. Function bar is compiled correctly. I checked that GCC has this
behaviour since 10.1.0.
#include
typedef union {
int u32;
struct
{
int A:1;
int B:2;
int C:3;
};
} u_t;
typedef union {
volatile int u[3];
volatile struct {
u_t a;
int b;
int c;
};
} DATA;
void foo (volatile DATA *d)
{
d->a.u32 = ~0;
u_t u = d->a;
int v = u.A;
if (v)
abort();
}
void bar (volatile DATA *d)
{
d->a.u32 = ~0;
if (d->a.A)
abort();
}
in the tree .optimized dump:
void foo (volatile union DATA * d)
{
union u_t u;
[count: 0]:
d_2(D)->D.3445.a.u32 ={v} -1;
u ={v} d_2(D)->D.3445.a;
abort ();
}
;; Function bar (bar, funcdef_no=12, decl_uid=3453, cgraph_uid=13,
symbol_order=12)
void bar (volatile union DATA * d)
{
_1;
[local count: 1073741824]:
d_3(D)->D.3445.a.u32 ={v} -1;
_1 ={v} d_3(D)->D.3445.a.D.3437.A;
if (_1 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
abort ();
[local count: 1073741824]:
return;
}
[Bug tree-optimization/120944] [12/13/14/15/16 Regression] Incorrect optimization with accessing a volatile structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120944
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.1.0
Last reconfirmed||2025-07-03
Known to work||9.1.0, 9.5.0
Keywords||wrong-code
Ever confirmed|0 |1
Summary|Incorrect optimization with |[12/13/14/15/16 Regression]
|accessing a volatile|Incorrect optimization with
|structure member|accessing a volatile
||structure member
Status|UNCONFIRMED |NEW
Target Milestone|--- |12.5
--- Comment #1 from Andrew Pinski ---
Confirmed, fre looks to prop through volatile accesses:
Processing block 0: BB2
Value numbering stmt = d_3(D)->D.3475.a.u32 ={v} -1;
Setting value number of .MEM_4 to .MEM_4 (changed)
Value numbering stmt = u ={v} d_3(D)->D.3475.a;
Setting value number of .MEM_5 to .MEM_5 (changed)
Value numbering stmt = _1 = u.D.3467.A;
Setting value number of _1 to -1 (changed)
Started in GCC 10.
[Bug target/120933] Turn on -mtls-dialect=gnu2 by default on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933 --- Comment #4 from H.J. Lu --- (In reply to Florian Weimer from comment #3) > Yes, compatibility with old glibc is a concern, considering this can be > difficult to test, and failures can be largely silent. What are your suggestions?
[Bug target/120908] *tls_(local|global)_dynamic_64_ has an implicit RDI clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908 --- Comment #6 from H.J. Lu --- Fixed for GCC 16 so far
[Bug target/120936] [12/13/14/15/16 Regression] x86_function_profiler emits an unused label by by r5-3767-gecc81e33123d7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936 --- Comment #6 from Jakub Jelinek --- E.g. body: .LFB[0-9]+: .*\t.cfi_.* \t1:callmcount .* against: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 1: callmcount .section __mcount_loc, "a",@progbits .quad 1b .previous popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: FAIL: gcc.target/i386/pr120936-4.c check-function-bodies foo ../configure --enable-languages=default,ada,obj-c++,lto,go,d,m2,cobol --enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes
[Bug debug/96635] Feature request: PDB/Codeview support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635 Julian Waters changed: What|Removed |Added CC||tanksherman27 at gmail dot com --- Comment #7 from Julian Waters --- Commenting on this issue as a codeview user: It might also be worth adding documentation on how to emit codeview debugging information when the compile and link steps are split up (As in -c was passed to the compiler so the object files are emitted instead of the final binary), as well as how to control where the codeview file is placed (If such a thing is possible). At least from what I can see in my testing, unlike with Linux and DWARF, simply passing -g -gcodeview to the compile step is not enough to get the codeview file; It is simply not emitted when compiling and linking are separate steps.
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #12 from Siddhesh Poyarekar ---
This is interesting here's the IR dump right after objsz:
struct magic_map * apprentice_load ()
{
unsigned int i;
char b[1024];
struct magic_ * ptr;
struct magic_map * map2;
char buf[128];
struct magic_ * * _1;
void * _9;
long unsigned int _11;
[local count: 1073741824]:
map2_4 = __builtin_malloc (8);
pin_pointer (&buf);
_1 = &map2_4->magic;
_9 = __builtin_malloc (9);
*_1 = _9;
goto ; [100.00%]
[local count: 1073741824]:
b = "";
ptr_10 = *_1;
_11 = 8;
__builtin___memcpy_chk (ptr_10, &b, 9, _11);
b ={v} {CLOBBER(eos)};
i_13 = i_12 + 1;
[local count: 2147483648]:
# i_12 = PHI <0(2), i_13(3)>
if (i_12 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 1073741824]:
pin_pointer (map2_4);
buf ={v} {CLOBBER(eos)};
return;
}
The key bit is:
map2_4 = __builtin_malloc (8);
pin_pointer (&buf);
_1 = &map2_4->magic;
_9 = __builtin_malloc (9);
*_1 = _9;
goto ; [100.00%]
[local count: 1073741824]:
b = "";
ptr_10 = *_1;
_11 = 8;
__builtin___memcpy_chk (ptr_10, &b, 9, _11);
where *_1 gets updated to _9, but when one follows the *_1 through ptr_10, it
doesn't end up with _9, the def statement is:
_1 = &map2_4->magic;
which leads to the incorrect value for the object size. This is because the
pass doesn't know that a MEM_REF could be the LHS (for the zero byte offset
case like it is here) for an assignment, i.e. this:
*_1 = _9;
[Bug c/118948] [15/16 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_single_nonnegative_warnv_p, at fold-const.cc:14878 since r15-328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118948
--- Comment #5 from Andrew Pinski ---
Simple fix:
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 47492575d00..8867540243b 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15224,7 +15224,7 @@ bool
tree_expr_nonnegative_warnv_p (tree t, bool *strict_overflow_p, int depth)
{
enum tree_code code;
- if (t == error_mark_node)
+ if (error_operand_p (t))
return false;
code = TREE_CODE (t);
[Bug c++/120577] [14/15/16 Regression] Another crash with [[no_unique_address]] and constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120577 --- Comment #5 from Nikolas Klauser --- Is there any update on this? It'd be really nice if libc++ could be used with GCC without any crashes.
[Bug tree-optimization/120780] Missed __builtin_dynamic_object_size optimization(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780 --- Comment #20 from Siddhesh Poyarekar --- I'll backport to the gcc-15 branch after it marinates on trunk for a day or so, allowing various CIs to test it.
[Bug tree-optimization/120780] Missed __builtin_dynamic_object_size optimization(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780 --- Comment #21 from Sam James --- (In reply to Siddhesh Poyarekar from comment #20) > I'll backport to the gcc-15 branch after it marinates on trunk for a day or > so, allowing various CIs to test it. I don't know for certain, but you may need to wait until PR120929 is sorted to have more confidence in that (as e.g. bootstrap-ubsan is broken on arm64, so they won't pick up your patch).
[Bug debug/120938] discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938
--- Comment #1 from Jan Hubicka ---
Removing the parameter of inc makes the problem to go away. So does removing
the recursion
#include
volatile int variablev;
static int dead ()
{
return 0;
}
static void inc()
{
variablev++;
}
static void
inline_me (int l)
{
for (int i = 0; i < 1; i++)
{dead();inc();inc();}
if (!l)
inline_me (l+1);
printf ("block tail recursion\n");
}
int main ()
{
inline_me (0);
return 0;
}
[Bug libstdc++/120934] views::concat is ill-formed depending on argument order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120934 --- Comment #2 from François Hamonic --- (In reply to Patrick Palka from comment #1) > Confirmed, it seems this gets fixed if we implement the updated proposed > resolution for LWG 4166 (https://wg21.link/lwg4166). We currently implement > the original proposed resolution (in r15-4555), which isn't sufficient here > (as Hewill Kang pointed out earlier in PR115209#c7). Thanks a lot for your work and your fast reply ! I am happy to learn that this problem seems to already have a fix planned
[Bug target/120941] [16 Regression] 20-40% slowdown of 519.lbm_r on Zen2 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941 Filip Kastl changed: What|Removed |Added Target Milestone|--- |16.0
[Bug c++/118856] [15 Regression] ICE in gimplify_var_or_parm_decl at gimplify.cc:3346 on mesonlsp-4.3.7 since r15-7481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856 --- Comment #15 from GCC Commits --- The releases/gcc-15 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6b19e40f982829c460439d270d34c5c848d90c6e commit r15-9916-g6b19e40f982829c460439d270d34c5c848d90c6e Author: Jason Merrill Date: Wed Jul 2 18:03:57 2025 -0400 c++: uninitialized TARGET_EXPR and constexpr [PR120684] In r15-7532 for PR118856 I introduced a TARGET_EXPR with a TARGET_EXPR_INITIAL of void_node to express that no initialization is done. And indeed evaluating that doesn't store a value for the TARGET_EXPR_SLOT variable. But then at the end of the full-expression, destroy_value stores void_node to express that its lifetime has ended. If we evaluate the same full-expression again, global_ctx->values still holds the void_node, causing confusion when we try to destroy it again. So clear out any value before evaluating a TARGET_EXPR_INITIAL of void_type. PR c++/120684 PR c++/118856 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression) [TARGET_EXPR]: Clear the value first if is_complex. gcc/testsuite/ChangeLog: * g++.dg/cpp23/range-for10.C: New test.
[Bug c++/120684] [15/16 Regression] bogus "error: destroying ‘’ outside its lifetime" with constexpr dtor object inside repeated range-based for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120684 --- Comment #3 from GCC Commits --- The releases/gcc-15 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6b19e40f982829c460439d270d34c5c848d90c6e commit r15-9916-g6b19e40f982829c460439d270d34c5c848d90c6e Author: Jason Merrill Date: Wed Jul 2 18:03:57 2025 -0400 c++: uninitialized TARGET_EXPR and constexpr [PR120684] In r15-7532 for PR118856 I introduced a TARGET_EXPR with a TARGET_EXPR_INITIAL of void_node to express that no initialization is done. And indeed evaluating that doesn't store a value for the TARGET_EXPR_SLOT variable. But then at the end of the full-expression, destroy_value stores void_node to express that its lifetime has ended. If we evaluate the same full-expression again, global_ctx->values still holds the void_node, causing confusion when we try to destroy it again. So clear out any value before evaluating a TARGET_EXPR_INITIAL of void_type. PR c++/120684 PR c++/118856 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression) [TARGET_EXPR]: Clear the value first if is_complex. gcc/testsuite/ChangeLog: * g++.dg/cpp23/range-for10.C: New test.
[Bug libstdc++/120934] views::concat is ill-formed depending on argument order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120934 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:612690936f5ddd122b60cf843cb4f40ae7ede436 commit r15-9917-g612690936f5ddd122b60cf843cb4f40ae7ede436 Author: Patrick Palka Date: Thu Jul 3 10:55:17 2025 -0400 libstdc++: Update LWG 4166 changes to concat_view::end() [PR120934] In r15-4555-gf191c830154565 we proactively implemented the initial proposed resolution for LWG 4166 which later turned out to be insufficient, since we must also require equality_comparable of the underlying iterators before concat_view could be a common range. This patch implements the updated P/R, requiring all underlying iterators to be forward (which implies equality_comparable) before making concat_view common, which fixes the testcase from this PR. PR libstdc++/120934 libstdc++-v3/ChangeLog: * include/std/ranges (concat_view::end): Refine condition for returning an iterator instead of default_sentinel as per the updated P/R for LWG 4166. * testsuite/std/ranges/concat/1.cc (test05): New test. Reviewed-by: Jonathan Wakely (cherry picked from commit c5a17e92ebf0c6f3887fb5698a1114a3fdf50576)
[Bug libstdc++/120934] views::concat is ill-formed depending on argument order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120934 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #6 from Patrick Palka --- Fixed for GCC 15.2, thanks for the bug report.
[Bug target/120933] Turn on -mtls-dialect=gnu2 by default on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929 --- Comment #17 from Siddhesh Poyarekar --- (In reply to qinzhao from comment #16) > (In reply to Siddhesh Poyarekar from comment #12) > > This is interesting here's the IR dump right after objsz: > > > > The key bit is: > > > > map2_4 = __builtin_malloc (8); > > pin_pointer (&buf); > > _1 = &map2_4->magic; > > _9 = __builtin_malloc (9); > > *_1 = _9; > > goto ; [100.00%] > > > >[local count: 1073741824]: > > b = ""; > > ptr_10 = *_1; > > _11 = 8; > > __builtin___memcpy_chk (ptr_10, &b, 9, _11); > > > > where *_1 gets updated to _9, but when one follows the *_1 through ptr_10, > > it doesn't end up with _9, the def statement is: > > > > _1 = &map2_4->magic; > > > > which leads to the incorrect value for the object size. This is because the > > pass doesn't know that a MEM_REF could be the LHS (for the zero byte offset > > case like it is here) for an assignment, i.e. this: > > > > *_1 = _9; > > There are two possible solutions to the above issue: > > A. Add handling for *_1 = _9 to enable the object size propagate through the > correct data flow path. > Or > B. in my latest change that triggered this issue: > > /* Handle the following stmt #2 to propagate the size from the >stmt #1 to #3: > 1 _1 = .ACCESS_WITH_SIZE (_3, _4, 1, 0, -1, 0B); > 2 _5 = *_1; > 3 _6 = __builtin_dynamic_object_size (_5, 1); > */ > else if (TREE_CODE (rhs) == MEM_REF > && POINTER_TYPE_P (TREE_TYPE (rhs)) > && TREE_CODE (TREE_OPERAND (rhs, 0)) == SSA_NAME > && integer_zerop (TREE_OPERAND (rhs, 1))) > reexamine = merge_object_sizes (osi, var, TREE_OPERAND (rhs, > 0)); > > > I feel that propagating the size through _5 = *_1 might not be correct in > general, we should only limit it to the case when the RHS is a pointer > defined by .ACCESS_WITH_SIZE? That propagation is not incorrect, but it is incomplete, since (TIL) a MEM_REF with zero offset could be the LHS of a valid gimple statement as well. However AFAICT there's no way to directly reach it like in case of an SSA, you'll need to walk the function to find the statement with a matching LHS. That is essentially option A. I think that's the "correct" solution unless it turns out to be infeasible (too slow, too kludgy, etc.), in which case option B is a reasonable alternative I think.
[Bug libstdc++/120806] std::out_ptr is not conforming to the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120806
--- Comment #1 from Jonathan Wakely ---
This deviation from the standard is intentional, and was part of the original
design, and was present in the reference implementation:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1132r8.html#perf
However the wording in the standard does not permit this optimization. I sent
the following email to the C++ committee's library working group in November
2023 but nobody responded, so I should open an LWG issue:
tl;dr I don't think the current spec for std::out_ptr and std::inout_ptr allows
any optimizations for std::unique_ptr and std::shared_ptr, even though that was
intended by the design.
The https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1132r8.html paper
seems pretty clear that implementations should try to optimize std::out_ptr for
at least std::unique_ptr. One strategy is for std::out_ptr_t::operator
Pointer*() to return the address of the unique_ptr's internal pointer, e.g.
operator Pointer*() const noexcept {
return std::addressof(m_uniqptr.m_ptr);
}
The ~out_ptr destructor then doesn't need to use reset(p) to store the result
into the unique_ptr, because it's already there. However, this optimization
would be observable and so doesn't seem to be permitted. Consider:
#include
#include
std::unique_ptr global;
void c_api_func(int** p)
{
// 1) std::out_ptr ensures this since LWG 3734
assert(global == nullptr);
// 2) and ensures this:
assert(*p == nullptr);
// 3) but nothing says I can't do this:
global.reset(new int(1));
// 4) is this still true?
assert(*p == nullptr);
*p = new int(2);
}
int main()
{
c_api_func(std::out_ptr(global));
}
If the implementation gives direct access to the unique_ptr's member then 4)
will fail, because resetting the global unique_ptr obviously stores to that
member.
N.B. ztd::out_ptr fails the assertion at 1) under all conditions, presumably
LWG 3734 isn't supported.
ztd::out_ptr fails assertions 2) and 4) when using
-DZTD_OUT_PTR_USE_CLEVER_OUT_PTR=1 to optimize the unique_ptr case, and with
NDEBUG it results in a double-free.
My current implementation has a similar clever optimization, but using
friendship instead of UB aliasing. It also fails 4) and instead of a
double-free it leaks memory.
I can make 4) still hold by making out_ptr always have its own pointer member
and return that from operator Pointer*(), and then assigning that pointer to
the unique_ptr's member in the ~out_ptr_t destructor. But if doing
global.reset(...) is still allowed at 3) then the ~out_ptr_t dtor **must** use
s.reset(p) to update the smart pointer. It can't just do s.m_ptr = p; because
that would leak the previous value of s.m_ptr that was set at 3), as my impl
does.
But my understanding from P1132 is that avoiding s.reset(p) is the entire point
of the clever optimizations. So it seems no optimization is currently possible
at all.
Should the standard say users are not allowed to access the smart_ptr while
it's "owned" by out_ptr_t?
I think the implementation should be allowed to assume that Smart& is a unique
reference, similar to the blanket permission given for rvalue references in
[res.on.arguments].
That would disallow 3) and so 4) would still hold.
P1132 also hints at optimizing std::out_ptr_t, T*, D> by
preallocating a shared_ptr control block in the out_ptr_t constructor, so that
~out_ptr_t doesn't allocate when doing s.reset(p, args...). But that would be
observable. Consider std::out_ptr(shptr, my_deleter, my_alloc) which must use
my_alloc to allocate the control block, so it's observable whether that happens
during out_ptr_t construction, or during destruction. The standard is quite
explicit about the effects and when they happen ("Effects: Equivalent to..."
doesn't leave much left to the imagination).
An implementation could choose to only do the pre-allocation optimization when
no custom allocator is provided, but even operator new is observable. I think
out_ptr_t is missing some normative allowance for allocating memory (as hinted
at by the note about the ctor not being noexcept).
Apart from the question of when allocations are allowed to happen, the standard
also guarantees two copies of the deleter: one into tuple during
construction and one into the control block when doing s.reset(p, args...)
during destruction. If we preallocate the control block it seems like it would
make sense to construct the deleter (and any allocator) into the control block
right away, so we don't need to store the tuple at all. But that seems
to be disallowed by the precise number of initializations implied by the
effects.
I think we can maybe argue that making fewer copies is allowed, but I think we
need to say something about when allocations happen.
[Bug libstdc++/120806] std::out_ptr is not conforming to the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120806 --- Comment #2 from Jonathan Wakely --- The implementation in libstdc++ is the one called "friendly" in the P1132R8 paper. This was clearly intended to be allowed: "Teams eager to squeeze out performance realize they can only do this by relying on type-punning shenanigans to extract the actual value out of unique_ptr: this is expressly undefined behavior. However, if an implementation of out_ptr could be friended or shipped by the standard library, it can be implemented without performance penalty." "it would be much more prudent to allow both standard library vendors and users to be able to achieve this performance without hacks, tricks, and other I-promise-it-works-I-swear pledges." It seems very clear to me that the intended design was to allow implementations to perform these optimizations, and if the wording in the standard doesn't allow it, that's a defect in the standard.
[Bug tree-optimization/118669] Misaligned store after vectorization without using misaligned type with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 --- Comment #13 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:37bf13adcda564dfdb28c3aa736f2cac71c73d09 commit r16-1918-g37bf13adcda564dfdb28c3aa736f2cac71c73d09 Author: Richard Biener Date: Wed Jul 2 09:30:05 2025 +0200 tree-optimization/118669 - fixup wrongly aligned loads/stores The vectorizer tracks alignment of datarefs with dr_aligned and dr_unaligned_supported but that's aligned with respect to the target alignment which can be less aligned than the mode used for the access. The following fixes this discrepancy for vectorizing loads and stores. The issue is visible for aarch64 SVE and risc-v where VLA vector modes have larger than element alignment but the target handles element alignment just fine. PR tree-optimization/118669 * tree-vect-stmts.cc (vectorizable_load): Emit loads with proper (element) alignment. (vectorizable_store): Likewise.
[Bug c++/120471] [12/13/14 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:78ce4720d13b3e82a4c718880a9ca9f0e955cf7e commit r13-9781-g78ce4720d13b3e82a4c718880a9ca9f0e955cf7e Author: Jakub Jelinek Date: Tue Jul 1 15:28:10 2025 +0200 c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471] The following testcase is miscompiled since the introduction of UBSan, cp_build_array_ref COND_EXPR handling replaces (cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are SAVE_EXPRs inside of idx, they will be evaluated just in one of the branches and the other uses uninitialized temporaries. Fixed by keeping doing what it did if idx doesn't have side effects and is invariant. Otherwise if op1/op2 are ARRAY_TYPE arrays with invariant addresses or pointers with invariant values, use SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as a new condition and SAVE_EXPR instead of idx for the recursive calls. Otherwise punt, but if op1/op2 are ARRAY_TYPE, furthermore call cp_default_conversion on array, so that COND_EXPR with ARRAY_TYPE doesn't survive in the IL until expansion. 2025-07-01 Jakub Jelinek PR c++/120471 gcc/cp/ * typeck.cc (cp_build_array_ref) : If idx is not INTEGER_CST, don't optimize the case (but cp_default_conversion on array early if it has ARRAY_TYPE) or use SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as new op0 depending on flag_strong_eval_order and whether op1 and op2 are arrays with invariant address or tree invariant pointers. Formatting fixes. gcc/testsuite/ * g++.dg/ubsan/pr120471.C: New test. * g++.dg/parse/pr120471.C: New test. (cherry picked from commit 988e87b66882875b14a6cab11c17516863c74a63)
[Bug tree-optimization/118669] Misaligned store after vectorization without using misaligned type with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669 Richard Biener changed: What|Removed |Added Known to work||16.0 Known to fail||15.1.0 --- Comment #14 from Richard Biener --- This is now fixed on trunk, I plan to backport it for GCC 15.2 but likely not further.
[Bug tree-optimization/120927] [15/16 Regression] 510.parest_r segfaults built with -Ofast -march=znver4 --param vect-partial-vector-usage=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120927
--- Comment #7 from Richard Biener ---
Testcase that segfaults at runtime with -O3 -mavx512bw -mavx512vl --param
vect-partial-vector-usage=1
#include
std::vector quadrature_points;
double weights[5];
static double __attribute__((aligned(64))) wts[]{2., 2., 2., 2., 5.};
void __attribute__((noipa)) foo(unsigned n)
{
for (unsigned i = 0; i < n; ++i)
quadrature_points[i] = weights[i] = wts[i];
}
int main()
{
quadrature_points.push_back (0.);
quadrature_points.push_back (0.);
quadrature_points.push_back (0.);
quadrature_points.push_back (0.);
quadrature_points.push_back (0.);
foo (5);
}
or alternatively the C testcase
static const double a[] = { 1., 2., 3., 4., 5. };
void __attribute__((noipa))
foo (double *b, double *bp, double c, int n)
{
for (int i = 0; i < n; ++i)
b[i] = bp[i] = a[i] * c;
}
int main()
{
double b[5], bp[5];
foo (b, bp, 3., 5);
}
The reason is we run into
static bool
vect_need_peeling_or_partial_vectors_p (loop_vec_info loop_vinfo)
{
...
else if (LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo)
/* ??? When peeling for gaps but not alignment, we could
try to check whether the (variable) niters is known to be
VF * N + 1. That's something of a niche case though. */
|| LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo)
|| !LOOP_VINFO_VECT_FACTOR (loop_vinfo).is_constant (&const_vf)
|| ((tree_ctz (LOOP_VINFO_NITERS (loop_vinfo))
< (unsigned) exact_log2 (const_vf))
/* In case of versioning, check if the maximum number of
iterations is greater than th. If they are identical,
the epilogue is unnecessary. */
&& (!LOOP_REQUIRES_VERSIONING (loop_vinfo)
|| ((unsigned HOST_WIDE_INT) max_niter
/* We'd like to use LOOP_VINFO_VERSIONING_THRESHOLD
but that's only computed later based on our result.
The following is the most conservative approximation. */
> (std::max ((unsigned HOST_WIDE_INT) th,
const_vf) / const_vf) * const_vf
return true;
return false;
which decides that peeling or partial vectors are _not_ necessary as
we are versioning for aliasing and max_niter (== 5) > 8.
But we use LOOP_VINFO_COST_MODEL_THRESHOLD which isn't even computed yet.
Also the code uses > rather than ==, so it's wrong, at least for
the partial vector case.
OTOH we should never even consider an epilogue with a gt VF than its
main loop.
[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747 --- Comment #17 from Filip Kastl --- (In reply to Andrew Pinski from comment #15) > So it looks like (a * b) are closer in value to (vnb12 * 1.2e+1 - c) than > (vnb12 * 1.2e+1) is to (a * b - c) . Btw, for the purpose of me trying to get better at debugging similar things, how did you figure this out? Did you perhaps run gromacs in a debugger and looked at what values those variables usually have? Or did you figure this out from gromacs' source files?
[Bug target/120941] [16 Regression] 10-40% slowdown of 519.lbm_r on Zen{2,3} since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 20-40% |[16 Regression] 10-40%
|slowdown of 519.lbm_r on|slowdown of 519.lbm_r on
|Zen2 since |Zen{2,3} since
|r16-1644-gaba3b9d3a48a07|r16-1644-gaba3b9d3a48a07
--- Comment #1 from Filip Kastl ---
There is also a ~10% slowdown on Zen3, probably the same problem:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=475.477.0
(the same cmdline options)
[Bug c++/120942] New: internal compiler error happend when i lose include some file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942
Bug ID: 120942
Summary: internal compiler error happend when i lose include
some file
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: q1210081098 at gmail dot com
Target Milestone: ---
After running the following code, I received an internal compiler error. I know
this is due to the lack of # include, but it outputs an gcc error
```
#include
#include
#include
#include
int main() {
std::map> gradebook;
// Add students and their grades
gradebook["John"] = {85, 90, 77};
gradebook["Emily"] = {95, 88, 100};
gradebook["Michael"] = {88, 92, 100};
// Calculate the average grade for each student
for (const auto& student : gradebook) {
double average = std::accumulate(student.second.begin(),
student.second.end(), 0.0) / student.second.size();
std::cout << "Average grade for " << student.first << ": " << average
<< "\n";
}
return 0;
}
```
the output is
```
/GCC-15-COVERAGE/include/c++/15.0.1/format: In instantiation of ‘typename
std::basic_format_context<_Out, _CharT>::iterator
std::__format::__formatter_fp<_CharT>::format(_Fp,
std::basic_format_context<_Out, _CharT>&) const [with _Fp = _Float128; _Out =
std::__format::_Sink_iter; _CharT = wchar_t; typename
std::basic_format_context<_Out, _CharT>::iterator =
std::basic_format_context,
wchar_t>::iterator]’:
/GCC-15-COVERAGE/include/c++/15.0.1/format:2251:22: required from ‘typename
std::basic_format_context<_Out, _CharT>::iterator std::formatter<_Tp,
_CharT>::format(_Tp, std::basic_format_context<_Out, _CharT>&) const [with _Out
= std::__format::_Sink_iter; _Tp = _Float128; _CharT = wchar_t;
typename std::basic_format_context<_Out, _CharT>::iterator =
std::basic_format_context,
wchar_t>::iterator]’
2251 | { return _M_f.format(__u, __fc); }
| ~~~^~~
/GCC-15-COVERAGE/include/c++/15.0.1/format:4166:41: required from
‘std::__format::_Formatting_scanner,
wchar_t>::_M_format_arg(std::size_t):: [with auto:38 =
_Float128]’
4166 | this->_M_fc.advance_to(__f.format(__arg, this->_M_fc));
| ~~^~~~
/GCC-15-COVERAGE/include/c++/15.0.1/format:3650:44: required from
‘decltype(auto) std::basic_format_arg<_Context>::_M_visit(_Visitor&&,
std::__format::_Arg_t) [with _Visitor =
std::__format::_Formatting_scanner,
wchar_t>::_M_format_arg(std::size_t)::; _Context =
std::basic_format_context, wchar_t>]’
3650 | return std::forward<_Visitor>(__vis)(_M_val._M_f128);
| ~^~~~
/GCC-15-COVERAGE/include/c++/15.0.1/format:3665:28: required from
‘decltype(auto) std::visit_format_arg(_Visitor&&, basic_format_arg<_Context>)
[with _Visitor = __format::_Formatting_scanner<__format::_Sink_iter,
wchar_t>::_M_format_arg(std::size_t)::; _Context =
basic_format_context<__format::_Sink_iter, wchar_t>]’
3665 | return __arg._M_visit(std::forward<_Visitor>(__vis),
__arg._M_type);
|
~~^~
/GCC-15-COVERAGE/include/c++/15.0.1/format:4155:23: required from ‘constexpr
void std::__format::_Formatting_scanner<_Out,
_CharT>::_M_format_arg(std::size_t) [with _Out =
std::__format::_Sink_iter; _CharT = wchar_t; std::size_t = long
unsigned int]’
4155 | std::visit_format_arg([this](auto& __arg) {
| ~^~
4156 | using _Type = remove_reference_t;
| ~~
4157 | using _Formatter = typename _Context::template
formatter_type<_Type>;
|
~
4158 | if constexpr (is_same_v<_Type, monostate>)
| ~~
4159 | __format::__invalid_arg_id_in_format_string();
| ~~
4160 | else if constexpr (is_same_v<_Type, handle>)
|
4161 | __arg.format(this->_M_pc, this->_M_fc);
| ~~~
4162 | else if constexpr (is_default_constructible_v<_Formatter>)
| ~~
4163 | {
| ~
4164 | _Formatter __f;
| ~~~
4165 | this->_M_pc.advance_to(__f.parse(this->_M_pc));
| ~~~
4166 | this
[Bug debug/120938] discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938
--- Comment #3 from Jan Hubicka ---
Even smaller set of example. Bad profile:
#include
volatile int variablev;
static void inc()
{
variablev++;
}
static int zero = 0;
int main ()
{
for (int i = 0; i < 1; i++)
{
inc();inc();
inc();inc();
}
return 0;
}
good profile:
#include
volatile int variablev;
static void inc()
{
variablev++;
}
static int zero = 0;
int main ()
{
for (int i = 0; i < 1; i++)
{
inc();inc();
inc();
inc();
}
return 0;
}
Only difference is the fourth invocation of inc().
I checked that the problem also reproduces with llvm's profile generator.
If the file is built with clang profiles are OK.
Diff of dwarf2 debug is not that small, I will attach it.
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929 --- Comment #15 from Sam James --- (In reply to qinzhao from comment #14) > (In reply to Siddhesh Poyarekar from comment #13) > > Here's a super-minimal test case: > > > thanks for the smaller testing case, it has the same behavior as the one > Sergei provided in comment #7: On X86 machine, even the older GCC reports > the overflow error. But on aarch64, only the latest GCC reports the overflow > error. > it looks like an old bug in object-size. I can't reproduce that behaviour at all on x86-64. Very odd. It's OK with 12..16 (with your commits reverted for testing).
[Bug debug/120938] discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938 --- Comment #4 from Jan Hubicka --- Created attachment 61793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61793&action=edit good assembly
[Bug debug/120938] discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938 --- Comment #6 from Jan Hubicka --- Created attachment 61795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61795&action=edit Diff
[Bug debug/120938] discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938 --- Comment #5 from Jan Hubicka --- Created attachment 61794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61794&action=edit bad assembly
[Bug c++/120874] internal compiler error: in type_dependent_expression_p, at cp/pt.cc:29442 since 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120874 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. You must have missed you reported this before. *** This bug has been marked as a duplicate of bug 120199 ***
[Bug c++/120748] [16 Regression] New crash with lambda code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120748 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/120199] ICE when using __builtin_addressof on overload function inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120199 --- Comment #3 from Andrew Pinski --- *** Bug 120874 has been marked as a duplicate of this bug. ***
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 Jakub Jelinek changed: What|Removed |Added Target Milestone|15.2|12.5 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed, very sorry.
[Bug target/120946] GCC emits compressed instruction with .option arch, -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120946 --- Comment #5 from Jesse T --- Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=33128
[Bug middle-end/120855] [16 Regression] Recent changes causing ICE in assemble_name_resolve since r16-1738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120855 Thomas Schwinge changed: What|Removed |Added Target|mcore-elf |mcore-elf, nvptx Keywords||patch CC||tschwinge at gcc dot gnu.org Last reconfirmed|2025-06-28 00:00:00 |2025-7-3 --- Comment #3 from Thomas Schwinge --- '--target=nvptx-none' is another target that fails in the same way, and I'm happy to report that this: (In reply to Nathaniel Shead from comment #1) > Created attachment 61747 [details] > possible fix ... indeed does address the breakage. I'm fine to wait for Nathaniel to resolve this.
[Bug libstdc++/108487] [12/13 Regression] ~20-30x slowdown in populating std::vector from std::ranges::iota_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487 Jonathan Wakely changed: What|Removed |Added Target Milestone|12.5|14.3 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Jonathan Wakely --- This can cause problems for code which isn't ready for C++20, as described at https://gcc.gnu.org/gcc-15/porting_to.html#cxx20-iterators As a result, I don't think it should be backported any further, so the performance regression won't be fixed for GCC 12 and 13.
[Bug middle-end/118130] std::vector code quality issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118130 Bug 118130 depends on bug 108487, which changed state. Bug 108487 Summary: [12/13 Regression] ~20-30x slowdown in populating std::vector from std::ranges::iota_view https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/120859] FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120859
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> I think this file just needs `/* { dg-do compile } */`
>
> I will check tomorrow.
I actually think this is the correct fix:
```
diff --git a/gcc/testsuite/gcc.dg/tree-prof/afdo-crossmodule-1b.c
b/gcc/testsuite/gcc.dg/tree-prof/afdo-crossmodule-1b.c
index dd532952f97..79ba529c747 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/afdo-crossmodule-1b.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/afdo-crossmodule-1b.c
@@ -1,3 +1,8 @@
+/* { dg-require-effective-target lto } */
+/* { dg-additional-sources "afdo-crossmodule-1.c" } */
+/* { dg-options "-O3 -flto -fdump-ipa-afdo_offline
-fdump-tree-einline-details" } */
+/* { dg-require-profiling "-fauto-profile" } */
+
extern int foo2 ();
int bar (int (*fooptr) (int (*)()))
```
The reason is because afdo-crossmodule-1b.c has some scans in it.
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f9c43140bee94587cd60c8476db8c0e699206841 commit r15-9920-gf9c43140bee94587cd60c8476db8c0e699206841 Author: Jakub Jelinek Date: Thu Jul 3 22:39:39 2025 +0200 c++: Fix a pasto in the PR120471 fix [PR120940] No idea how this slipped in, I'm terribly sorry. Strangely nothing in the testsuite has caught this, so I've added a new test for that. 2025-07-03 Jakub Jelinek PR c++/120940 * typeck.cc (cp_build_array_ref): Fix a pasto. * g++.dg/parse/pr120940.C: New test. * g++.dg/warn/Wduplicated-branches9.C: New test. (cherry picked from commit dc90649466a54ab61926d88500a05f59a55cb055)
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f3db50e3a41af53f87e94cd31e86f63126b8 commit r14-11876-gf3db50e3a41af53f87e94cd31e86f63126b8 Author: Jakub Jelinek Date: Thu Jul 3 22:39:39 2025 +0200 c++: Fix a pasto in the PR120471 fix [PR120940] No idea how this slipped in, I'm terribly sorry. Strangely nothing in the testsuite has caught this, so I've added a new test for that. 2025-07-03 Jakub Jelinek PR c++/120940 * typeck.cc (cp_build_array_ref): Fix a pasto. * g++.dg/parse/pr120940.C: New test. * g++.dg/warn/Wduplicated-branches9.C: New test. (cherry picked from commit dc90649466a54ab61926d88500a05f59a55cb055)
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dc90649466a54ab61926d88500a05f59a55cb055 commit r16-1990-gdc90649466a54ab61926d88500a05f59a55cb055 Author: Jakub Jelinek Date: Thu Jul 3 22:39:39 2025 +0200 c++: Fix a pasto in the PR120471 fix [PR120940] No idea how this slipped in, I'm terribly sorry. Strangely nothing in the testsuite has caught this, so I've added a new test for that. 2025-07-03 Jakub Jelinek PR c++/120940 * typeck.cc (cp_build_array_ref): Fix a pasto. * g++.dg/parse/pr120940.C: New test. * g++.dg/warn/Wduplicated-branches9.C: New test.
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f3689dc2061481fa789dbf7b6ab55a8e5f52f198 commit r13-9783-gf3689dc2061481fa789dbf7b6ab55a8e5f52f198 Author: Jakub Jelinek Date: Thu Jul 3 22:39:39 2025 +0200 c++: Fix a pasto in the PR120471 fix [PR120940] No idea how this slipped in, I'm terribly sorry. Strangely nothing in the testsuite has caught this, so I've added a new test for that. 2025-07-03 Jakub Jelinek PR c++/120940 * typeck.cc (cp_build_array_ref): Fix a pasto. * g++.dg/parse/pr120940.C: New test. * g++.dg/warn/Wduplicated-branches9.C: New test. (cherry picked from commit dc90649466a54ab61926d88500a05f59a55cb055)
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ed950a9ed384389ff07ac793b7065abe31bcae3f commit r12-11245-ged950a9ed384389ff07ac793b7065abe31bcae3f Author: Jakub Jelinek Date: Thu Jul 3 22:39:39 2025 +0200 c++: Fix a pasto in the PR120471 fix [PR120940] No idea how this slipped in, I'm terribly sorry. Strangely nothing in the testsuite has caught this, so I've added a new test for that. 2025-07-03 Jakub Jelinek PR c++/120940 * typeck.cc (cp_build_array_ref): Fix a pasto. * g++.dg/parse/pr120940.C: New test. * g++.dg/warn/Wduplicated-branches9.C: New test. (cherry picked from commit dc90649466a54ab61926d88500a05f59a55cb055)
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929 --- Comment #11 from Sam James --- Qing, is it the same glibc version in the arm64 environment vs the x86-64 one? I think it might be what Sergei said: > It still needs glibc, but if you would not be able to reproduce I'll > preprocess it as well (I suspect memcpy() macro is crucial there).
[Bug libstdc++/120934] views::concat is ill-formed depending on argument order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120934 --- Comment #4 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c5a17e92ebf0c6f3887fb5698a1114a3fdf50576 commit r16-1986-gc5a17e92ebf0c6f3887fb5698a1114a3fdf50576 Author: Patrick Palka Date: Thu Jul 3 10:55:17 2025 -0400 libstdc++: Update LWG 4166 changes to concat_view::end() [PR120934] In r15-4555-gf191c830154565 we proactively implemented the initial proposed resolution for LWG 4166 which later turned out to be insufficient, since we must also require equality_comparable of the underlying iterators before concat_view could be a common range. This patch implements the updated P/R, requiring all underlying iterators to be forward (which implies equality_comparable) before making concat_view common, which fixes the testcase from this PR. PR libstdc++/120934 libstdc++-v3/ChangeLog: * include/std/ranges (concat_view::end): Refine condition for returning an iterator instead of default_sentinel as per the updated P/R for LWG 4166. * testsuite/std/ranges/concat/1.cc (test05): New test. Reviewed-by: Jonathan Wakely
[Bug middle-end/120369] [15 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug middle-end/120369] [15 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120369 --- Comment #10 from GCC Commits --- The releases/gcc-15 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:2cb1108c0929311f73fc9210d29681ba49607b8d commit r15-9918-g2cb1108c0929311f73fc9210d29681ba49607b8d Author: Andrew Pinski Date: Tue May 20 13:21:28 2025 -0700 middle-end: Fix complex lowering of cabs with no LHS [PR120369] This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that the LHS of the cabs call could be NULL. This seems to only happen at -O0, I tried to produce one that happens at -O1 but needed many different options to prevent the removal of the call. Anyways the fix is just keep around the call if the LHS is null. Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/120369 gcc/ChangeLog: * tree-complex.cc (gimple_expand_builtin_cabs): Return early if the LHS of cabs is null. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr120369-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 95c74f354ae3186e84fbada22d2e7f3845dbb659)
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[15/16 Regression] False|[12/13/14/15/16 Regression] |positive|False positive |-Wduplicated-branches |-Wduplicated-branches |warning |warning Ever confirmed|0 |1 Last reconfirmed||2025-07-03 Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Oops, sorry.
[Bug c++/120940] [12/13/14/15/16 Regression] False positive -Wduplicated-branches warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940 --- Comment #2 from Jakub Jelinek --- Created attachment 61796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61796&action=edit gcc16-pr120940.patch Brown paper bag time, very sorry.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #457 from John Paul Adrian Glaubitz --- I have performed some tests now. The patch to reduce the R0 lifetimes is definitely still required: 0853a85ba96fa8642aac5315812c26a41966fede SH: Try to reduce R0 live ranges Without it, I'm still getting spill failures for R0. The following two are also required as otherwise GCC will ICE during bootstrap: e66b2ce1a032cf771e77c50aca457ad0c92357e6 LRA: Add cannot_substitute_const_equiv_p target hook d2b2702860297263a39f265125e7f504dc4fb56e LRA: Take scratch as implicit unused output reloads Will test now, whether these are still required: 6d2eb03cc070416c7ca8d425c884ad3bfc2b0406 SH: Try to workaround fp-reg related move insns pt.2 2b6413d79a7e12da8267617ca06447dbf4ce080d SH: Try to workaround fp-reg related move insns 51c41253e9ddd7457b4de710ea5271ef564833fd SH: Pin input args to hard-regs via predicates for sfuncs 3e0299ab538700df912479d8da6fc3f32fde9dd2 SH: Tighten memory predicates and constraints
[Bug target/120936] [12/13/14/15/16 Regression] x86_function_profiler emits an unused label by by r5-3767-gecc81e33123d7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936 --- Comment #5 from Jakub Jelinek --- And +FAIL: gcc.target/i386/pr120936-10.c check-function-bodies foo +FAIL: gcc.target/i386/pr120936-11.c check-function-bodies foo +FAIL: gcc.target/i386/pr120936-12.c check-function-bodies foo +FAIL: gcc.target/i386/pr120936-4.c check-function-bodies foo +FAIL: gcc.target/i386/pr120936-5.c check-function-bodies foo +FAIL: gcc.target/i386/pr120936-6.c check-function-bodies foo +FAIL: gcc.target/i386/pr120936-8.c check-function-bodies foo on x86_64-linux.
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929 --- Comment #10 from qinzhao at gcc dot gnu.org --- (In reply to Sergei Trofimovich from comment #7) > > Crashing: > > $ gcc/xgcc -Bgcc -D_FORTIFY_SOURCE=3 -O1 apprentice.c -o bug && ./bug > In file included from /usr/include/string.h:548, > from apprentice.c:4: > In function 'memcpy', > inlined from 'coalesce_entries' at apprentice.c:30:9, > inlined from 'apprentice_load' at apprentice.c:59:3: > /usr/include/bits/string_fortified.h:29:10: warning: > '__builtin___memcpy_chk' writing 9 bytes into a region of size 8 overflows > the destination [-Wstringop-overflow=] >29 | return __builtin___memcpy_chk (__dest, __src, __len, > | ^ >30 | __glibc_objsize0 (__dest)); > | ~~ > *** buffer overflow detected ***: terminated > Aborted (core dumped) > thanks a lot for the testing case. I tried it on both X86 and aarch64 machines, but get different behavior: 1. on aarch64, I can repeat the exactly same issue with the testing case: with my latest trunk gcc, the testing case failed; However, with an earlier gcc, the testing case passed. 2. However on X86, even with the earlier gcc, I can repeat the exactly same failure. So, I am wondering whether you see such behavior only on aarch64 machine? Did you try it on X86? what's the behavior on X86?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #458 from John Paul Adrian Glaubitz --- OK, 51c41253e9ddd7457b4de710ea5271ef564833fd SH: Pin input args to hard-regs via predicates for sfuncs is required for 0853a85ba96fa8642aac5315812c26a41966fede SH: Try to reduce R0 live ranges.
[Bug c++/120942] internal compiler error happend when i lose include some file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2025-07-03 --- Comment #1 from Andrew Pinski --- I can't reproduce this with the released version of GCC 15.1.0 . What options are you passing to GCC?
[Bug tree-optimization/120929] [16 Regression] file-5.45 triggers _FORTIFY_SOURCE false positives since r16-1905-g7165ca43caf470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929 --- Comment #14 from qinzhao at gcc dot gnu.org --- (In reply to Siddhesh Poyarekar from comment #13) > Here's a super-minimal test case: > thanks for the smaller testing case, it has the same behavior as the one Sergei provided in comment #7: On X86 machine, even the older GCC reports the overflow error. But on aarch64, only the latest GCC reports the overflow error. it looks like an old bug in object-size.
[Bug c++/120942] internal compiler error happend when i lose include some file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942 --- Comment #2 from Andrew Pinski --- Also can you provide the full output of "gcc -v" ?
[Bug c++/120716] [16 regression] ICE on https://eel.is/c++draft/expr.const#example-3 in C++23 since r16-149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120716 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/120945] Missed optimization opportunity with std::bind_front
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120945 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-07-03 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59948 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- The difference is in the case of the lambda it is not an indirect function call so the test call/lambda is inlined early into std::ranges::count_if and that will be inlined into count2/test2 to get the non loop version. In the case of std::bind_front, there is an indirect function call. std::ranges::count_if is not early inlined into count1 and the indirect function call is NOT turned into a direct function call until after inlining so we miss out that Foo::find not being inlined and then the loop stays around.
[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747 --- Comment #19 from Andrew Pinski --- (In reply to Andrew Pinski from comment #18) > It is more understanding how floating point works and gave a rounding step. > And that fma does the multiple and addition in infinite precision and only > rounds at the end. Plus the other bug reports have had a similar analysis about numerical error and reassociation.
[Bug c++/120471] [12/13/14 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Jakub Jelinek --- Fixed also for 14.4, 13.5 and 12.5.
[Bug c++/120409] FAIL: g++.dg/coroutines/torture/pr119916.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120409 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Sandoe --- > interesting - it does not show on i686-linux or darwin. Endianess (or strict-alignment) issue? > I am assuming 32b solaris/sparc has 32b pointers? Sure: just a regular ILP32 target. However, I lied: it's the 64-bit test that FAILs, 32-bit is fine: Thread 2 received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0x7edcbf40 in __lwp_sigqueue () from /lib/64/libc.so.1 (gdb) bt #0 0x7edcbf40 in __lwp_sigqueue () from /lib/64/libc.so.1 #1 0x7ed19e24 in raise () from /lib/64/libc.so.1 #2 0x7ece96e4 in abort () from /lib/64/libc.so.1 #3 0x00011c44 in main () at /vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/coroutines/torture/pr119916.C:65
[Bug debug/120938] New: discriminators are not useful in statements doing multiple calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120938
Bug ID: 120938
Summary: discriminators are not useful in statements doing
multiple calls
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
jh@shroud:~> cat d.C
#include
volatile int a;
static int dead ()
{
return 0;
}
static void inc(int b)
{
a++;
}
static void
inline_me (int l)
{
for (int i = 0; i < 1; i++)
{dead();inc(dead ());inc(dead ());}
if (!l)
inline_me (l+1);
printf ("block tail recursion\n");
}
int main ()
{
inline_me (0);
return 0;
}
jh@shroud:~> cat afdo-test
~/trunk-install-new7/bin/gcc -O3 -g $* -o train -g -flto
-fdump-tree-all-details-lineno || exit
perf record -e ex_ret_brn_tkn:Pu -c13 -b ./train || exit
create_gcov --binary train --gcov_version 2 --use_discriminator_encoding
--debug_dump perf.data --gcov a.gcov | tee gcov-debug
~/trunk-install-new7/bin/gcc -O3 -g -fauto-profile=a.gcov -Wauto-profile
-fdump-tree-all-details-lineno -fdump-ipa-all-details -o trained $* || exit
jh@shroud:~> sh afdo-test d.C
gives
d.C:16:14: warning: auto-profile contains inlined function with symbol name inc
instead of symbol name _ZL4deadv [-Wauto-profile]
16 | {dead();inc(dead ());inc(dead ());}
| ^~
d.C:13:1: warning: auto-profile of ‘void inline_me(int)’ contains extra
callsites [-Wauto-profile]
13 | inline_me (int l)
| ^
d.C:13:1: note: call of inc with relative location +3, discriminator 0
d.C:16:14: warning: auto-profile contains inlined function with symbol name inc
instead of symbol name _ZL4deadv [-Wauto-profile]
16 | {dead();inc(dead ());inc(dead ());}
| ^~
d.C:13:1: warning: auto-profile of ‘void inline_me(int)’ contains extra
callsites [-Wauto-profile]
13 | inline_me (int l)
| ^
d.C:13:1: note: call of inc with relative location +3, discriminator 0
The problem here is in the profile info:
_ZL9inline_mei total:27945 head:0
1: 0
2.1: 9315
4: 0
6: 0
7: 0
3.2: inc total:9315
2: 9315
3.4: inc total:9315
2: 9315
5: inline_me total:0
2.1: 0
6: 0
3: inc total:0
2: 0
main total:18780 head:0
1: 0
4: 0
2: inline_me total:18780
2.1: 9390
5: 0
6: 0
3: inc total:9390
2: 9390
Notice that _ZL9inline_mei in offline version correctly records two calls of
"inc" with discriminators 2 and 4. Inline versions in main and inline_me
(which is dead) has only one call with discriminator 0 that gets confused with
call to dead() function...
[Bug target/120624] [14 Backport] aarch64: Incorrect DCE of a ZA restore in SME code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:72b828227f8faf8f0a85735a5c27545378cf20c5 commit r14-11871-g72b828227f8faf8f0a85735a5c27545378cf20c5 Author: Richard Sandiford Date: Thu Jul 3 08:12:42 2025 +0100 aarch64: Incorrect removal of ZA restore [PR120624] The PCS defines a lazy save scheme for managing ZA across normal "private-ZA" functions. GCC currently uses this scheme for calls to all private-ZA functions (rather than using caller-save). Therefore, before a sequence of calls to private-ZA functions, GCC emits code to set up a lazy save. After the sequence of calls, GCC emits code to check whether lazy save was committed and restore the ZA contents if so. These sequences are emitted by the mode-switching pass, in an attempt to reduce the number of redundant saves and restores. The lazy save scheme also means that, before a function can use ZA, it must first conditionally store the old contents of ZA to the caller's lazy save buffer, if any. This all creates some relatively complex dependencies between setup code, save/restore code, and normal reads from and writes to ZA. These dependencies are modelled using special fake hard registers: ;; Sometimes we use placeholder instructions to mark where later ;; ABI-related lowering is needed. These placeholders read and ;; write this register. Instructions that depend on the lowering ;; read the register. (LOWERING_REGNUM 87) ;; Represents the contents of the current function's TPIDR2 block, ;; in abstract form. (TPIDR2_BLOCK_REGNUM 88) ;; Holds the value that the current function wants PSTATE.ZA to be. ;; The actual value can sometimes vary, because it does not track ;; changes to PSTATE.ZA that happen during a lazy save and restore. ;; Those effects are instead tracked by ZA_SAVED_REGNUM. (SME_STATE_REGNUM 89) ;; Instructions write to this register if they set TPIDR2_EL0 to a ;; well-defined value. Instructions read from the register if they ;; depend on the result of such writes. ;; ;; The register does not model the architected TPIDR2_ELO, just the ;; current function's management of it. (TPIDR2_SETUP_REGNUM 90) ;; Represents the property "has an incoming lazy save been committed?". (ZA_FREE_REGNUM 91) ;; Represents the property "are the current function's ZA contents ;; stored in the lazy save buffer, rather than in ZA itself?". (ZA_SAVED_REGNUM 92) ;; Represents the contents of the current function's ZA state in ;; abstract form. At various times in the function, these contents ;; might be stored in ZA itself, or in the function's lazy save buffer. ;; ;; The contents persist even when the architected ZA is off. Private-ZA ;; functions have no effect on its contents. (ZA_REGNUM 93) Every normal read from ZA and write to ZA depends on SME_STATE_REGNUM, in order to sequence the code with the initial setup of ZA and with the lazy save scheme. The code to restore ZA after a call involves several instructions, including conditional control flow. It is initially represented as a single define_insn and is split late, after shrink-wrapping and prologue/epilogue insertion. The split form of the restore instruction includes a conditional call to __arm_tpidr2_restore: (define_insn "aarch64_tpidr2_restore" [(set (reg:DI ZA_SAVED_REGNUM) (unspec:DI [(reg:DI R0_REGNUM)] UNSPEC_TPIDR2_RESTORE)) (set (reg:DI SME_STATE_REGNUM) (unspec:DI [(reg:DI SME_STATE_REGNUM)] UNSPEC_TPIDR2_RESTORE)) ... ) The write to SME_STATE_REGNUM indicates the end of the region where ZA_REGNUM might differ from the real contents of ZA. In other words, it is the point at which normal reads from ZA and writes to ZA can safely take place. To finally get to the point, the problem in this PR was that the unsplit aarch64_restore_za pattern was missing this change to SME_STATE_REGNUM. It could therefore be deleted as dead before it had chance to be split. The split form had the correct dataflow, but the unsplit form didn't. Unfortunately, the tests for this code tended to use calls and asms to model regions of ZA usage, and those don't seem to be affected in the same way. gcc/ PR target/120624 * config/aarch64/aarch64.md (SME_STATE_REGNUM): Expand on comments. * config/aarch64/aarch64-sme.md (aarch64_restore_za): Also set SME_STATE_REGNUM gcc/testsuite/ PR target/120624 * gcc.target/aarch64/sme/za_state_7
[Bug target/120624] [14 Backport] aarch64: Incorrect DCE of a ZA restore in SME code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Sandiford --- Fixed.
[Bug fortran/120711] [15/16 regression] Growing arrays segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120711 --- Comment #9 from GCC Commits --- The releases/gcc-15 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:8b7a779b85df65a29fe3820886cbd72663b6dba4 commit r15-9914-g8b7a779b85df65a29fe3820886cbd72663b6dba4 Author: Andre Vehreschild Date: Wed Jun 25 09:12:35 2025 +0200 Fortran: Fix out of bounds access in structure constructor's clean up [PR120711] A structure constructor's generated clean up code was using an offset variable, which was manipulated before the clean up was run leading to an out of bounds access. PR fortran/120711 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_array_ctor_element): Store the value of the offset for reuse. gcc/testsuite/ChangeLog: * gfortran.dg/asan/array_constructor_1.f90: New test. (cherry picked from commit dff66a690f6d47963e5cb96677d0e194b85948fa)
[Bug target/120933] Turn on -mtls-dialect=gnu2 by default on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #3 from Florian Weimer --- Yes, compatibility with old glibc is a concern, considering this can be difficult to test, and failures can be largely silent.
[Bug fortran/120711] [15/16 regression] Growing arrays segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120711 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Andre Vehreschild --- Backported to gcc-15, closing.
[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747 --- Comment #18 from Andrew Pinski --- (In reply to Filip Kastl from comment #17) > (In reply to Andrew Pinski from comment #15) > > So it looks like (a * b) are closer in value to (vnb12 * 1.2e+1 - c) than > > (vnb12 * 1.2e+1) is to (a * b - c) . > > Btw, for the purpose of me trying to get better at debugging similar things, > how did you figure this out? Did you perhaps run gromacs in a debugger and > looked at what values those variables usually have? Or did you figure this > out from gromacs' source files? It is more understanding how floating point works and gave a rounding step. And that fma does the multiple and addition in infinite precision and only rounds at the end.
[Bug fortran/120711] [15/16 regression] Growing arrays segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120711 --- Comment #11 from Christopher Albert --- Thank you, Andre! I am impressed how fast and professionally this was fixed.
[Bug c++/120409] FAIL: g++.dg/coroutines/torture/pr119916.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120409 --- Comment #3 from Iain Sandoe --- interesting - it does not show on i686-linux or darwin. I am assuming 32b solaris/sparc has 32b pointers?
[Bug target/118886] Invalid fusions on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118886 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- These issues have been resolved on the trunk.
[Bug target/118886] Invalid fusions on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118886 --- Comment #1 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:83d19b5d842dadc1720b57486d4675a238966ba4 commit r16-1984-g83d19b5d842dadc1720b57486d4675a238966ba4 Author: Jeff Law Date: Thu Jul 3 06:44:31 2025 -0600 [RISC-V][PR target/118886] Refine when two insns are signaled as fusion candidates A number of folks have had their fingers in this code and it's going to take a few submissions to do everything we want to do. This patch is primarily concerned with avoiding signaling that fusion can occur in cases where it obviously should not be signaling fusion. Every DEC based fusion I'm aware of requires the first instruction to set a destination register that is both used and set again by the second instruction. If the two instructions set different registers, then the destination of the first instruction was not dead and would need to have a result produced. This is complicated by the fact that we have pseudo registers prior to reload. So the approach we take is to signal fusion prior to reload even if the destination registers don't match. Post reload we require them to match. That allows us to clean up the code ever-so-slightly. Second, we sometimes signaled fusion into loads that weren't scalar integer loads. I'm not aware of a design that's fusing into FP loads or vector loads. So those get rejected explicitly. Third, the store pair "fusion" code is cleaned up a little. We use fusion to model store pair commits since the basic properties for detection are the same. The point where they "fuse" is different. Also this code liked to "return false" at each step along the way if fusion wasn't possible. Future work for additional fusion cases makes that behavior undesirable. So the logic gets reworked a little bit to be more friendly to future work. Fourth, if we already fused the previous instruction, then we can't fuse it again. Signaling fusion in that case is, umm, bad as it creates an atomic blob of code from a scheduling standpoint. Hopefully I got everything correct with extracting this work out of a larger set of changes ð We will contribute some instrumentation & testing code so if I botched things in a major way we'll soon have a way to test that and I'll be on the hook to fix any goof's. From a correctness standpoint this should be a big fat nop. We've seen this make measurable differences in pico benchmarks, but obviously as you scale up to bigger stuff the gains largely disappear into the noise. This has been through Ventana's internal CI and my tester. I'll obviously wait for a verdict from the pre-commit tester. PR target/118886 gcc/ * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Check for fusion being disabled earlier. If PREV is already fused, then it can't be fused again. Be more selective about fusing when the destination registers do not match. Don't fuse into loads that aren't scalar integer modes. Revamp store pair commit support. Co-authored-by: Daniel Barboza Co-authored-by: Shreya Munnangi
[Bug tree-optimization/120939] New: vect_need_peeling_or_partial_vectors_p accesses not yet computed LOOP_VINFO_COST_MODEL_THRESHOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120939 Bug ID: 120939 Summary: vect_need_peeling_or_partial_vectors_p accesses not yet computed LOOP_VINFO_COST_MODEL_THRESHOLD Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- We use that as /* In case of versioning, check if the maximum number of iterations is greater than th. If they are identical, the epilogue is unnecessary. */ && (!LOOP_REQUIRES_VERSIONING (loop_vinfo) || ((unsigned HOST_WIDE_INT) max_niter /* We'd like to use LOOP_VINFO_VERSIONING_THRESHOLD but that's only computed later based on our result. The following is the most conservative approximation. */ > (std::max ((unsigned HOST_WIDE_INT) th, const_vf) / const_vf) * const_vf where also noticable we compare with > and fail to honor the "If they are identical, the epilogue is unnecessary."
[Bug tree-optimization/120780] Missed __builtin_dynamic_object_size optimization(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120780 --- Comment #19 from GCC Commits --- The master branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:72e85d46472716e670cbe6e967109473b8d12d38 commit r16-1972-g72e85d46472716e670cbe6e967109473b8d12d38 Author: Siddhesh Poyarekar Date: Thu Jun 26 17:46:00 2025 -0400 tree-optimization/120780: Support object size for containing objects MEM_REF cast of a subobject to its containing object has negative offsets, which objsz sees as an invalid access. Support this use case by peeking into the structure to validate that the containing object indeed contains a type of the subobject at that offset and if present, adjust the wholesize for the object to allow the negative offset. gcc/ChangeLog: PR tree-optimization/120780 * tree-object-size.cc (inner_at_offset, get_wholesize_for_memref): New functions. (addr_object_size): Call get_wholesize_for_memref. gcc/testsuite/ChangeLog: PR tree-optimization/120780 * gcc.dg/builtin-dynamic-object-size-pr120780.c: New test case. Signed-off-by: Siddhesh Poyarekar
[Bug libstdc++/119742] [C++26] Implement P2697R1, Interfacing bitset with string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742 --- Comment #2 from GCC Commits --- The master branch has been updated by Nathan Myers : https://gcc.gnu.org/g:9930876ed788a7da18ccef0c91f4f12749da1df7 commit r16-1973-g9930876ed788a7da18ccef0c91f4f12749da1df7 Author: Nathan Myers Date: Mon Jun 30 18:55:48 2025 -0400 libstdc++: construct bitset from string_view (P2697) [PR119742] Add a bitset constructor from string_view, per P2697. Fix existing tests that would fail to detect incorrect exception behavior. Argument checks that result in exceptions guarded by "#if HOSTED" are made unguarded because the functions called to throw just call terminate() in free-standing builds. Improve readability in Doxygen comments. Generalize a private member argument-checking function to work with string and string_view without mentioning either, obviating need for guards. The version.h symbol is not "hosted" because string_view, though not specified to be available in free-standing builds, is defined there and the feature is useful there. libstdc++-v3/ChangeLog: PR libstdc++/119742 * include/bits/version.def: Add preprocessor symbol. * include/bits/version.h: Add preprocessor symbol. * include/std/bitset: Add constructor. * testsuite/20_util/bitset/cons/1.cc: Fix. * testsuite/20_util/bitset/cons/6282.cc: Fix. * testsuite/20_util/bitset/cons/string_view.cc: Test new ctor. * testsuite/20_util/bitset/cons/string_view_wide.cc: Test new ctor.
[Bug c++/120409] FAIL: g++.dg/coroutines/torture/pr119916.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120409 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Target|x32 |x32, sparc-sun-solaris2.11 --- Comment #2 from Rainer Orth --- Same on 32-bit Solaris/SPARC.
[Bug libstdc++/110339] Implement C++26 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 Bug 110339 depends on bug 119742, which changed state. Bug 119742 Summary: [C++26] Implement P2697R1, Interfacing bitset with string_view https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/119742] [C++26] Implement P2697R1, Interfacing bitset with string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742 Nathan Myers changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |16.0 Resolution|--- |FIXED --- Comment #3 from Nathan Myers --- Reviewed-by: Jonathan Wakely
[Bug tree-optimization/120927] [15/16 Regression] 510.parest_r segfaults built with -Ofast -march=znver4 --param vect-partial-vector-usage=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120927
--- Comment #6 from Richard Biener ---
So it's interesting, we somehow get a AVX vectorized main loop with a AVX512
vectorized masked epilog. It must have sth to do with max-iterations vs.
actually known ones, but
static const double a[] = { 1., 2., 3., 4., 5. };
void foo (double *b, double c, int n)
{
for (int i = 0; i < n; ++i)
b[i] = a[i] * c;
}
behaves sanely. Still the following makes us ICE compiling
the offending file from SPEC. I'm reducing now since I'm obviously
missing something here. Note that the above, with --param
vect-partial-vector-usage=1 gets us an "epilogue-only" vectorization
using masked AVX512 which was unexpected but kind-of makes sense.
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 2782d61a5fc..5e12fe0e213 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -3757,6 +3757,8 @@ vect_analyze_loop (class loop *loop, gimple
*loop_vectorized_call,
if (loop_vinfo)
{
+ gcc_assert (known_ge (first_vinfo_vf,
+ LOOP_VINFO_VECT_FACTOR (loop_vinfo)));
if (pick_lowest_cost_p
&& orig_loop_vinfo->epilogue_vinfo
&& vect_joust_loop_vinfos (loop_vinfo,
[Bug target/120936] [12/13/14/15/16 Regression] x86_function_profiler emits an unused label by by r5-3767-gecc81e33123d7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936 --- Comment #3 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:349da53f13de274864d01b6ccc466961c472dbe1 commit r16-1971-g349da53f13de274864d01b6ccc466961c472dbe1 Author: H.J. Lu Date: Thu Jul 3 10:13:48 2025 +0800 x86: Emit label only for __mcount_loc section commit ecc81e33123d7ac9c11742161e128858d844b99d Author: Andi Kleen Date: Fri Sep 26 04:06:40 2014 + Add direct support for Linux kernel __fentry__ patching emitted a label, 1, for __mcount_loc section: 1: callmcount .section __mcount_loc, "a",@progbits .quad 1b .previous If __mcount_loc wasn't used, we got an unused label. Update x86_function_profiler to emit label only when __mcount_loc section is used. gcc/ PR target/120936 * config/i386/i386.cc (x86_print_call_or_nop): Add a label argument and use it to print label. (x86_function_profiler): Emit label only when __mcount_loc section is used. gcc/testsuite/ PR target/120936 * gcc.target/i386/pr120936-1.c: New test * gcc.target/i386/pr120936-2.c: Likewise. * gcc.target/i386/pr120936-3.c: Likewise. * gcc.target/i386/pr120936-4.c: Likewise. * gcc.target/i386/pr120936-5.c: Likewise. * gcc.target/i386/pr120936-6.c: Likewise. * gcc.target/i386/pr120936-7.c: Likewise. * gcc.target/i386/pr120936-8.c: Likewise. * gcc.target/i386/pr120936-9.c: Likewise. * gcc.target/i386/pr120936-10.c: Likewise. * gcc.target/i386/pr120936-11.c: Likewise. * gcc.target/i386/pr120936-12.c: Likewise. * gcc.target/i386/pr93492-3.c: Updated. * gcc.target/i386/pr93492-5.c: Likewise. Signed-off-by: H.J. Lu
[Bug c/120837] [12/13/14/15/16 regression] False-positive from -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837 --- Comment #17 from Jakub Jelinek --- Created attachment 61792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61792&action=edit gcc16-pr120837.patch Untested patch which instead of dropping the optimization simply performs everything in sizetype type before final POINTER_PLUS. It isn't recursive admittedly.
[Bug c++/120471] [12/13/14 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #20 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b5f0faa4eb71650a9dde3938c3a98eda710534de commit r12-11244-gb5f0faa4eb71650a9dde3938c3a98eda710534de Author: Jakub Jelinek Date: Tue Jul 1 15:28:10 2025 +0200 c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471] The following testcase is miscompiled since the introduction of UBSan, cp_build_array_ref COND_EXPR handling replaces (cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are SAVE_EXPRs inside of idx, they will be evaluated just in one of the branches and the other uses uninitialized temporaries. Fixed by keeping doing what it did if idx doesn't have side effects and is invariant. Otherwise if op1/op2 are ARRAY_TYPE arrays with invariant addresses or pointers with invariant values, use SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as a new condition and SAVE_EXPR instead of idx for the recursive calls. Otherwise punt, but if op1/op2 are ARRAY_TYPE, furthermore call cp_default_conversion on array, so that COND_EXPR with ARRAY_TYPE doesn't survive in the IL until expansion. 2025-07-01 Jakub Jelinek PR c++/120471 gcc/cp/ * typeck.cc (cp_build_array_ref) : If idx is not INTEGER_CST, don't optimize the case (but cp_default_conversion on array early if it has ARRAY_TYPE) or use SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as new op0 depending on flag_strong_eval_order and whether op1 and op2 are arrays with invariant address or tree invariant pointers. Formatting fixes. gcc/testsuite/ * g++.dg/ubsan/pr120471.C: New test. * g++.dg/parse/pr120471.C: New test. (cherry picked from commit 988e87b66882875b14a6cab11c17516863c74a63)
[Bug libstdc++/120931] [15/16 Regression] std::deque::resize() method fails with -std=c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120931 --- Comment #5 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bc3ec8684f7111a06fde433bbe57caa385b178af commit r16-1966-gbc3ec8684f7111a06fde433bbe57caa385b178af Author: Jonathan Wakely Date: Wed Jul 2 21:54:06 2025 +0100 libstdc++: Fix regression in std::uninitialized_fill for C++98 [PR120931] A typo in r15-4473-g3abe751ea86e34 made it ill-formed to use std::uninitialized_fill with iterators that aren't pointers (or pointers wrapped in our __normal_iterator) if the value type is a narrow character type. libstdc++-v3/ChangeLog: PR libstdc++/120931 * include/bits/stl_uninitialized.h (__uninitialized_fill): Fix typo resulting in call to __do_uninit_copy instead of __do_uninit_fill. * testsuite/20_util/specialized_algorithms/uninitialized_fill/120931.cc: New test.
[Bug fortran/120843] [15/16-Regression, Coarray] Inconsistent ranks for operator reported when coarray ranks differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843 --- Comment #6 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:15413e05eb9cde976b8890cd9b597d0a41a8eb27 commit r16-1967-g15413e05eb9cde976b8890cd9b597d0a41a8eb27 Author: Andre Vehreschild Date: Wed Jul 2 11:06:17 2025 +0200 Fortran: Remove corank conformability checks [PR120843] Remove the checks on coranks conformability in expressions, because there is nothing in the standard about it. When a coarray has no coindexes it it treated like a non-coarray, when it has a full-corank coindex its result is a regular array. So nothing to check for corank conformability. PR fortran/120843 gcc/fortran/ChangeLog: * resolve.cc (resolve_operator): Remove conformability check, because it is not in the standard. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/coindexed_6.f90: Enhance test to have coarray components covered.
[Bug target/120930] [16 Regression] RISC-V: Miscompile at -O[23] with zvl256b -mrvv-vector-bits=zvl since r16-1645-g309dbcea2ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120930 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |16.0 Target||riscv
[Bug target/120908] *tls_(local|global)_dynamic_64_ has an implicit RDI clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908 --- Comment #5 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:d8d5e2a8031e74f08f61ccdd727476f97940c5a6 commit r16-1917-gd8d5e2a8031e74f08f61ccdd727476f97940c5a6 Author: H.J. Lu Date: Thu Jul 3 10:54:39 2025 +0800 x86-64: Add RDI clobber to 64-bit dynamic TLS patterns *tls_global_dynamic_64_largepic, *tls_local_dynamic_64_ and *tls_local_dynamic_base_64_largepic use RDI as the __tls_get_addr argument. Add RDI clobber to these patterns to show it. gcc/ PR target/120908 * config/i386/i386.cc (legitimize_tls_address): Pass RDI to gen_tls_local_dynamic_64. * config/i386/i386.md (*tls_global_dynamic_64_largepic): Add RDI clobber and use it to generate LEA. (*tls_local_dynamic_64_): Likewise. (*tls_local_dynamic_base_64_largepic): Likewise. (@tls_local_dynamic_64_): Add a clobber. gcc/testsuite/ PR target/120908 * gcc.target/i386/pr120908.c: New test. Signed-off-by: H.J. Lu
[Bug c++/120471] [12/13/14 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471 --- Comment #18 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d21bfd170f939625abee3e230a6d41d7e1529ed3 commit r14-11872-gd21bfd170f939625abee3e230a6d41d7e1529ed3 Author: Jakub Jelinek Date: Tue Jul 1 15:28:10 2025 +0200 c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471] The following testcase is miscompiled since the introduction of UBSan, cp_build_array_ref COND_EXPR handling replaces (cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are SAVE_EXPRs inside of idx, they will be evaluated just in one of the branches and the other uses uninitialized temporaries. Fixed by keeping doing what it did if idx doesn't have side effects and is invariant. Otherwise if op1/op2 are ARRAY_TYPE arrays with invariant addresses or pointers with invariant values, use SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as a new condition and SAVE_EXPR instead of idx for the recursive calls. Otherwise punt, but if op1/op2 are ARRAY_TYPE, furthermore call cp_default_conversion on array, so that COND_EXPR with ARRAY_TYPE doesn't survive in the IL until expansion. 2025-07-01 Jakub Jelinek PR c++/120471 gcc/cp/ * typeck.cc (cp_build_array_ref) : If idx is not INTEGER_CST, don't optimize the case (but cp_default_conversion on array early if it has ARRAY_TYPE) or use SAVE_EXPR , SAVE_EXPR , SAVE_EXPR as new op0 depending on flag_strong_eval_order and whether op1 and op2 are arrays with invariant address or tree invariant pointers. Formatting fixes. gcc/testsuite/ * g++.dg/ubsan/pr120471.C: New test. * g++.dg/parse/pr120471.C: New test. (cherry picked from commit 988e87b66882875b14a6cab11c17516863c74a63)
[Bug target/120933] Turn on -mtls-dialect=gnu2 by default on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120933 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-07-03 Status|UNCONFIRMED |NEW --- Comment #5 from H.J. Lu --- We can update ld and glibc to add GLIBC_ABI_GNU2_TLS, similar to GLIBC_ABI_DT_RELR. If inputs have any GNU2 TLS relocations, we add the dependency on GLIBC_ABI_GNU2_TLS. libc.so has the working GNU2 TLS support only if it has GLIBC_ABI_GNU2_TLS.
[Bug testsuite/120923] check-function-bodies doesn't support "1: call mcount"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120923 H.J. Lu changed: What|Removed |Added Last reconfirmed||2025-07-03 Status|UNCONFIRMED |NEW Target Milestone|--- |16.0 Ever confirmed|0 |1
