[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297 --- Comment #4 from Robin Dapp --- I can reproduce this, but only with a qemu VLEN=128, VLEN >= 256 result in the correct value of 234635118.
[Bug tree-optimization/120396] New: unprofitable SLP vectorization, leaves scalar parts live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120396
Bug ID: 120396
Summary: unprofitable SLP vectorization, leaves scalar parts
live
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
A variant of PR 109892.
static double muladd(double x, double y, double z)
{
return x * y + z;
}
double g(double x[], long n)
{
double r0 = 0, r1 = 0;
for (; n; x += 2, n--) {
r0 = muladd(x[0], x[0], r0);
r1 = muladd(x[1], x[1], r1);
x[0] = r0;
x[1] = r1;
}
return r0 + r1;
}
The SLP-vectorized loop at -O2 -mfma (or plain -O2 on AArch64) does strictly
more work than a scalar loop.
[Bug libstdc++/120397] New: std::uninitialized_value_construct cannot create arrays of non-trivially destructible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
Bug ID: 120397
Summary: std::uninitialized_value_construct cannot create
arrays of non-trivially destructible types
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct X { ~X() { } };
void f()
{
X x[1];
x->~X();
std::uninitialized_value_construct(&x, &x+1);
x->~X();
std::uninitialized_value_construct_n(&x, 1);
}
include/c++/15.1.0/bits/stl_construct.h:166:19: error: request for member '~X
[1]' in '* __pointer', which is of non-class type 'X [1]'
166 | __pointer->~_Tp();
| ^~~
The standard just says that constructed elements need to be destroyed if an
exception happens, it doesn't say how. We call std::_Destroy(first, cur) to
destroy them, but that can't handle arrays in C++17 (for C++20 it calls
std::destroy_at which does handle arrays).
This is related to Bug 94831 but this time for types with non-trivial
destructors, so that std::_Destroy isn't a no-op.
We could either stop using std::_Destroy(first, cur) in the uninitialized algos
(no thanks), or make std::_Destroy(first, cur) handle arrays, or make
std::_Destroy(*first) handle arrays.
The latter would be consistent with std::destroy_at, and would mean that
std::_Destroy_n(first, n) would also work for arrays. But to make the code
above (and all similar cases?) work it's sufficient to handle it in
std::_Destroy(first, last). All the uninitialized algos use that.
[Bug c/120354] Flexible array union in the middle is not reported by -Wflex-array-member-not-at-end option when flexible array member is not the last one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120354 --- Comment #2 from Ella Ma --- Sorry, I made a mistake when making the example. This problem happens when the flex-array member is not the last, **and the members below it are in a record type**. (GCC will report if they are in integer types) Which means, in the original example, the `y` elements in `union X` and `union Y` should be in a struct or union (it is also not reported even if the struct or union is empty), rather than `int`. Details and comparison with Clang in https://godbolt.org/z/zjPY9z5E7, please ignore the previous link to godbolt.
[Bug libstdc++/120397] std::uninitialized_value_construct cannot create arrays of non-trivially destructible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
When the type has a non-trivial default constructor then uninitialized_default
has the same problem:
#include
struct X { X() { } ~X() { } };
void val(X (*x)[1])
{
std::uninitialized_value_construct(x, x+1);
}
void val_n(X (*x)[1])
{
std::uninitialized_value_construct_n(x, 1);
}
void def(X (*x)[1])
{
std::uninitialized_default_construct(x, x+1);
}
void def_n(X (*x)[1])
{
std::uninitialized_default_construct_n(x, 1);
}
I don't think any of the other std::uninitialized_xxx algos in C++17 can be
used to create arrays, so it's only these ones.
[Bug libstdc++/120397] std::uninitialized_value_construct cannot create arrays of non-trivially destructible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > We could either stop using std::_Destroy(first, cur) in the uninitialized > algos (no thanks), or make std::_Destroy(first, cur) handle arrays, or make > std::_Destroy(*first) handle arrays. > > The latter would be consistent with std::destroy_at, and would mean that > std::_Destroy_n(first, n) would also work for arrays. But to make the code > above (and all similar cases?) work it's sufficient to handle it in > std::_Destroy(first, last). All the uninitialized algos use that. Hmm, but std::destroy(first, last) and std::destroy_n(first, n) in C++17 do not support arrays, and we implement them by calling std::_Destroy(first, last) and std::_Destroy_n(first, n) respectively. So if _Destroy is "fixed" to handle arrays, then it would affect std::destroy.
[Bug tree-optimization/120398] New: vectorization emits shuffles followed by scalar adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120398
Bug ID: 120398
Summary: vectorization emits shuffles followed by scalar adds
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
Another variant of PR 109892. GCC manages to emit vector multiplications at
-O2, but corresponding additions are all scalar, and there's tons of shuffles
in between. At the same time, on AArch64 this loop is vectorized properly.
static float muladd(float x, float y, float z)
{
return x * y + z;
}
float g(float x[], long n)
{
float r0 = 0, r1 = 0;
for (; n; x += 2, n--) {
r0 = muladd(x[0], x[0], r0);
r1 = muladd(x[1], x[1], r1);
}
return r0 + r1;
}
[Bug libstdc++/120397] std::uninitialized_value_construct cannot create arrays of non-trivially destructible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
--- Comment #4 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -118,7 +118,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
~_UninitDestroyGuard()
{
if (__builtin_expect(_M_cur != 0, 0))
- std::_Destroy(_M_first, *_M_cur);
+ _S_destroy(_M_first, *_M_cur);
}
_GLIBCXX20_CONSTEXPR
@@ -129,6 +129,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
private:
_UninitDestroyGuard(const _UninitDestroyGuard&);
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wc++17-extensions"
+ template
+ _GLIBCXX20_CONSTEXPR
+ static void
+ _S_destroy(_Iter __first, _Iter __last)
+ {
+#if __cplusplus == 201703L
+ using _ValT = typename iterator_traits<_Iter>::value_type;
+ if constexpr (is_array<_ValT>::value)
+ for (; __first != __last; ++__first)
+ _S_destroy(*__first, *__first + extent<_ValT>::value);
+ else
+#endif
+ std::_Destroy(__first, __last);
+ }
+#pragma GCC diagnostic push
};
// This is the default implementation of std::uninitialized_copy.
[Bug tree-optimization/109892] SLP failure with explicit fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109892 --- Comment #3 from Alexander Monakov --- In the meantime codegen for 'g' substantially regressed (with or without -mfma), PR 120398.
[Bug libstdc++/120399] New: Rename and refactor std::__uninitialized_default* algos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120399 Bug ID: 120399 Summary: Rename and refactor std::__uninitialized_default* algos Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- We have std::__uninitialized_default which is used to implement std::uninitialized_value_construct, and std::__uninitialized_default_novalue which is used for std::uninitialized_default_construct. These names are confusing. We should rename the __ forms to match the standard names. And at the same time, make them use constexpr if instead of dispatching to specializations of class templates.
[Bug libstdc++/120399] Rename and refactor std::__uninitialized_default* algos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120399 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |16.0
[Bug c++/120400] New: C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Bug ID: 120400
Summary: C++ FE optimisations reorder && operands.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
In the coroutines code we need to guard some accesses to frame data - since
that might become invalidated by completion of a coroutine body.
So we have code-gen like this:
tree fr_cleanup_if = begin_if_stmt ();
tree cond = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x);
cond = build2_loc (loc, TRUTH_ANDIF_EXPR, boolean_type_node,
coro_before_return, cond);
finish_if_stmt_cond (cond, fr_cleanup_if);
finish_expr_stmt (delete_frame_call);
finish_then_clause (fr_cleanup_if);
finish_if_stmt (fr_cleanup_if);
The intention is that "coro_before_return" guards the (potentially) unsafe
access of iarc_x.
When we build this with O0 then:
0) coroutine codegen:
s if (E |EC|test::_Coro_before_return &&
!test::_Coro_initial_await_resume_called)
CxE operator delete (E (void*)E cvt[coro::promise_type*,VD
test::_Coro_frameptr], E 40);<>
1) tree-original:
if (_Coro_before_returnD.9342 &&
!_Coro_initial_await_resume_calledD.9343)
{
2) gimple:
if (_Coro_before_returnD.9342 != 0) goto ; else goto
;
:
_3 = _Coro_frameptrD.9340->_Coro_initial_await_resume_calledD.9326;
_4 = ~_3;
if (_4 != 0) goto ; else goto ;
:
=== All OK and doing what's expected.
When we build at O1+:
0) coroutine codegen
s if (E |EC|test::_Coro_before_return &&
!test::_Coro_initial_await_resume_called)
(same)
1) tree-original:
if (!_Coro_initial_await_resume_calledD.9346 &&
_Coro_before_returnD.9345)
ouch! .. the operands are reversed - UB can happen
2) tree-gimple:
_3 = _Coro_frameptrD.9343->_Coro_initial_await_resume_calledD.9329;
_4 = ~_3;
_5 = _Coro_before_returnD.9345 & _4;
if (_5 != 0) goto ; else goto ;
and this is even worse, it's all unconditional.
I guess this is happening in folding or genericization.
Perhaps the argument is that "it's OK to reorder" because if any of the
operations would be UB then we can do what we like... however, that does rather
make defensive programming hard.
I'd categorise it as wrong-code .. but perhaps I'm missing something.
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Jonathan, thoughts on the library side? E.g. std::uncaught_exceptions is just declared in the header, but if it needs to be constexpr it needs some inline definition but for ABI reasons better should call the original function. std::current_exception is also defined out of line, for constant evaluation it better use some helper builtin which returns void * and construct exception_ptr from that.
[Bug cobol/119520] cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119520 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org CC||jklowden at gcc dot gnu.org Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from James K. Lowden --- "This program uses several typedefs", did you intend to provide this program? :-) typedef is barely tested, lacking examples. But perhaps this PR is actually solved because it's rooted in CDF >>DEFINE, which (I hope) has been corrected. This small program works, PROGRAM-ID. "TYPEDEF". DATA DIVISION. WORKING-STORAGE SECTION. 77 INT PIC 9(8) is typedef. 01 SOME-GID USAGE INT VALUE ZERO. PROCEDURE DIVISION. move 77 to some-gid. if SOME-GID = 77 then display "the GID is 77" else display "the GID is " some-gid ", boo!". $ gcobol -dialect mf typedef.cbl && ./a.out the GID is 77 Marking resolved until further notice.
[Bug cobol/119461] record layout done in odd ways
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119461 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-22 --- Comment #1 from James K. Lowden --- This is an "old" bug by our standards atm, and I don't know if it's still relevant. Bob will know.
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
Alex Coplan changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Summary|[15/16 Regression] ICE in |[14/15/16 Regression] ICE
|vect pass "error: |in vect "error: definition
|definition in block 9 does |in block 9 does not
|not dominate use in block |dominate use in block 3"
|3" since|with early break
|r15-6807-g68326d5d1a593d|
Keywords||ice-checking
--- Comment #4 from Alex Coplan ---
The following simplified testcase ICEs in the same way back to the introduction
of early break vectorization in GCC 14:
char a;
unsigned long long t[2][22];
int u[22];
void f(void) {
for (int v = 0; v < 22; v++)
for (_Bool w = 0; w < (u[v] < 0) + 1; w = 1)
a *= 0 != t[w][v];
}
So for AArch64, that's r14-6823-g1bcc07aeb47c0ed7eb50eac8a4e057d6336669ab, but
since that's the AArch64 introduction of the cbranch optab it would of course
be different for other targets.
Either way this shows the problem is independent of alignment peeling and
likely a generic early break vect issue.
Note that it's a checking ICE so needs --enable-checking=yes or compiling with
-fchecking.
[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting/eiline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 ad...@u-group13.org changed: What|Removed |Added Known to work||10.3.1 --- Comment #12 from ad...@u-group13.org --- GCC ARM cross compiler v10.3.1 on my laptop (Pop!_OS 22.04 w/ kernel v6.12.10-76061203-generic) works normally with previously given command.
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #2 from Jakub Jelinek ---
Created attachment 61493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61493&action=edit
gcc16-pr117785-wip.patch
Very early WIP patch.
This can right now handle a trivial exception throwing + catching, e.g.
struct S { constexpr S (); constexpr S (const S &); constexpr ~S (); };
struct T : public S { constexpr T (); constexpr T (int); constexpr T (const T
&); constexpr ~T (); };
constexpr S::S () {}
constexpr S::S (const S &) {}
constexpr S::~S () {}
constexpr T::T () {}
constexpr T::T (int) {}
constexpr T::T (const T &) {}
constexpr T::~T () {}
constexpr int
foo ()
{
try {
throw T (1);
}
catch (int &a)
{
return 1;
}
catch (const S &b)
{
return 2;
}
catch (...)
{
return 3;
}
return 4;
}
constexpr int a = foo ();
static_assert (a == 2);
As the IL constexpr evaluation sees already uses calls to
__cxa_{allocate_exception,free_exception,throw,rethrow,begin_catch,end_catch}
I've implemented it so far as if they were magic constexpr builtins.
Guess for some parts of the library implementation we'll need to add further
builtins, but many of the libsupc++ headers have methods implemented out of
line in libsupc++.a/libstdc++.so, so not sure how to deal with their constexpr
definition when we want to call the out of line implementation with ABI
compatible name unless if consteval.
On the compiler side, I guess the largest task is probably to pass jump_target
unconditionally (so drop the default argument) and deal with throws
(jump_target) in tons of places - the existing "jumps" like
switch/break/continue/return were expected to happen only in statements, not
arbitrary subexpressions (although that actually isn't the case for say ({ if
(something) return; 42; }) in arbitrary subexpressions), but e.g. for binary
expressions too chose a random example we will need if (throws (jump_target))
return NULL_TREE; or so after evaluating the arguments before evaluating the
rest.
[Bug middle-end/120372] canonicalize_comparison uses gen_move_insn to calcualate the cost of the constant formation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120372 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:bb7b6d9ad7f89ebc68c9d1eff16bec95f6e81cd9 commit r16-823-gbb7b6d9ad7f89ebc68c9d1eff16bec95f6e81cd9 Author: Andrew Pinski Date: Tue May 20 15:10:15 2025 -0700 aarch64: Improve rtx_cost for constants in COMPARE [PR120372] The middle-end uses rtx_cost on constants with the outer of being COMPARE to find out the cost of a constant formation for a comparison instruction. So for aarch64 backend, we would just return the cost of constant formation in general. We can improve this by seeing if the outer is COMPARE and if the constant fits the constraints of the cmp instruction just set the costs to being one instruction. Built and tested for aarch64-linux-gnu. PR target/120372 gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_rtx_costs ): Handle if outer is COMPARE and the constant can be handled by the cmp instruction. gcc/testsuite/ChangeLog: * gcc.target/aarch64/imm_choice_comparison-2.c: New test. Signed-off-by: Andrew Pinski
[Bug middle-end/120372] canonicalize_comparison uses gen_move_insn to calcualate the cost of the constant formation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120372 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:21a487046f4acda0d7d3aaed08a99501bd0430d3 commit r16-822-g21a487046f4acda0d7d3aaed08a99501bd0430d3 Author: Andrew Pinski Date: Tue May 20 14:48:58 2025 -0700 expand: Use rtx_cost directly instead of gen_move_insn for canonicalize_comparison. This is the first part in fixing PR target/120372. The current code for canonicalize_comparison, uses gen_move_insn and rtx_cost to find out the cost of generating a constant. This is ok in most cases except sometimes the comparison instruction can handle different constants than a simple set intruction can do. This changes to use rtx_cost directly with the outer being COMPARE just like how prepare_cmp_insn handles that. Note this is also a small speedup and small memory improvement because we are not creating a move for the constant any more. Since we are not creating a psedu-register any more, this also removes the check on that. Also adds a dump so we can see why one choice was chosen over the other. Build and tested for aarch64-linux-gnu. gcc/ChangeLog: * expmed.cc (canonicalize_comparison): Use rtx_cost directly instead of gen_move_insn. Print out the choice if dump is enabled. Signed-off-by: Andrew Pinski
[Bug middle-end/120372] canonicalize_comparison uses gen_move_insn to calcualate the cost of the constant formation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120372 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |16.0 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug libstdc++/120399] Rename and refactor std::__uninitialized_default* algos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120399 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-22 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > And at the same time, make them use constexpr if instead of dispatching to > specializations of class templates. Similar changes were done to std::uninitialized_copy etc. as part of r15-4473-g3abe751ea86e34, but in that case we had to keep the class templates for C++98 mode. The __uninitialized_default and __uninitialized_default_novalue algos only exist for C++11 and later, so that's not an issue here.
[Bug target/119590] macOS 15.4 SDK is not GCC compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590 Alisdair Meredith changed: What|Removed |Added CC||alisdairm at me dot com --- Comment #7 from Alisdair Meredith --- For a short term workaround adding `-D_Alignof=alignof` to your command lines should work -- at least according to my quick testing. If gcc were to add `_Alignof` support in C++, we might still need that -D hack in order to build the initial compiler --- but that assumes we do not wait for Apple to update their SDK, if they believe that this is an issue they are concerned about.
[Bug target/70557] uint64_t zeroing on 32-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70557 --- Comment #14 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:c77085970ec98916e12e079a5a9d9530b86aae71 commit r16-824-gc77085970ec98916e12e079a5a9d9530b86aae71 Author: Siarhei Volkau Date: Thu May 22 08:52:17 2025 -0600 [PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32 Patch is originally from Siarhei Volkau . RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit pattern to recognize that we can store 0.0 into memory using x0 as the source register. This patch only affects RISC-V. It has been regression tested on riscv64-elf. Jeff has also tested this in his tester (riscv64-elf and riscv32-elf) with no regressions. PR target/70557 gcc/ * config/riscv/riscv.md (movdi_32bit): Add "J" constraint to allow storing 0 directly to memory.
[Bug target/119590] macOS 15.4 SDK is not GCC compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590 --- Comment #8 from Iain Sandoe --- (In reply to Alisdair Meredith from comment #7) > For a short term workaround adding `-D_Alignof=alignof` to your command > lines should work -- at least according to my quick testing. > > If gcc were to add `_Alignof` support in C++, For the macOS development branches (on my GH) I have added an option to support this clang extension (which defaults to 'on' for macOS targets) - whether there will be any appetite for accepting it 'upstream' remains to be seen. >we might still need that -D > hack in order to build the initial compiler --- but that assumes we do not > wait for Apple to update their SDK, if they believe that this is an issue > they are concerned about. If the initial/host bootstrap compiler is GCC, (necessary to support Ada or D) then yes; if that compiler is clang, then the extension should already be accepted.
[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting/eiline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 Andrew Pinski changed: What|Removed |Added Known to work|10.3.1 | --- Comment #13 from Andrew Pinski --- (In reply to admin from comment #12) > GCC ARM cross compiler v10.3.1 on my laptop (Pop!_OS 22.04 w/ kernel > v6.12.10-76061203-generic) works normally with previously given command. Not with the reduced testcase.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 Andrew Pinski changed: What|Removed |Added Component|middle-end |c++ --- Comment #3 from Andrew Pinski --- that is TRUTH_ANDIF_EXPR being converted into TRUTH_AND_EXPR in fold because fold thinks coro_before_return and cond don't have side effects as they are normal decls at the point fold is called.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 --- Comment #4 from Iain Sandoe --- (In reply to Andrew Pinski from comment #3) > that is TRUTH_ANDIF_EXPR being converted into TRUTH_AND_EXPR in fold because > fold thinks coro_before_return and cond don't have side effects as they are > normal decls at the point fold is called. hmm .. perhaps if a DECL has a D_V_E that should be blocked? (one of the decls is "normal" coro_before_return ,,, bu the other is not - it has a D_V_E pointing to the coroutine frame, and the folder probably should not be reasoning about that). ?
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > (In reply to Andrew Pinski from comment #3) > > that is TRUTH_ANDIF_EXPR being converted into TRUTH_AND_EXPR in fold because > > fold thinks coro_before_return and cond don't have side effects as they are > > normal decls at the point fold is called. > > hmm .. perhaps if a DECL has a D_V_E that should be blocked? > (one of the decls is "normal" coro_before_return ,,, bu the other is not - > it has a D_V_E pointing to the coroutine frame, and the folder probably > should not be reasoning about that). > > ? I must say it's also somewhat odd that the folder chooses the more expensive condition to come first - but then if there's no short-circuiting then all the ops will be done anyway.
[Bug cobol/119634] compile error: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119634 --- Comment #1 from Simon Sobisch --- rechecked with today's debian package (now gcc 16), the result is identical, also with -dialect ibm Note: current versions still document the USE statement for procedures https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=statement-debugging-declarative#LSH-DEBUGGING but as I said before it would also be much better if the parser would be able to understand that (even it it places these parts into the "Sorry" bin) and can go on parsing.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #7)
> I think if you set TREE_SIDE_EFFECTS on the decls that have a D_V_E, then it
> might just work.
i can also try that (but I'd want to avoid doing something that's possibly
fragile).
note that:
int foo (bool *a)
{
if (a && !*a)
return 6;
return 42;
}
behaves as expected.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #9 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > I think if you set TREE_SIDE_EFFECTS on the decls that have a D_V_E, then it
> > might just work.
>
> i can also try that (but I'd want to avoid doing something that's possibly
> fragile).
>
> note that:
>
> int foo (bool *a)
> {
> if (a && !*a)
> return 6;
> return 42;
> }
>
> behaves as expected.
Right because INDIRECT_REF has TREE_SIDE_EFFECTS set on it when it is built.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 --- Comment #7 from Andrew Pinski --- I think if you set TREE_SIDE_EFFECTS on the decls that have a D_V_E, then it might just work.
[Bug cobol/119638] WRITE FROM x BEFORE Y raises compile error (SQ207M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119638 --- Comment #2 from Simon Sobisch --- Ooops - current debian package results in gcobol tests/cobol85/SQ/SQ207M.CBL (null):0: confused by earlier errors, bailing out That seems like a sever bug (@jklowden: feel free to create a new one for this or just fix it apart from this issue)
[Bug cobol/119883] codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883 Simon Sobisch changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Simon Sobisch --- It is correct now. Old result: Return value '0' Current result, as expected: Step: 1, Arg: 5, Return: 5 Step: 2, Arg: 4, Return: 5 Step: 3, Arg: 3, Return: 5 Step: 4, Arg: 2, Return: 5 Step: 5, Arg: 1, Return: 5 Return value '5'
[Bug target/120263] RISC-V: FRM not restored if clobbered via inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120263 Vineet Gupta changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Vineet Gupta --- Currently inline asm is the only way to set the FRM w/o save/restore so this bug is just invalid. In the test the second vfadd will execute with RM 4 set by inline asm/
[Bug cobol/119821] FE (parser): CONFIGURATION SECTION rejects valid code - empty paragraphs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119821 Simon Sobisch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Sobisch --- resolved with current debian package
[Bug cobol/119805] FE: COMP-5 / COMP-X issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119805 --- Comment #1 from Simon Sobisch --- still failing with today's package
[Bug cobol/119768] FE: parsing PIC N and NAT is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119768 --- Comment #1 from Simon Sobisch --- still happens; note: for improved error handling the "guessed Alphanumeric-edited" could be used to internally define nat, for example as plain PIC X, that would prevent the second error
[Bug cobol/119520] cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119520 Simon Sobisch changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #2 from Simon Sobisch --- checking with the given example program and gcobol debian package from yesterday "directly": TYPEDEF.cob:5:37: error: USAGE TYPENAME is not ISO syntax, requires -dialect mf 5 |01 SOME-GID USAGE INT VALUE ZERO. | ^ TYPEDEF.cob:8:8: error: cannot MOVE '77' (FldLiteralN) to 'SOME-GID' (Fld) 8 |move 77 to some-gid. |^ cobol1: error: failed compiling TYPEDEF.cob For improved error handling I'd recommend to leave the first error in, but to internally still apply the typedef - which would prevent strange follow-up errors like the second one (there are likely much more in bigger programs). The example though is something else: it is when dropping the TYPEDEF line. And this does not abort any more (same result w/wo the dialect): TYPEDEF.cob:5:37: error: DATA-ITEM 'INT' not found 5 |01 SOME-GID USAGE INT VALUE ZERO. | ^ TYPEDEF.cob:8:8: error: cannot MOVE '77' (FldLiteralN) to 'SOME-GID' (Fld) 8 |move 77 to some-gid. |^ cobol1: error: failed compiling TYPEDEF.cob To improve error handling here (that will help for a lot of other cases as well!): look at the VALUE clause, if numeric then fallback to UNSIGNED BINARY-DOUBLE, if alpanumeric/national/utf8 then PIC X/N/U of necessary size. ... and speaking of that (@jklowden you may want to move some or all of those suggestions out to a feature request ticket of the priority you think is reasonable): when dropping the definition for some-gid the result is: TYPEDEF.cob:8:19: error: DATA-ITEM 'some-gid' not found 8 |move 77 to some-gid. | ^ TYPEDEF.cob:8:19: error: invalid receiving operand TYPEDEF.cob:9:11: error: DATA-ITEM 'SOME-GID' not found 9 |if SOME-GID = 77 then | ^ TYPEDEF.cob:12:32: error: DATA-ITEM 'some-gid' not found 12 | display "the GID is " some-gid ", boo!". |^ cobol1: error: failed compiling TYPEDEF.cob cc1 would only error the first time, then stays silent about that identifier (and don't calculate it in -fmax-errors). One way to do this is to internally create a data-item with that name, similar to the one above; that still allows checking for type mismatches later on, for example, and would also work around other issues like the following: TYPEDEF.cob:8:19: error: DATA-ITEM 'some-gid' not found 8 |move 77 to some-gid. | ^ TYPEDEF.cob:8:19: error: invalid receiving operand compilation terminated due to -fmax-errors=2. (that is one error, but currently counted as two)
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Iain Sandoe changed:
What|Removed |Added
Version|15.0|16.0
--- Comment #1 from Iain Sandoe ---
trivial reproducer:
int foo (bool a, bool b)
{
if (a && !b)
return 6;
return 42;
}
I seee the same back to 10.5 (on x86_64-darwin21).
[Bug middle-end/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
Andrew Pinski changed:
What|Removed |Added
Component|c++ |middle-end
--- Comment #2 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #1)
> trivial reproducer:
>
>
> int foo (bool a, bool b)
> {
> if (a && !b)
> return 6;
> return 42;
> }
>
> I seee the same back to 10.5 (on x86_64-darwin21).
This is coming from fold ...
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 --- Comment #6 from Andrew Pinski --- (In reply to Iain Sandoe from comment #5) > > I must say it's also somewhat odd that the folder chooses the more expensive > condition to come first - but then if there's no short-circuiting then all > the ops will be done anyway. That comes from tree_swap_operands_p: /* Put variables last. */ if (DECL_P (arg1)) return false; if (DECL_P (arg0)) return true;
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 --- Comment #10 from Iain Sandoe --- (In reply to Iain Sandoe from comment #8) > (In reply to Andrew Pinski from comment #7) > > I think if you set TREE_SIDE_EFFECTS on the decls that have a D_V_E, then it > > might just work. > > i can also try that (but I'd want to avoid doing something that's possibly > fragile). Setting that on the decls does "work" (as I read tree.h that is effectively making those vars "volatile"). I'll do this for now, but would be interested if there's some better strategy (other than doing two nested ifs).
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #8 from Robert Dubner --- I don't like making blind changes. I need to duplicate the report you created so that I know that any changes I make actually fix cppcheck outputs without creating new ones. The "problems" reported by Cppcheck are not causing any difficulties that I am aware of. Certainly the various test suites are all succeeding with those problems in place. Jim has repaired some of them. I don't know which. The source code has changed significantly since you first posted about it, so I can't be sure about line numbers. So, in order for cppcheck to be useful, especially in the face of its extensive configurability, what I find to be Cppcheck's sketchy documentation, and my current complete ignorance of how to use it, it would be very useful for me to know exactly how you are using it as a starting point. I guess I am asking you to treat it like a bug report. If Cppcheck .cfg files have been created for coping with GCC source code fiels, I would appreciate knowing what they are. There must be complete command lines for running cppcheck and for grepping the result; I need to know what those are. Because right now I can't seem to make it work at all. I regard learning how to use Cppcheck in a way consistent with what you have developed as at least as important as making stylistic changes about clarifying operator precedence.
[Bug fortran/85750] [12/13/14/15/16 Regression] Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 --- Comment #16 from GCC Commits --- The releases/gcc-15 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6fb3dd1de63e48a0cc465973f9de24f680c3fde5 commit r15-9721-g6fb3dd1de63e48a0cc465973f9de24f680c3fde5 Author: Harald Anlauf Date: Thu May 15 21:07:07 2025 +0200 Fortran: default-initialization and functions returning derived type [PR85750] Functions with non-pointer, non-allocatable result and of derived type did not always get initialized although the type had default-initialization, and a derived type component had the allocatable or pointer attribute. Rearrange the logic when to apply default-initialization. PR fortran/85750 gcc/fortran/ChangeLog: * resolve.cc (resolve_symbol): Reorder conditions when to apply default-initializers. gcc/testsuite/ChangeLog: * gfortran.dg/alloc_comp_auto_array_3.f90: Adjust scan counts. * gfortran.dg/alloc_comp_class_3.f03: Remove bogus warnings. * gfortran.dg/alloc_comp_class_4.f03: Likewise. * gfortran.dg/allocate_with_source_14.f03: Adjust scan count. * gfortran.dg/derived_constructor_comps_6.f90: Likewise. * gfortran.dg/derived_result_5.f90: New test. (cherry picked from commit d31ab498b12ebbe4f50acb2aa240ff92c73f310c)
[Bug fortran/85750] [12/13/14 Regression] Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13/14/15/16 Regression] |[12/13/14 Regression] |Default initialization of |Default initialization of |derived type array missing |derived type array missing --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-16, and on 15-branch so far.
[Bug cobol/120401] New: gcobol allows arithmetic on alphanumeric fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120401 Bug ID: 120401 Summary: gcobol allows arithmetic on alphanumeric fields Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- A PIC XX. *> alphanumeric B PIC XBX. *> alphanumeric-edited C PIC 99. COMPUTE B = C * C COMPUTE A = C * C should error, but compiles with gcobol Same may be true with national/national-edited/utf8.
[Bug target/120144] [15/16 Regression] ICE when building libstdc++ on mips64-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120144 Giovanni Bajo changed: What|Removed |Added CC||giovannibajo at gmail dot com, ||syq at gcc dot gnu.org --- Comment #8 from Giovanni Bajo --- YunQiang, do you think we can get the fixed in time for 15.2? Currently 15.1 is broken on mips64-elf for default o64 ABI
[Bug tree-optimization/120396] [12/13/14/15/16 Regression] unprofitable SLP vectorization, leaves scalar parts live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120396 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.5 Known to work||11.2.0 Keywords||missed-optimization, ||needs-bisection Summary|unprofitable SLP|[12/13/14/15/16 Regression] |vectorization, leaves |unprofitable SLP |scalar parts live |vectorization, leaves ||scalar parts live Known to fail||12.2.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/120396] [12/13/14/15/16 Regression] unprofitable SLP vectorization, leaves scalar parts live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120396 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-22
[Bug c++/120395] Calls to std::__is_constant_evaluated() hurt codegen at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-05-22 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/120397] std::uninitialized_value_construct cannot create arrays of non-trivially destructible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120397
--- Comment #3 from Jonathan Wakely ---
~_UninitDestroyGuard()
{
if (__builtin_expect(_M_cur != 0, 0))
std::_Destroy(_M_first, *_M_cur);
}
If we handle arrays here then it doesn't impact other uses of std::_Destroy
[Bug c++/120385] [14/15/16 Regression] GCC 14 incorrectly accepts array prvalues with certain operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385 Jason Merrill changed: What|Removed |Added Last reconfirmed||2025-05-22 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jason Merrill --- https://cplusplus.github.io/CWG/issues/2548.html
[Bug cobol/119805] FE: COMP-5 / COMP-X issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119805 --- Comment #2 from Simon Sobisch --- ... no, only fails without dialect; with gnu/ibm now compiles
[Bug c++/120395] Calls to std::__is_constant_evaluated() hurt codegen at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |16.0 Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed by r16-828-g26b50c5fed8b03 (wrong PR number in the comment, oops)
[Bug c/120402] New: gcobol does not check precedence of PIC characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120402 Bug ID: 120402 Summary: gcobol does not check precedence of PIC characters Product: gcc Version: 13.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- see ISO's table for that; note: U is nearly identical to N for example gcobol currently allows XX.XX while it should only allow for XXBXX.
[Bug modula2/120389] Assigning a CHAR to an INTEGER crashes the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120389 --- Comment #2 from Gaius Mulley --- Created attachment 61494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61494&action=edit Proposed fix which incompatible types in Xindr Here is a proposed patch. $ cat badarray.mod MODULE badarray3 ; VAR x: ARRAY [1..5] OF INTEGER ; BEGIN x[1] := 'c'; END badarray3. $ gm2 badarray3.mod badarray3.mod: In function ‘_M2_badarray3_init’: badarray3.mod:6:9: error: assignment check caught mismatch between expression and ‘c’ 6 |x[1] := 'c'; |~^~
[Bug tree-optimization/120403] New: Can't collapse two equality into one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120403
Bug ID: 120403
Summary: Can't collapse two equality into one
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
struct s {
int x, y;
};
bool cmp(struct s s1, struct s s2) {
return s1.x == s2.x && s1.y == s2.y;
}
struct t {
int16_t x, y;
};
bool cmp_t(struct t s1, struct t s2) {
return s1.x == s2.x && s1.y == s2.y;
}
$ gcc -O3 generates
```asm
cmp(s, s):
xor eax, eax
cmp edi, esi
je .L5
ret
.L5:
sar rdi, 32
sar rsi, 32
cmp edi, esi
seteal
ret
cmp_t(t, t):
xor eax, eax
cmp di, si
je .L9
ret
.L9:
sar edi, 16
sar esi, 16
cmp di, si
seteal
ret
```
clang -O3 generates
```asm
cmp(s, s):
cmp rdi, rsi
seteal
ret
cmp_t(t, t):
cmp edi, esi
seteal
ret
```
https://godbolt.org/z/8j71anzTW
[Bug target/120404] RISC-V: inline asm FRM write ignored by FRM save/restore machinery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120404 --- Comment #1 from Andrew Pinski --- How is this different from PR 120263?
[Bug tree-optimization/120403] Can't collapse two equality into one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120403 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- There might be a dup of this bug already.
[Bug target/120404] New: RISC-V: inline asm FRM write ignored by FRM save/restore machinery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120404
Bug ID: 120404
Summary: RISC-V: inline asm FRM write ignored by FRM
save/restore machinery
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: vineetg at gcc dot gnu.org
Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, pan2.li at intel dot com,
rdapp at gcc dot gnu.org
Target Milestone: ---
This is extracted from
gcc/testsuite/gcc.target/riscv/rvv/base/float-point-frm-run-1.c
which passes but I think is wrong.
static void
set_frm (int frm)
{
__asm__ volatile ( "fsrm %0" : :"r"(frm) : "frm");
}
main
set_frm (4);
test_float_point_frm_run_1 (op1, op2, vl);
assert_equal (4, get_frm (), "Outer: frm should be equal");# prints 4 !=
0
vfloat32m1_t __attribute__ ((noinline))
test_float_point_frm_run_1 (vfloat32m1_t op1, vfloat32m1_t op2, size_t vl)
{
vfloat32m1_t result;# upon entry global frm is 4
set_frm (0);# global frm set to 0
result = __riscv_vfadd_vv_f32m1_rm (op1, result, 1, vl); # local clobber 1
assert_equal (1, get_frm (), "Inner: frm should be equal");
return result; # expected to restore frm 4
}
the save/restore in function ignores the inline asm setting it to 0.
inline asm is the only way global frm state is set in RISC-V, so it being
ignored for the "prev" global seems weird.
I believe this happened because of current implementation (gcc 15 release)
which generates an unconditional early/eager FRM save on function entry which
captured the global state at the start and not when really needed.
My FRM removes the early/eager save and hence fails this test.
Per discussions with Robin this behaviour is
1. Wrong
2. Implementation driven
thus needs to be changed.
[Bug c/105863] RFE: C23 #embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #21 from Jakub Jelinek --- Implemented for GCC 15.1 (both C and C++).
[Bug c++/119930] [15/16 regression] g++.dg/coroutines/torture/pr103953.C FAILs with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930 --- Comment #11 from Martin Jambor --- (In reply to Sam James from comment #4) > -fno-ipa-cp works It does not help for me, can you double check, please?
[Bug tree-optimization/111873] [12/13/14/15 regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111873 --- Comment #20 from GCC Commits --- The releases/gcc-14 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:92d8b9970ea2ed59010a5f1a394cb98adffa63e8 commit r14-11797-g92d8b9970ea2ed59010a5f1a394cb98adffa63e8 Author: Martin Jambor Date: Wed May 14 12:08:24 2025 +0200 tree-sra: Do not create stores into const aggregates (PR111873) This patch fixes (hopefully the) one remaining place where gimple SRA was still creating a load into const aggregates. It occurs when there is a replacement for a load but that replacement is not type compatible - typically because it is a single field structure. I have used testcases from duplicates because the original test-case no longer reproduces for me. gcc/ChangeLog: 2025-05-13 Martin Jambor PR tree-optimization/111873 * tree-sra.cc (sra_modify_expr): When processing a load which has a type-incompatible replacement, do not store the contents of the replacement into the original aggregate when that aggregate is const. gcc/testsuite/ChangeLog: 2025-05-13 Martin Jambor * gcc.dg/ipa/pr120044-1.c: New test. * gcc.dg/ipa/pr120044-2.c: Likewise. * gcc.dg/tree-ssa/pr114864.c: Likewise. (cherry picked from commit 9d039eff453f777c58642ff16178c1ce2a4be6ab)
[Bug modula2/120389] Assigning a CHAR to an INTEGER crashes the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120389 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:895a8abad245365940939911e3d0de850522791e commit r16-832-g895a8abad245365940939911e3d0de850522791e Author: Gaius Mulley Date: Thu May 22 22:03:22 2025 +0100 PR modula2/120389 ICE if assigning a constant char to an integer array This patch fixes an ICE which occurs if a constant char is assigned into an integer array. The fix it to introduce type checking in M2GenGCC.mod:CodeXIndr. gcc/m2/ChangeLog: PR modula2/120389 * gm2-compiler/M2GenGCC.mod (CodeXIndr): Check to see that the type of left is assignment compatible with the type of right. gcc/testsuite/ChangeLog: PR modula2/120389 * gm2/iso/fail/badarray3.mod: New test. Signed-off-by: Gaius Mulley
[Bug c++/119930] [15/16 regression] g++.dg/coroutines/torture/pr103953.C FAILs with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930 --- Comment #12 from Sam James --- (In reply to Martin Jambor from comment #11) > (In reply to Sam James from comment #4) > > -fno-ipa-cp works > > It does not help for me, can you double check, please? I can't reproduce that now either (i.e. doesn't help).
[Bug c++/120395] Calls to std::__is_constant_evaluated() hurt codegen at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395 --- Comment #3 from Jonathan Wakely --- Thanks!
[Bug target/114860] [14/15/16 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #11 from Ramana Radhakrishnan --- So, WONTFIX ?
[Bug target/120405] bfloat16-complex.c fails with -mcpu=neoverse-v2 but works with -mcpu=cortex-a57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120405 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 111876 ***
[Bug c++/120406] New: Modules ICE when including spdlog in Global Module Fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120406
Bug ID: 120406
Summary: Modules ICE when including spdlog in Global Module
Fragment
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisi57001 at gmail dot com
Target Milestone: ---
Code:
module;
#include
export module logging;
class Logger {
spdlog::logger logger_{"Logger"};
};
CMake:
add_library(Logging)
target_sources(Logging
PUBLIC
FILE_SET CXX_MODULES
BASE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/modules
FILES modules/logger.cppm
)
target_compile_features(Logging PUBLIC cxx_std_23)
target_link_libraries(Logging PUBLIC spdlog::spdlog)
target_compile_options(Logging PUBLIC -freport-bug)
Output:
FAILED: CMakeFiles/Logging.dir/modules/logger.cppm.o
CMakeFiles/Logging.dir/logging.gcm
/sbin/g++ -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -isystem
/home/chris/.vcpkg-clion/vcpkg/installed/x64-linux/include -g -std=gnu++23
-fdiagnostics-color=always -freport-bug -MD -MT
CMakeFiles/Logging.dir/modules/logger.cppm.o -MF
CMakeFiles/Logging.dir/modules/logger.cppm.o.d -fmodules-ts
-fmodule-mapper=CMakeFiles/Logging.dir/modules/logger.cppm.o.modmap -MD
-fdeps-format=p1689r5 -x c++ -o CMakeFiles/Logging.dir/modules/logger.cppm.o -c
/home/chris/cpp/vulkan-modules/modules/logger.cppm
/home/chris/cpp/vulkan-modules/modules/logger.cppm:5:8: internal compiler
error: in core_vals, at cp/module.cc:6641
5 | export module logging;
|^~
0x26d6c51 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2730d98 internal_error(char const*, ...)
???:0
0x7153c9 fancy_abort(char const*, int, char const*)
???:0
0x8583ea depset::hash::find_dependencies(module_state*)
???:0
0x8596e3 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0x86bb05 finish_module_processing(cpp_reader*)
???:0
0x7e989c c_parse_final_cleanups()
???:0
0xa1ea8a c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See
for instructions.
Preprocessed source stored into /tmp/ccws2Kfq.out file, please attach this to
your bugreport.
ninja: build stopped: subcommand failed.
>From what I can tell this ICE is extremely inconsistent. Earlier I could
compile this without any issues despite including more dependencies and even
importing std. After recompiling the file (because I accidentally added a
newline) I ran into the ICE again. I feel like the fickleness might be an issue
with how CMake handles modules (maybe because of compilation order or using
wrongly generated files) but it is an ICE nonetheless.
[Bug libstdc++/120407] New: [12.3/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407
Bug ID: 120407
Summary: [12.3/13/14/15/16 Regression] Binary size manifold for
static linked MinGW target (e.g.
std::__throw_system_error)
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Compiling the following C++ code for mingw-w64 using `-O2 -s -static` creates a
896 KiB executable instead of 119 KiB since git commit
releases/gcc-12.2.0-633-g00ac6fa3f2a.
#include
namespace __gnu_cxx {
/* Disable the verbose termination handler by overwriting it. */
void __verbose_terminate_handler() {}
} /* namespace __gnu_cxx */
int main() {
std::__throw_system_error(0);
return 0;
}
For me it is unclear how this commit can cause such an increase in size.
Especially since the commit claims to provide better dead code elemination
opportunities. The commit was found via git bisect.
[Bug middle-end/111876] bf16 complex mul/div does not work when the target has +fp16 support or when -fexcess-precision=16 is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876 Andrew Pinski changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- *** Bug 120405 has been marked as a duplicate of this bug. ***
[Bug target/120405] New: bfloat16-complex.c fails with -mcpu=neoverse-v2 but works with -mcpu=cortex-a57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120405 Bug ID: 120405 Summary: bfloat16-complex.c fails with -mcpu=neoverse-v2 but works with -mcpu=cortex-a57 Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ramana at gcc dot gnu.org Target Milestone: --- Strangely the testcase gcc.dg/bfloat16-complex.c passes with base v8 but fails with v8.2 and above with the link time error as below at all optimization levels. /local/home/ramanara/build/gcc/xgcc -O2 -B/local/home/ramanara/build/gcc/ /local/home/ramanara/gcc-14.3.0-RC-20250515/gcc/testsuite/gcc.dg/torture/bfloat16-complex.c -fdiagnostics-plain-output-O0-lm -o ./bfloat16-complex.exe --save-temps -mcpu=neoverse-n1 /usr/bin/ld: ./bfloat16-complex.o: in function `main': bfloat16-complex.c:(.text+0x6d4): undefined reference to `__mulbc3' /usr/bin/ld: bfloat16-complex.c:(.text+0x76c): undefined reference to `__divbc3' Hit while testing the RC for 14.3 with a compiler that defaults to neoverse-v2 . Will try trunk next.
[Bug c++/89867] internal compiler error: in layout_type, at stor-layout.c:2578 with auto and attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89867
Jack Lloyd changed:
What|Removed |Added
CC||lloyd at randombit dot net
--- Comment #8 from Jack Lloyd ---
I just encountered this with `strub` attribute
void surprise() {
__attribute__((strub)) auto lol = 5;
}
Fails with GCC 14.2, 15.1 and trunk.
[Bug libstdc++/120407] [12.3/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/cgit/gcc/commit/?id=00ac6fa3f2a
[Bug tree-optimization/120357] [15/16 Regression] ICE in vect pass "error: definition in block 9 does not dominate use in block 3" since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 Alex Coplan changed: What|Removed |Added Keywords|needs-bisection | Summary|[15/16 Regression] RISC-V: |[15/16 Regression] ICE in |ICE in vect pass "error:|vect pass "error: |definition in block 9 does |definition in block 9 does |not dominate use in block |not dominate use in block |3" |3" since ||r15-6807-g68326d5d1a593d Target|riscv |riscv, aarch64-*-* --- Comment #2 from Alex Coplan --- I can reproduce it on AArch64 too with just -O3 -fwhole-program. Taking a look.
[Bug tree-optimization/120357] [15/16 Regression] ICE in vect pass "error: definition in block 9 does not dominate use in block 3" since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
--- Comment #3 from Alex Coplan ---
This version ICEs with just -O3 on AArch64 (no longer needs -fwhole-program),
and fixes the -Woverflow warning:
char a;
void b(int d, int o, unsigned long long t[][22], int u[]) {
for (int v = 0; v < d + 1488232569; v += o + 952017568)
for (_Bool w = 0; w < (u[v] < 0) + 1; w = 1)
a *= 0 != t[w][v];
}
static const int d = -1488232547;
static const int o = 3342949729;
unsigned long long t[2][22];
int u[2];
int main() {
b(d, o, t, u);
}
[Bug c++/120395] New: Calls to std::__is_constant_evaluated() hurt codegen at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
Bug ID: 120395
Summary: Calls to std::__is_constant_evaluated() hurt codegen
at -O0
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
void x(int);
[[gnu::always_inline]] inline bool
is_constant_evaluated()
{ return __builtin_is_constant_evaluated(); }
struct Iter
{
typedef int value_type;
int& operator*() const;
Iter& operator++();
bool operator!=(const Iter&) const;
};
void f(Iter first, Iter last)
{
if (__is_trivial(Iter::value_type))
if (!is_constant_evaluated())
return;
for (; first != last; ++first)
x(*first);
}
At -O1 this is fine, the code compiles away completey as expected. But at -O0
the always_inline function seems to not be inlined, or to act as though it
isn't.
Even though the function f is not constexpr, so can never be constant
evaluated, the generated code includes the loop, which should be dead code:
f(Iter, Iter):
pushrbp
mov rbp, rsp
sub rsp, 16
mov eax, 0
xor eax, 1
testal, al
jne .L7
jmp .L5
.L6:
lea rax, [rbp-1]
mov rdi, rax
callIter::operator*() const
mov eax, DWORD PTR [rax]
mov edi, eax
callx(int)
lea rax, [rbp-1]
mov rdi, rax
callIter::operator++()
.L5:
lea rdx, [rbp-2]
lea rax, [rbp-1]
mov rsi, rdx
mov rdi, rax
callIter::operator!=(Iter const&) const
testal, al
jne .L6
jmp .L1
.L7:
nop
.L1:
leave
ret
If we comment out the if (!is_constant_evaluated()) check then the code is
ideal:
f(Iter, Iter):
pushrbp
mov rbp, rsp
nop
pop rbp
ret
(again, this is for -O0 so it's not a single instruction like at -O1 but it's
what I expect for -O0).
If we replace the always_inline function and just call
__builtin_is_constant_evaluated() directly, the code is ideal. So why does an
always_inline function that calls the builtin not produce the same code as the
builtin? Using the builtin directly isn't an option for the library code.
Is there anything we can do to remove this overhead for
std::__is_constant_evaluated() in libstdc++? Newer C++ standards require us to
put those checks in more and more places, but I didn't realise the effect on
codegen could be so significant.
I'd really prefer not to have to replace the always_inline function with a
macro that expands directly to the builtin (or to `if consteval` for C++23).
(As a separate issue, I've noticed that std::is_constant_evaluated() isn't
marked always_inline, which should be fixed so it's at least on a par with
std::__is_constant_evaluated(), even if that has bad codegen for -O0.)
[Bug c++/120395] Calls to std::__is_constant_evaluated() hurt codegen at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120395
--- Comment #1 from Jonathan Wakely ---
This isn't actually related to the builtin, we get the same thing for any
always_inline function that returns a constant:
void x(int);
[[gnu::always_inline]]
inline bool always_true() { return true; }
struct Iter
{
typedef int value_type;
int& operator*() const;
Iter& operator++();
bool operator!=(const Iter&) const;
};
void f(Iter first, Iter last)
{
if (__is_trivial(Iter::value_type))
if (always_true())
return;
// unreachable dead code!
for (; first != last; ++first)
x(*first);
}
So there's probably a dup of this.
[Bug cobol/119638] WRITE FROM x BEFORE Y raises compile error (SQ207M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119638 --- Comment #1 from Simon Sobisch --- ping @jklowden
[Bug cobol/119256] Capture source ranges for tokens in gcobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #5 from Simon Sobisch --- Yes, the range is off by one. @jklowden: Is there any reason to not merge the range part in?
[Bug target/120360] Horrible code generation for trivial decrement with test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120360 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5f4e794fd3efb0e44a6b5afdead95033df69c41b commit r16-815-g5f4e794fd3efb0e44a6b5afdead95033df69c41b Author: Jakub Jelinek Date: Thu May 22 09:09:48 2025 +0200 i386: Extend *cmp_minus_1 optimizations also to plus with CONST_INT [PR120360] As mentioned by Linus, we can't optimize comparison of otherwise unused result of plus with CONST_INT second operand, compared against zero. This can be done using just cmp instruction with negated constant and say js/jns/je/jne etc. conditional jumps (or setcc). We already have *cmp_minus_1 instruction which handles it when (as shown in foo in the testcase) the IL has MINUS rather than PLUS, but for constants except for the minimum value the canonical form is with PLUS. The following patch adds a new pattern and predicate to handle this. 2025-05-22 Jakub Jelinek PR target/120360 * config/i386/predicates.md (x86_64_neg_const_int_operand): New predicate. * config/i386/i386.md (*cmp_plus_1): New pattern. * gcc.target/i386/pr120360.c: New test.
[Bug cobol/119332] cobol frontend does not support version dump options specified in --help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119332 --- Comment #3 from Simon Sobisch --- Instead of "/dev/null" you can also write "banana", it doesn't matter. Seems like the option parsing is broken "somewhere".
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
Joe Ramsay changed:
What|Removed |Added
CC||joe.ramsay at arm dot com
--- Comment #5 from Joe Ramsay ---
Hello! I have discovered a similar issue, commenting in case another data point
is useful. The following:
#include
_Float16 norm(_Float16 re, _Float16 im) {
return sqrtf(re * re + im * im);
}
compiled with -march=armv8-a+fp16 -O3 gives
norm:
fmulh1, h1, h1
fmadd h1, h0, h0, h1
fcvts0, h1
fcmps0, #0.0
bpl .L4
stp x29, x30, [sp, -32]!
mov x29, sp
str s1, [sp, 28]
bl sqrtf
ldr s1, [sp, 28]
ldp x29, x30, [sp], 32
fsqrt h0, h1
ret
.L4:
fsqrt h0, h1
ret
and with -ffast-math added gives:
norm:
fmulh1, h1, h1
fmadd h0, h0, h0, h1
fsqrt h0, h0
ret
I think GCC is being overly cautious here - the fast FSQRT case is fine without
fast-math (the optimal sequence is emitted without -ffast-math for single- and
double-precision floats).
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #7 from Jakub Jelinek ---
(In reply to Alex Coplan from comment #6)
> I suppose that example boils down to whether code like:
>
> _Bool f(_Float16 a) {
> return a * a >= 0;
> }
> _Bool g(float a) {
> return a * a >= 0;
> }
>
> can be optimised to return true. We currently do it with -ffast-math but
> not without.
And it is correct like that. If a is a NaN (qNaN or sNaN), then a * a >= 0 is
false.
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #6 from Alex Coplan ---
I suppose that example boils down to whether code like:
_Bool f(_Float16 a) {
return a * a >= 0;
}
_Bool g(float a) {
return a * a >= 0;
}
can be optimised to return true. We currently do it with -ffast-math but not
without.
[Bug tree-optimization/120231] GCC fails to notice that (double)u64 is non-negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231 --- Comment #8 from Jakub Jelinek --- In any case, #c5 and onwards is completely unrelated to this PR, which is about value ranges for casts from integers to floating point and vice versa. So, please move that elsewhere.
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367 --- Comment #6 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:04f2be72b1deecd6c6d454e000cfc0cb16db957c commit r16-819-g04f2be72b1deecd6c6d454e000cfc0cb16db957c Author: Jonathan Wakely Date: Wed May 21 15:29:02 2025 +0100 libstdc++: Fix vector(from_range_t, R&&) for exceptions [PR120367] Because this constructor delegates to vector(a) the object has been fully constructed and the destructor will run if an exception happens. That means we need to set _M_finish == _M_start so that the destructor doesn't try to destroy any elements. libstdc++-v3/ChangeLog: PR libstdc++/120367 * include/bits/stl_vector.h (_M_range_initialize): Initialize _M_impl._M_finish. * testsuite/23_containers/vector/cons/from_range.cc: Check with a type that throws on construction. exceptions during construction. Reviewed-by: Patrick Palka
[Bug c++/120377] ICE with fmtlib and modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377 --- Comment #4 from Cameron Angus --- Managed to build from source, and indeed the reduced repro is fine, and my own code is also no longer giving the original ICE that it was. So seems the underlying issue must have been addressed in the last few days. I have some other ICEs but they'll need separate reduction so will file new issues. Feel free to close this, thanks.
[Bug c++/120409] New: FAIL: g++.dg/coroutines/torture/pr119916.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120409 Bug ID: 120409 Summary: FAIL: g++.dg/coroutines/torture/pr119916.C Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x32 I got FAIL: g++.dg/coroutines/torture/pr119916.C -O0 execution test FAIL: g++.dg/coroutines/torture/pr119916.C -O1 execution test FAIL: g++.dg/coroutines/torture/pr119916.C -O2 execution test FAIL: g++.dg/coroutines/torture/pr119916.C -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: g++.dg/coroutines/torture/pr119916.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: g++.dg/coroutines/torture/pr119916.C -O3 -g execution test FAIL: g++.dg/coroutines/torture/pr119916.C -Os execution test with -mx32 on x86-64.
[Bug target/120410] New: [15/16 Regression] [SH] XTRCT instruction is no longer selected for shift after multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120410
Bug ID: 120410
Summary: [15/16 Regression] [SH] XTRCT instruction is no longer
selected for shift after multiplication
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zack+gcc at buhman dot org
Target Milestone: ---
Target: sh*-*-*
Fixed point multiplication, as in:
int32_t fpmul_16_16(int32_t a, int32_t b)
{
int64_t tmp = (int64_t)a * (int64_t)b;
return tmp >> 16;
}
Is a common pattern on SH-2.
This function should be compiled as, and the GCC code generation in all
versions from versions 4 through 14 inclusive was:
dmuls.l r5,r4
sts macl,r0
sts mach,r1
rts
xtrct r1,r0
However, GCC >= 15.1 compiles the function as:
dmuls.l r5,r4
sts macl,r0
sts mach,r1
shll16 r1
shlr16 r0
rts
add r1,r0
This is a fairly impactful regression for the typical use-case for SH-2, where
large numbers of fixed-point multiplications are performed.
I confirmed this regression exists both in GCC 15.1 and the latest GCC 16
master.
https://godbolt.org/z/zaoPreK7b
[Bug middle-end/120276] [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- The regression is 16 only, so fixed now.
[Bug target/120404] RISC-V: inline asm FRM write ignored by FRM save/restore machinery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120404 --- Comment #2 from Vineet Gupta --- (In reply to Andrew Pinski from comment #1) > How is this different from PR 120263? PR120263 posited, incorrectly that inline asm need to save/restore around them. That was just a misunderstadning because currently thats the only way to globally set FRM (for enabling fesetround () and friends). I closed it as INVALID. Save/restore frm around standalone inline asm behavior we have today is correct. This is pointing out incorrect behavior when inline asm setting frm is followed by an intrinsic needing to change the RM. Current behavior is to ignore/override the set from inline asm when restoring the static mode set by intrinsic which is wrong. the inline asm set should be treated as last global set and should be the one restored upon function return, not the prior global mode on function entry.
[Bug libstdc++/120407] [12.3/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-22 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Can you provide the preprocessed source? Also since you are linking to a static binary, can you attach the before and after linker map?
[Bug tree-optimization/120408] New: Missed memset (len + 1) tree build_string() in gcc/tree.cc at 98575a51f588428a8c5c9d7c28d473c4a22caa7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120408 Bug ID: 120408 Summary: Missed memset (len + 1) tree build_string() in gcc/tree.cc at 98575a51f588428a8c5c9d7c28d473c4a22caa7e Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kaelfandrew at gmail dot com Target Milestone: --- Created attachment 61495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61495&action=edit C code Compiling the C code attachment shows f0_slow() is not optimize like f0() with flags -O3 -fallow-store-data-races from godbolt -v: Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/gcc Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20250522/configure --prefix=/opt/compiler-explorer/gcc-build/staging --enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2,cobol --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build-gcc-035ab47366eb7560a9c69b2ebc7307c309e9e909-binutils-2.42 Thread model: posix Supported LTO compression algorithms: zlib gcc version 16.0.0 20250522 (experimental) (Compiler-Explorer-Build-gcc-035ab47366eb7560a9c69b2ebc7307c309e9e909-binutils-2.42) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-fno-verbose-asm' '-S' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' /opt/compiler-explorer/gcc-trunk-20250522/bin/../libexec/gcc/x86_64-linux-gnu/16.0.0/cc1 -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/ -quiet -dumpdir /app/ -dumpbase output.c -dumpbase-ext .c -masm=intel -mtune=generic -march=x86-64 -g -version -fdiagnostics-color=always -fno-verbose-asm -o /app/output.s GNU C23 (Compiler-Explorer-Build-gcc-035ab47366eb7560a9c69b2ebc7307c309e9e909-binutils-2.42) version 16.0.0 20250522 (experimental) (x86_64-linux-gnu) compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/include /opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. Compiler executable checksum: 6344123aa07ae9474e9bb3b0aee8dab3 COMPILER_PATH=/opt/compiler-explorer/gcc-trunk-20250522/bin/../libexec/gcc/x86_64-linux-gnu/16.0.0/:/opt/compiler-explorer/gcc-trunk-20250522/bin/../libexec/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-trunk-20250522/bin/../libexec/gcc/:/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../x86_64-linux-gnu/bin/ LIBRARY_PATH=/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/:/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/:/opt/compiler-explorer/gcc-trunk-20250522/bin/../lib/gcc/x86_64-linux-gnu/16.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/
[Bug middle-end/120276] [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276 Ramana Radhakrishnan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-22 CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan --- Is this an ICE on 15.0 or something that's on trunk only as the bisection points to a version post stage1 started ?
[Bug c++/120406] Modules ICE when including spdlog in Global Module Fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120406 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Nathaniel Shead --- Thanks for the report! I downloaded spdlog and tried myself: we ICE on this line: case OPTIMIZATION_NODE: case TARGET_OPTION_NODE: // FIXME: Our representation for these two nodes is a cache of // the resulting set of options. Not a record of the options // that got changed by a particular attribute or pragma. Should // we record that, or should we record the diff from the command // line options? The latter seems the right behaviour, but is // (a) harder, and I guess could introduce strangeness if the // importer has set some incompatible set of optimization flags? gcc_unreachable (); break; So a dup of PR108080. *** This bug has been marked as a duplicate of bug 108080 ***
[Bug c++/108080] ICE: in module.cc:core_vals with -fmodule-header and #pragma GCC target / optimize (shows up in fmt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108080 Nathaniel Shead changed: What|Removed |Added CC||chrisi57001 at gmail dot com --- Comment #15 from Nathaniel Shead --- *** Bug 120406 has been marked as a duplicate of this bug. ***
[Bug c++/120411] New: ICE compiling module relating to typedef struct {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120411
Bug ID: 120411
Summary: ICE compiling module relating to typedef struct {}
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cjangus at gmail dot com
Target Milestone: ---
Created attachment 61496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61496&action=edit
Compressed preprocessed source
Sorry I don't have the time to reduce this further, but I can tell you that the
trigger appears to be the use of the form "typedef union {} name;" (or struct),
see for example line 159368 of the preprocessed file. Switching to "typedef
union name {} name;", or "union name {};" avoids the ICE.
g++ -fPIC -Og -g -Wall -std=c++2b -fmodules -finput-charset=UTF-8 -c -x c++
-fpreprocessed -fdirectives-only function2.gcm.ii
Output:
/home/cjangus/bug-repros/gcc/add-indirects/add-indirects/function2.mxx:6:8:
internal compiler error: in add_indirects, at cp/module.cc:7833
6 | export module function2;
Target: x86_64-pc-linux-gnu
Configured with: ../repo/configure --prefix=/home/cjangus/gcc
--enable-languages=c,c++ --disable-multilib
gcc version 16.0.0 20250522 (experimental) (GCC)
