[Bug target/118384] unexpected call to __muldi3 generated for riscv target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118384
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |target
Target||riscv32
Last reconfirmed||2025-01-09
Keywords||missed-optimization
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Must be some cost model issue:
```
unsigned long long f(unsigned long long a, unsigned long long b)
{
unsigned long long c = -((a & 1) != 0);
asm("":"+r"(c));
return b & c;
}
unsigned long long f1(unsigned long long a, unsigned long long b)
{
unsigned long long c = ((a & 1) != 0);
return b * c;
}
```
Easy workaround:
Product += (a & 1) ? b : 0;
[Bug target/118384] unexpected call to __muldi3 generated for riscv target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118384
--- Comment #3 from Andrew Pinski ---
(In reply to Huaqi from comment #1)
> This issue also present in arm-eabi-gcc toolchain 14.x, but not present in
> 13.x.
>
> compiler option chosen is -Os -mcpu=cortex-m0
>
> chose m0 due it don't have a multiply hw unit
>
> see https://godbolt.org/z/941TbMKGc
>
> 14.x will generate bl __aeabi_lmul, but 13.x will not.
bool speed = optimize_insn_for_speed_p ();
int cost = add_cost (speed, mode) + neg_cost (speed, mode);
struct algorithm algorithm;
enum mult_variant variant;
if (CONST_INT_P (op1)
? !choose_mult_variant (mode, INTVAL (op1),
&algorithm, &variant, cost)
: cost < mul_cost (speed, mode))
{
temp = bit0_p ? expand_and (mode, negate_rtx (mode, op0),
op1, target)
This is supposed to chose between `X*Y as X&-Y` but in both arm and riscv32
where there is a libcall is chosing the libcall for -Os.
[Bug target/118362] [15 Regression] ICE in require, at machmode.h:313 since r15-2002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118362 --- Comment #6 from Jakub Jelinek --- You can always grep E_V[0-9]*[A-Z]*mode, insn-modes.h in the builddir, those are all the vector modes actually used. Or grep MODE_VECTOR insn-modes.cc
[Bug c++/118385] A temporary expression bound to a reference member in a mem-initializer is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118385 --- Comment #1 from Andrew Pinski --- GCC 4.7 started to warn about this: : In constructor 'A::A()': :2:13: warning: a temporary bound to 'A::v' only persists until the constructor exits [-Wextra]
[Bug target/118384] unexpected call to __muldi3 generated for riscv target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118384 --- Comment #4 from Huaqi --- Thanks Andrew, it is clear to me now. Do you know how it can be avoided? Since I may want to implement my own `__muldi3` function instead of generating a libcall.
[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #21 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #2)
> Maybe related, but not the same. PR986 involves creating a temporary and
> binding the reference to it, that should be easier to warn about. Here's a
> similar case to PR986 where a reference member is dangling after the
> constructor, which we fail to warn about:
>
> struct Y {
> Y(int local) : ref(local) { }
> int& ref;
> };
That is also filed as PR 63181.
[Bug target/118384] unexpected call to __muldi3 generated for riscv target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118384 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #5 from Kito Cheng --- I thought either -fbuilding-libgcc or -fno-builtin can suppress that, but I realized it's just cause by GCC introduce a new MULT during optimization after reading dump...so another work around by command line option is adding `-fno-ssa-phiopt` for this file.
[Bug c++/63181] GCC should warn about "obvious" bugs in binding a reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63181
--- Comment #6 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Eric Gallager from comment #4)
> > This one should be moved to its own separate option per bug 7651
>
> Indeed it should, and if we add -Wdangling-field then that would be the
> ideal option to move it to.
Since GCC 12:
: In constructor 'Foo::Foo(int)':
:2:16: warning: storing the address of local variable 'x' in
'*this.Foo::x_' [-Wdangling-pointer=]
2 |Foo(int x): x_(x) { }
|^
:2:12: note: 'x' declared here
2 |Foo(int x): x_(x) { }
|^
:2:12: note: '' declared here
[Bug c++/63181] GCC should warn about "obvious" bugs in binding a reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63181 Andrew Pinski changed: What|Removed |Added CC||raf2 at msux dot cjb.net --- Comment #7 from Andrew Pinski --- *** Bug 31856 has been marked as a duplicate of this bug. ***
[Bug c++/63181] GCC should warn about "obvious" bugs in binding a reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63181 Andrew Pinski changed: What|Removed |Added CC||dkruger at stevens dot edu --- Comment #8 from Andrew Pinski --- *** Bug 31788 has been marked as a duplicate of this bug. ***
[Bug c++/31856] Undetected error using references to parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31856 --- Comment #6 from Andrew Pinski --- Actually a dup of bug 63181. *** This bug has been marked as a duplicate of bug 63181 ***
[Bug c++/31788] no warnings for passing temps by reference into obviously longer lifetime pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31788 --- Comment #2 from Andrew Pinski --- Actually a dup of bug 63181. *** This bug has been marked as a duplicate of bug 63181 ***
[Bug c++/29593] Missing warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29593 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-01-09 Severity|minor |enhancement Status|RESOLVED|NEW Ever confirmed|0 |1 Resolution|DUPLICATE |--- Keywords||diagnostic --- Comment #5 from Andrew Pinski --- This is not a dup and still does not warn ...
[Bug c++/118385] A temporary expression bound to a reference member in a mem-initializer is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118385 Andrew Pinski changed: What|Removed |Added Blocks||94404 Alias||cwg1696 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-01-09 --- Comment #2 from Andrew Pinski --- This is DR 1696 which GCC does not implement yet. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 118385, which changed state. Bug 118385 Summary: A temporary expression bound to a reference member in a mem-initializer is ill-formed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118385 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/118385] A temporary expression bound to a reference member in a mem-initializer is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118385 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 94904 ***
[Bug c++/94904] [DR 1696] Temporary lifetime and non-static data member initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94904
Andrew Pinski changed:
What|Removed |Added
Alias||cwg1696
Blocks||94404
--- Comment #2 from Andrew Pinski ---
Note:
```
struct A {
A() : v(42) { } // error
const int& v;
};
```
started to warn with r0-113306-g2c6f792709071c aka PR 986 so that might be easy
to fix with s/warning/error .
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues
[Bug c++/94904] [DR 1696] Temporary lifetime and non-static data member initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94904 Andrew Pinski changed: What|Removed |Added CC||rush102333 at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 118385 has been marked as a duplicate of this bug. ***
[Bug c++/986] g++ misses warning for reference on temporary that invokes undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=986 --- Comment #34 from Andrew Pinski --- Note C++ DR 1696 changed the code in comment #0 to be invalid; that is filed as PR 94904.
[Bug rtl-optimization/118266] [15 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2591 by r15-5863-g5ab3f091b3eb42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118266
--- Comment #20 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:14879ba89a4f9d2263472dca1423b584c1236586
commit r15-6728-g14879ba89a4f9d2263472dca1423b584c1236586
Author: H.J. Lu
Date: Wed Jan 8 20:50:04 2025 +0800
ree: Skip extension on fixed register
Skip extension on fixed register since we can't turn
(insn 27 26 139 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "x.ii":14:17 discrim 1 283 {*addsi_1}
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
...
(insn 43 125 74 2 (set (reg/f:DI 6 bp [145])
(zero_extend:DI (reg/f:SI 7 sp))) "x.ii":15:9 175
{*zero_extendsidi2}
(nil))
into
(insn 27 26 155 2 (parallel [
(set (reg:DI 6 bp)
(zero_extend:DI (plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10]
(clobber (reg:CC 17 flags))
]) "x.ii":14:17 discrim 1 296 {addsi_1_zext}
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn 155 27 139 2 (set (reg:DI 7 sp)
(reg:DI 6 bp)) "x.ii":14:17 discrim 1 -1
(nil))
without updating stack frame info.
gcc/
PR rtl-optimization/118266
* ree.cc (add_removable_extension): Skip extension on fixed
register.
gcc/testsuite/
PR rtl-optimization/118266
* gcc.target/i386/pr118266.c: New test.
Signed-off-by: H.J. Lu
[Bug target/115777] [12/13/14/15 regression] Severe performance regression on insertion sort at -O2 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115777 --- Comment #10 from Hongtao Liu --- > That's probably the conservative answer for BB vectorization, for loop vect > we know all those uses will be also in vector code. For BB vectorization > there is currently no easly reliable check to ensure this. Oh, I see.
[Bug c++/118392] "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118392 Simon Martin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot gnu.org --- Comment #4 from Simon Martin --- Working on it through bug #118163
[Bug c++/117792] [12/13/14/15 Regression] ICE in tsubst_template_args with function template-id and local static arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117792 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4dbfc2ff0a84edf6addeaa425272a5beacbbc7db commit r14-11175-g4dbfc2ff0a84edf6addeaa425272a5beacbbc7db Author: Patrick Palka Date: Thu Jan 9 10:49:45 2025 -0500 c++: template-id dependence wrt local static arg [PR117792] Here we end up ICEing at instantiation time for the call to f ultimately because we wrongly consider the call to be non-dependent, and so we specialize f ahead of time and then get confused when fully substituting this specialization. The call is dependent due to [temp.dep.temp]/3 and we miss that because function template-id arguments aren't coerced until overload resolution, and so the local static template argument lacks an implicit cast to reference type that value_dependent_expression_p looks for before considering dependence of the address. Other kinds of template-ids aren't affected since they're coerced ahead of time. So when considering dependence of a function template-id, we need to conservatively consider dependence of the address of each argument (if applicable). PR c++/117792 gcc/cp/ChangeLog: * pt.cc (type_dependent_expression_p): Consider the dependence of the address of each template argument of a function template-id. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/nontype7.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 40f0f6ab75a391906bed40cbdc098b0df3a91af7)
[Bug c++/117925] [14/15 Regression] ice unexpected expression '(FnPtr)(fnPtr)' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117925 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:70cea067dd2b101edc6b3710678529eb8ba2eec2 commit r14-11177-g70cea067dd2b101edc6b3710678529eb8ba2eec2 Author: Patrick Palka Date: Thu Jan 9 10:50:12 2025 -0500 c++: constexpr potentiality of CAST_EXPR [PR117925] We're incorrectly treating the templated callee (FnPtr)fnPtr, represented as CAST_EXPR with TREE_LIST operand, as potentially constant here due to neglecting to look through the TREE_LIST in the CAST_EXPR case of p_c_e_1. PR c++/117925 gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1) : Fix check for class conversion to literal type to properly look through the TREE_LIST operand of a CAST_EXPR. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent35.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 76d1061237b5cd57a274cd8bc8fe02a6f407baa9)
[Bug c++/118060] [13/14/15 Regression] ICE (internal compiler error) on requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118060 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f73ecaf1957d35a9990735ebe228c8dd6188 commit r14-11178-gf73ecaf1957d35a9990735ebe228c8dd6188 Author: Patrick Palka Date: Thu Jan 9 10:50:19 2025 -0500 c++: ICE during requires-expr partial subst [PR118060] Here during partial substitution of the requires-expression (as part of CTAD constraint rewriting) we segfault from the INDIRECT_REF case of convert_to_void due *f(u) being type-dependent. We should just defer checking convert_to_void until satisfaction. PR c++/118060 gcc/cp/ChangeLog: * constraint.cc (tsubst_valid_expression_requirement): Don't check convert_to_void during partial substitution. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires40.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit ca79349c050c27ff466735ba78d2e2bbce56ffdc)
[Bug c++/85944] Address of temporary at global scope not considered constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944 --- Comment #15 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 commit r14-11182-g845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation. (cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)
[Bug libstdc++/109976] error: is not a constant expression in std::equal() with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109976 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 commit r14-11182-g845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation. (cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e696cac2baa35f011f85878e76039fc3945d241 commit r14-11181-g1e696cac2baa35f011f85878e76039fc3945d241 Author: Jonathan Wakely Date: Mon Dec 9 17:35:24 2024 + libstdc++: Skip redundant assertions in std::array equality [PR106212] As PR c++/106212 shows, the Debug Mode checks cause a compilation error for equality comparisons involving std::array prvalues in constant expressions. Those Debug Mode checks are redundant when comparing two std::array objects, because we already know we have a valid range. We can also avoid the unnecessary step of using std::__niter_base to do __normal_iterator unwrapping, which isn't needed because our std::array iterators are just pointers. Using std::__equal_aux1 instead of std::equal avoids the redundant checks in std::equal and std::__equal_aux. libstdc++-v3/ChangeLog: PR libstdc++/106212 * include/std/array (operator==): Use std::__equal_aux1 instead of std::equal. * testsuite/23_containers/array/comparison_operators/106212.cc: New test. (cherry picked from commit 3aeb2edee2f9fc39ab77c7e020f09d7204b167ac)
[Bug c++/117925] [14/15 Regression] ice unexpected expression '(FnPtr)(fnPtr)' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117925 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:aa1e19d821a39d973c4c8c0e8d1d19811d2fa433 commit r14-11176-gaa1e19d821a39d973c4c8c0e8d1d19811d2fa433 Author: Patrick Palka Date: Thu Jan 9 10:50:08 2025 -0500 c++: relax ICE for unexpected trees during constexpr [PR117925] When we encounter an unexpected (likely templated) tree code during constexpr evaluation we currently ICE even in release mode. But it seems more user-friendly to just gracefully treat the expression as non-constant, which will be harmless most of the time (e.g. in the case of warning-specific or speculative constexpr folding as in the PR), and at worst will transform an ICE-on-valid bug into a rejects-valid bug. This is also what e.g. tsubst_expr does when it encounters an unexpected tree code. PR c++/117925 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression) : Relax ICE when encountering an unexpected tree code into a checking ICE guarded by flag_checking. Reviewed-by: Jason Merrill (cherry picked from commit eeedc54cc81c4dfb472ecbd6f14cfbf2dd035474)
[Bug libstdc++/112349] ranges::min/max make unnecessary copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f236c897af48c3ae52095a894d57e66065b8ad87 commit r14-11174-gf236c897af48c3ae52095a894d57e66065b8ad87 Author: Patrick Palka Date: Fri Dec 13 13:17:29 2024 -0500 libstdc++: Avoid unnecessary copies in ranges::min/max [PR112349] Use a local reference for the (now possibly lifetime extended) result of *__first so that we copy it only when necessary. PR libstdc++/112349 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__min_fn::operator()): Turn local object __tmp into a reference. * include/bits/ranges_util.h (__max_fn::operator()): Likewise. * testsuite/25_algorithms/max/constrained.cc (test04): New test. * testsuite/25_algorithms/min/constrained.cc (test04): New test. Reviewed-by: Jonathan Wakely (cherry picked from commit b8314ebff2495ee22f9e2203093bdada9843a0f5)
[Bug libstdc++/112641] : `drop_view::begin const` has O(n) complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9d650c29562bbb18c1ea5d0064e07f48c177912b commit r14-11172-g9d650c29562bbb18c1ea5d0064e07f48c177912b Author: Patrick Palka Date: Tue Oct 29 09:26:19 2024 -0400 libstdc++: Fix complexity of drop_view::begin() const [PR112641] Views are required to have a amortized O(1) begin(), but our drop_view's const begin overload is O(n) for non-common ranges with a non-sized sentinel. This patch reimplements it so that it's O(1) always. See also LWG 4009. PR libstdc++/112641 libstdc++-v3/ChangeLog: * include/std/ranges (drop_view::begin): Reimplement const overload so that it's O(1) always. * testsuite/std/ranges/adaptors/drop.cc (test10): New test. Reviewed-by: Jonathan Wakely (cherry picked from commit 7f622ee83fbbcf4a4ca70e020db8a0ce4b556b61)
[Bug libstdc++/118035] [12/13/14/15 Regression] deque bug when inserting an empty iterator interval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:67c457de5a3f74151fc2d0085387127bf9e4e3c5 commit r14-11179-g67c457de5a3f74151fc2d0085387127bf9e4e3c5 Author: Jonathan Wakely Date: Mon Dec 16 17:42:24 2024 + libstdc++: Fix std::deque::insert(pos, first, last) undefined behaviour [PR118035] Inserting an empty range into a std::deque results in undefined calls to either std::copy, std::copy_backward, std::move, or std::move_backward. We call those algos with invalid arguments where the output range is the same as the input range, e.g. std::copy(first, last, first) which violates the preconditions for the algorithms. This fix simply returns early if there's nothing to insert. Most callers already ensure that we don't even call _M_range_insert_aux with an empty range, but some callers don't. Rather than checking for n == 0 in each of the callers, this just does the check once and uses __builtin_expect to treat empty insertions as unlikely. libstdc++-v3/ChangeLog: PR libstdc++/118035 * include/bits/deque.tcc (_M_range_insert_aux): Return immediately if inserting an empty range. * testsuite/23_containers/deque/modifiers/insert/118035.cc: New test. (cherry picked from commit b273e25e11c842a5729d0e03c85088cf5ba8e06c)
[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117966 --- Comment #12 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:83fa0822aeec8af2162825976209efb90ca40c87 commit r14-11180-g83fa0822aeec8af2162825976209efb90ca40c87 Author: Jonathan Wakely Date: Mon Dec 9 17:35:24 2024 + libstdc++: Skip redundant assertions in std::span construction [PR117966] As PR c++/117966 shows, the Debug Mode checks cause a compilation error for a global constexpr std::span. Those debug checks are redundant when constructing from an array or a range, because we already know we have a valid range and we know its size. Instead of delegating to the std::span(contiguous_iterator, contiguous_iterator) constructor, just initialize the data members directly. libstdc++-v3/ChangeLog: PR libstdc++/117966 * include/std/span (span(T (&)[N])): Do not delegate to constructor that performs redundant checks. (span(array&), span(const array&)): Likewise. (span(Range&&), span(const span&)): Likewise. * testsuite/23_containers/span/117966.cc: New test. (cherry picked from commit e95bda027e0b81922c1bf44770674190bdf787e8)
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 commit r14-11182-g845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation. (cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)
[Bug libstdc++/117962] Debug Mode containers with stateful allocators don't work in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117962 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3590d9f68207861b8973f2812adf02fdba0840ba commit r14-11183-g3590d9f68207861b8973f2812adf02fdba0840ba Author: Jonathan Wakely Date: Mon Dec 9 10:52:10 2024 + libstdc++: Fix debug containers for constant evaluation [PR117962] Using a stateful allocator with std::vector would fail in Debug Mode, because the allocator-extended move constructor tries to swap all the attached safe iterators, but that uses a non-inline function which isn't constexpr. We don't actually need to swap any iterators in constant expressions, because we never attach them to the container in the first place. This bug went unnoticed because the tests for constexpr std::vector were using a stateful allocator with a std::allocator base class, but were failing to override the inherited is_always_equal trait from std::allocator. That meant that the allocators took the always-equal code paths, and didn't try to use the buggy constructor. In C++26 the std::allocator::is_always_equal trait goes away, and so the tests changed behaviour, revealing the bug. libstdc++-v3/ChangeLog: PR libstdc++/117962 * include/debug/safe_container.h: Make allocator-extended move constructor a no-op during constant evaluation. (cherry picked from commit 6fbe9e65645f54cc564a928bc0bc69c8b421cb98)
[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:72fe42c9a095ef9b4125bd65999cd1012dfb73b7 commit r14-11190-g72fe42c9a095ef9b4125bd65999cd1012dfb73b7 Author: Jonathan Wakely Date: Thu Apr 11 19:12:48 2024 +0100 libstdc++: Give std::memory_order a fixed underlying type [PR89624] Prior to C++20 this enum type doesn't have a fixed underlying type, which means it can be modified by -fshort-enums, which then means the HLE bits are outside the range of valid values for the type. As it has a fixed type of int in C++20 and later, do the same for earlier standards too. This is technically a change for C++17 down, because the implicit underlying type (without -fshort-enums) was unsigned before. I doubt it matters in practice. That incompatibility already exists between C++17 and C++20 and nobody has noticed or complained. Now at least the underlying type will be int for all -std modes. libstdc++-v3/ChangeLog: PR libstdc++/89624 * include/bits/atomic_base.h (memory_order): Use int as underlying type. * testsuite/29_atomics/atomic/89624.cc: New test. (cherry picked from commit 99dd1be14172445795f0012b935359e7014a2215)
[Bug libstdc++/108236] std::exclusive_scan with execution policy does not work in-place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108236 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f0eb0ba218968715506c435ca4ff71043e86617c commit r14-11184-gf0eb0ba218968715506c435ca4ff71043e86617c Author: Jonathan Wakely Date: Tue Dec 3 16:36:05 2024 + libstdc++: Fix parallel std::exclusive_scan [PR108236] The standard says that std::exclusive_scan can be used to work in place, i.e. where the output range is the same as the input range. This means that the first sum cannot be written to the output until after reading the first input value, otherwise we'll already have overwritten the first input value. While writing a new testcase I also realised that the serial version of std::exclusive_scan uses copy construction for the accumulator variable, but the standard only requires Cpp17MoveConstructible. We also require move assignable, which is missing from the standard's requirements, but we should at least use move construction not copy construction. A similar problem exists for some other new C++17 numeric algos, but I'll fix the others in a subsequent commit. libstdc++-v3/ChangeLog: PR libstdc++/108236 * include/pstl/glue_numeric_impl.h (exclusive_scan): Pass __init as rvalue. * include/pstl/numeric_impl.h (__brick_transform_scan): Do not write through __result until after reading through __first. Move __init into return value. (__pattern_transform_scan): Pass __init as rvalue. * include/std/numeric (exclusive_scan): Move construct instead of copy constructing. * testsuite/26_numerics/exclusive_scan/2.cc: New test. * testsuite/26_numerics/pstl/numeric_ops/108236.cc: New test. (cherry picked from commit cd107a6343c96c4ef26096e250d43a4a4211eced)
[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 commit r14-11182-g845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation. (cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)
[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117966 --- Comment #13 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 commit r14-11182-g845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation. (cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)
[Bug c++/118392] "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118392 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-01-10 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 Xi Ruoyao changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=32539 --- Comment #9 from Xi Ruoyao --- The use of access attribute seems problematic: it requires the pointer to point to an valid object, but that's not always true for mlock. It's likely we'll just revert the Glibc commit adding the access attribute. Maybe we'll need another attribute to mark a void * as a plain address which might be not a pointer to an real-exist object.
[Bug tree-optimization/118344] [15 regression] Crash at -O3 in ifcombine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118344 Alexandre Oliva changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-January ||/673163.html Keywords||patch Priority|P1 |P3
[Bug tree-optimization/118206] [15 regression] libdeflate miscompiled by ifcombine since r15-6360-g6d5df5133c5dd8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118206 Alexandre Oliva changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-January ||/673161.html Keywords||patch --- Comment #15 from Alexandre Oliva --- Thanks for the testcase and for the analysis! You're right about the predicate too, it makes no sense. I'd patched out the xor one last night because it was not even supposed to be there to begin with, but the other occurrences in other tests seem to have been a cut&pasto I've been carrying unthinkingly since the tentative and abandoned use of match.pd to recognize the gimple patterns for fold_truth_andor_for_ifcombine. Will fix.
[Bug tree-optimization/106883] SLSR may generate signed wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106883 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #3 from Andi Kleen --- Could ranger be used to see if the signed value could overflow? Maybe that would avoid some of the bad effects.
[Bug tree-optimization/118353] Implement greedy algorithm for switch jump table cluster finding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118353 --- Comment #5 from Mark Wielaard --- One difference might be how many cores are used for the builds. The more cores how more sensitive they are for parallelism bottlenecks. And riscv (was) kind of special in that there were just a handful of files that could take a couple of hours to build. With the last patch there seems to be none that takes more than 30 minutes. The full bootstrap builders that sourceware has are here: https://builder.sourceware.org/buildbot/#/builders?tags=gcc-full amd64 make -j12 arm64 make -j16 riscv make -j64 sparc make -j64 Those do a bootstrap plus check in a couple of hours. Only the riscv one shows a big difference (8-9 hours to 3-4 hours). But it seems most of them had slightly longer build times end of November/December than in January. It isn't super clear though, the individual build timess differ a lot (partly because of the use of ccache, which can speed up stage 1 a lot).
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #435 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #434) > Any suggestion on how to proceed here? Oleg, do you maybe want to rebase > your tree against master? I can re-run all tests and verify whether the > patches 59432 and 59550 are still necessary. I expect to be able to get back to this here in about 1~2 months or so.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #436 from Oleg Endo --- Could be relevant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017 https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673130.html
[Bug c++/118392] New: "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118392
Bug ID: 118392
Summary: "-w" fails to fully inhibit "'void a::b()' has not
been declared within a" warning
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: connor24nolan at live dot com
Target Milestone: ---
### Expected Behavior
"-w" should hide all warning messages.
### Actual Behavior
"-w" only partially hides the "'void a::b()' has not been declared within a"
message.
Without the flag, it prints:
> :6:6: warning: 'void xxx::bar()' has not been declared within xxx
> void xxx::bar() {}
> ^~~
> :3:20: note: only here as a friend
> friend void bar();
> ^~~
However, with the flag it only prints:
> :3:20: note: only here as a friend
> friend void bar();
> ^~~
This is extremely confusing to see, especially when building third-party code
(one use of the "-w" flag).
### Steps To Reproduce
An example is available at https://godbolt.org/z/Yv699n49v. The bug reproduces
on almost every GCC version I tested. The only exceptions were old versions
that failed to compile the example at all.
[Bug c++/118392] "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118392
--- Comment #1 from Andrew Pinski ---
There is auto_diagnostic_group but it looks like it is not working.
if (hidden_p)
{
auto_diagnostic_group d;
pedwarn (DECL_SOURCE_LOCATION (decl), 0,
"%qD has not been declared within %qD", decl, scope);
inform (DECL_SOURCE_LOCATION (found),
"only here as a %");
}
[Bug c++/118392] "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118392 --- Comment #2 from Andrew Pinski --- Created attachment 60087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60087&action=edit testcase Next time please attach or paste inline the testcase. Note attaching has a way to paste into a field instead of needing to attach via a file.
[Bug tree-optimization/117997] [15 regression] libgo regressions on aarch64 after g:4d2b9202fe94c54e63fb07d48293a78da3d82532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- Possibly dup (again on aarch64) that I haven't had a chance to reduce yet: https://bugzilla.redhat.com/show_bug.cgi?id=2336715 in "flac" testsuite: testing FLAC__crc16 ... FAILED, FLAC__crc16 result did not match reference CRC for 1 bytes of test data
[Bug target/118017] [15 Regression] ICE: maximum number of generated reload insns per insn achieved (90) with -Og -frounding-math -mno-80387 -mno-mmx since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017 --- Comment #9 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:fab96de044f1f023f52d43af866205d17d8895fb commit r15-6751-gfab96de044f1f023f52d43af866205d17d8895fb Author: Vladimir N. Makarov Date: Thu Jan 9 16:22:02 2025 -0500 [PR118017][LRA]: Don't inherit reg of non-uniform reg class In the PR case LRA inherited value of register of class INT_SSE_REGS which resulted in LRA cycling when LRA tried to use different move alternatives with SSE/general regs and memory. The patch rejects to inherit such (non-uniform) classes to prevent cycling. gcc/ChangeLog: PR target/118017 * lra-constraints.cc (inherit_reload_reg): Check reg class on uniformity. gcc/testsuite/ChangeLog: PR target/118017 * gcc.target/i386/pr118017.c: New.
[Bug target/118363] [15 regression] RISC-V: excess errors in c-c++-common/gomp/dispatch-11.c with zvls > 128b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118363 Edwin Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Edwin Lu --- (In reply to Sam James from comment #1) > See > https://inbox.sourceware.org/gcc-regression/202501082000. > 508k0hgq3159...@shliclel4214.sh.intel.com/T/#u. > > Probably fixed by r15-6721-g1bb367b5cdb9fa77733d87d97483fb57480ef6fe? Confirmed to be fixed now so likely was fixed by that commit. https://github.com/patrick-rivos/gcc-postcommit-ci/issues/2408
[Bug bootstrap/118369] Multilib bootstrap on Debian 12 fails due to missing asm/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118369 --- Comment #12 from Ilya Leoshkevich --- Sorry, I didn't manage to catch you on IRC today, so continuing here. Is this conflict considered an issue that will be eventually resolved, or is it to stay? I wonder how to proceed; I guess on a shared machine different users will want cross-compilers or multilib, so unless there is a way to do something about this package conflict, maybe there can be a workaround for GCC? Looking at the flags I found, while --build=x86_64-linux-gnu is merely a nuisance, having to also specify --prefix=/usr is a bit too much, since it would make it impossible to have private installations (unless make install DESTDIR=... would magically work).
[Bug bootstrap/118369] Multilib bootstrap on Debian 12 fails due to missing asm/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118369 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #13 from Xi Ruoyao --- > - Is it okay that the argument-less ./configure does not work? ./configure is unsupported at all. Quote from https://gcc.gnu.org/install/configure.html: First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where objdir is a subdirectory of srcdir should work as well; building where objdir == srcdir is unsupported.
[Bug target/118362] [15 Regression] ICE in require, at machmode.h:313 since r15-2002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118362 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8e4120500e0cfc71956dc6569fe4ff00d2c20949 commit r15-6748-g8e4120500e0cfc71956dc6569fe4ff00d2c20949 Author: Jakub Jelinek Date: Thu Jan 9 22:04:58 2025 +0100 s390: Add testcase for just fixed PR118362 On Thu, Jan 09, 2025 at 01:29:27PM +0100, Stefan Schulze Frielinghaus wrote: > Optimization s390_constant_via_vgbm_p() should only apply to constant > vectors which can be expressed by the hardware, i.e., which have a size > of at most 16-bytes, similar as it is done for s390_constant_via_vgm_p() > and s390_constant_via_vrepi_p(). > > gcc/ChangeLog: > > PR target/118362 > * config/s390/s390.cc (s390_constant_via_vgbm_p): Allow at most > 16-byte vectors. > --- > Bootstrap and regtest are still running. If both are successful, I > will push this one promptly. This was committed without a testcase, which IMHO shouldn't hurt. 2025-01-09 Jakub Jelinek PR target/118362 * gcc.c-torture/compile/pr118362.c: New test. * gcc.target/s390/pr118362.c: New test.
[Bug c/118375] Fixits for feature test macros (FTMs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118375 --- Comment #3 from Sam James --- Ugh, sorry, pasted wrong thing. It should of course be: ``` a.c: In function ‘main’: a.c:5:15: error: ‘program_invocation_name’ undeclared (first use in this function) 5 | char* x = program_invocation_name; | ^~~ a.c:5:15: note: each undeclared identifier is reported only once for each function it appears in ``` where we should suggest _GNU_SOURCE must be defined (before any includes) to make the extension available.
[Bug target/118320] [14/15 Regression] internal compiler error: Segmentation fault in aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118320 --- Comment #12 from Andrew Pinski --- I am trying to figure out if we should reject the STP or allow it. The reason why it fails in ldp_fusion1 (which is before RA) is because of this: ``` // Punt on accesses relative to eliminable regs. See the comment in // pair_fusion_bb_info::track_access for a detailed explanation of this. if (!reload_completed && (REGNO (base) == FRAME_POINTER_REGNUM || REGNO (base) == ARG_POINTER_REGNUM)) continue; ``` This is why it works if you make b a pointer or a global variable is because ldp_fusion1 will handle the situtation just fine and the 2 uses don't need to be merged there as the psedu registers are different so the uses list still includes 2 uses.
[Bug tree-optimization/117997] [15 regression] libgo regressions on aarch64 after g:4d2b9202fe94c54e63fb07d48293a78da3d82532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997 --- Comment #4 from Sam James --- (In reply to David Malcolm from comment #3) Does it pass with -fno-optimize-crc?
[Bug libstdc++/117962] Debug Mode containers with stateful allocators don't work in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117962 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.3 --- Comment #5 from Jonathan Wakely --- Fixed for 14.3
[Bug libstdc++/118035] [12/13 Regression] deque bug when inserting an empty iterator interval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035 Jonathan Wakely changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13 Regression] |deque bug when |deque bug when |inserting an empty iterator |inserting an empty iterator |interval|interval --- Comment #8 from Jonathan Wakely --- Fixed for 15.1 and 14.3 so far
[Bug c/117866] [15 regression] Confusing 'expected ... but argument is of type ...' (same type repeated) w/ C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866 --- Comment #8 from Sam James --- Thank you!
[Bug c++/118391] New: ICE: in add_extra_args, at cp/pt.cc:13737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118391
Bug ID: 118391
Summary: ICE: in add_extra_args, at cp/pt.cc:13737
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eczbek.void at gmail dot com
Target Milestone: ---
https://godbolt.org/z/TovxM83E6
This seems to work with GCC 14.2
```
template
using A = int;
template
using B = decltype([] {}.template operator()());
template
using C = A>;
C x;
int main() {}
```
: In substitution of 'template using C = A.operator()())> [with T = int]':
:10:6: required from here
10 | C x;
| ^
:5:20: internal compiler error: in add_extra_args, at cp/pt.cc:13737
5 | using B = decltype([] {}.template operator()());
|^~~
0x28fe3b5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29151b6 internal_error(char const*, ...)
???:0
0xacb842 fancy_abort(char const*, int, char const*)
???:0
0xd17f0d tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xd26557 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd31fa4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xd2616a tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd3a533 instantiate_template(tree_node*, tree_node*, int)
???:0
0xd23fca lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
???:0
0xd6525c finish_template_type(tree_node*, tree_node*, int)
???:0
0xce5eba c_parse_file()
???:0
0xe45879 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/118188] aarch64: worse code with -mtune=grace (vs -mtune=generic) in TSVC s4115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118188
--- Comment #4 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:08b6e875c6b1b52c6e98f4a2e37124bf8c6a6ccb
commit r15-6752-g08b6e875c6b1b52c6e98f4a2e37124bf8c6a6ccb
Author: Tamar Christina
Date: Thu Jan 9 21:31:05 2025 +
AArch64: Fix costing of emulated gathers/scatters [PR118188]
When a target does not support gathers and scatters the vectorizer tries to
emulate these using scalar loads/stores and a reconstruction of vectors
from
scalar.
The loads are still marked with VMAT_GATHER_SCATTER to indicate that they
are
gather/scatters, however the vectorizer also asks the target to cost the
instruction that generates the indexes for the emulated instructions.
This is done by asking the target to cost vec_to_scalar and vec_construct
with
a stmt_vinfo being the VMAT_GATHER_SCATTER.
Since Adv. SIMD does not have an LD1 variant that takes an Adv. SIMD Scalar
element the operation is lowered entirely into a sequence of GPR loads to
create
the x registers for the indexes.
At the moment however we don't cost these, and so the vectorizer things
that
when it emulates the instructions that it's much cheaper than using an
actual
gather/scatter with SVE. Consider:
#define iterations 10
#define LEN_1D 32000
float a[LEN_1D], b[LEN_1D];
float
s4115 (int *ip)
{
float sum = 0.;
for (int i = 0; i < LEN_1D; i++)
{
sum += a[i] * b[ip[i]];
}
return sum;
}
which before this patch with -mcpu= generates:
.L2:
add x3, x0, x1
ldrsw x4, [x0, x1]
ldrsw x6, [x3, 4]
ldpsw x3, x5, [x3, 8]
ldr s1, [x2, x4, lsl 2]
ldr s30, [x2, x6, lsl 2]
ldr s31, [x2, x5, lsl 2]
ldr s29, [x2, x3, lsl 2]
uzp1v30.2s, v30.2s, v31.2s
ldr q31, [x7, x1]
add x1, x1, 16
uzp1v1.2s, v1.2s, v29.2s
zip1v30.4s, v1.4s, v30.4s
fmlav0.4s, v31.4s, v30.4s
cmp x1, x8
bne .L2
but during costing:
a[i_18] 1 times vector_load costs 4 in body
*_4 1 times unaligned_load (misalign -1) costs 4 in body
b[_5] 4 times vec_to_scalar costs 32 in body
b[_5] 4 times scalar_load costs 16 in body
b[_5] 1 times vec_construct costs 3 in body
_1 * _6 1 times vector_stmt costs 2 in body
_7 + sum_16 1 times scalar_to_vec costs 4 in prologue
_7 + sum_16 1 times vector_stmt costs 2 in epilogue
_7 + sum_16 1 times vec_to_scalar costs 4 in epilogue
_7 + sum_16 1 times vector_stmt costs 2 in body
Here we see that the latency for the vec_to_scalar is very high. We know
the
intermediate vector isn't usable by the target ISA and will always be
elided.
However these latencies need to remain high because when costing
gather/scatters
IFNs we still pass the nunits of the type along. In other words, the
vectorizer
is still costing vector gather/scatters as scalar load/stores.
Lowering the cost for the emulated gathers would result in emulation being
seemingly cheaper. So while the emulated costs are very high, they need to
be
higher than those for the IFN costing.
i.e. the vectorizer generates:
vect__5.9_8 = MEM [(intD.7 *)vectp_ip.7_14];
_35 = BIT_FIELD_REF ;
_36 = (sizetype) _35;
_37 = _36 * 4;
_38 = _34 + _37;
_39 = (voidD.55 *) _38;
# VUSE <.MEM_10(D)>
_40 = MEM[(floatD.32 *)_39];
which after IVopts is:
_63 = &MEM [(int *)ip_11(D) + ivtmp.19_27 * 1];
_47 = BIT_FIELD_REF [(int *)_63], 32, 64>;
_41 = BIT_FIELD_REF [(int *)_63], 32, 32>;
_35 = BIT_FIELD_REF [(int *)_63], 32, 0>;
_53 = BIT_FIELD_REF [(int *)_63], 32, 96>;
Which we correctly lower in RTL to individual loads to avoid the repeated
umov.
As such, we should cost the vec_to_scalar as GPR loads and also do so for
the
throughput which we at the moment cost as:
note: Vector issue estimate:
note:load operations = 6
note:store operations = 0
note:general operations = 6
note:reduction latency = 2
note:estimated min cycles per iteration = 2.00
Which means 3 loads for the GOR indexes are missing, making it seem like
the
emulated loop has a much lower cycles per iter than it actually does since
the
bottleneck on the load units are not modelled.
But worse, because the vectorizer costs gathers/scatters IFNs as scalar
load/stores the number of loads required for an SVE gather is always much
higher than the equivalent emulated variant.
gcc/ChangeLog:
PR target/118188
* config/aarch64/aarch64.cc (aarch64_vector_costs::count_ops):
Ad
[Bug tree-optimization/116773] [meta-bug] TSVC missed optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116773 Bug 116773 depends on bug 118188, which changed state. Bug 118188 Summary: aarch64: worse code with -mtune=grace (vs -mtune=generic) in TSVC s4115 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118188 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/118188] aarch64: worse code with -mtune=grace (vs -mtune=generic) in TSVC s4115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118188 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Tamar Christina --- Fixed thanks for the report, not suitable for backporting.
[Bug c++/118391] ICE: in add_extra_args, at cp/pt.cc:13737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118391 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Just got fixed by r15-6740.
[Bug c++/118391] ICE: in add_extra_args, at cp/pt.cc:13737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118391 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2025-01-09 --- Comment #2 from Marek Polacek --- I think we still want that testcase.
[Bug target/118320] [14/15 Regression] internal compiler error: Segmentation fault in aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118320
--- Comment #11 from Andrew Pinski ---
case Action::CHANGE:
{
set_pair_pat (change);
change->new_uses = merge_access_arrays (attempt,
input_uses[0],
input_uses[1]);
returns invalid.
Because:
(gdb) p *(use_info *)access2
$13 = { = {m_regno = 0, m_mode = E_DImode, m_kind =
rtl_ssa::access_kind::USE, m_is_artificial = 0,
m_is_set_with_nondebug_insn_uses = 0, m_is_pre_post_modify = 0,
m_is_call_clobber = 0, m_is_live_out_use = 0, m_includes_address_uses = 0,
m_includes_read_writes = 0, m_includes_subregs = 0,
m_includes_multiregs = 0, m_only_occurs_in_notes = 0,
m_is_last_nondebug_insn_use = 1, m_is_in_debug_insn_or_phi = 0,
m_has_been_superceded = 0, m_is_temp = 0}, m_insn_or_phi = {m_ptr = 0x4b64db8
"8M\266\004"}, m_last_use_or_prev_use = {m_ptr = 0x4b64e28 ""},
m_last_nondebug_insn_use_or_next_use = {
m_ptr = 0x4b64e28 ""}, m_def = 0x4b64d80}
(gdb) p *(use_info *)access1
$14 = { = {m_regno = 0, m_mode = E_DImode, m_kind =
rtl_ssa::access_kind::USE, m_is_artificial = 0,
m_is_set_with_nondebug_insn_uses = 0, m_is_pre_post_modify = 0,
m_is_call_clobber = 0, m_is_live_out_use = 0, m_includes_address_uses = 0,
m_includes_read_writes = 0, m_includes_subregs = 0,
m_includes_multiregs = 0, m_only_occurs_in_notes = 0,
m_is_last_nondebug_insn_use = 0, m_is_in_debug_insn_or_phi = 0,
m_has_been_superceded = 0, m_is_temp = 0}, m_insn_or_phi = {m_ptr = 0x4b64c58
"\310K\266\004"}, m_last_use_or_prev_use = {m_ptr = 0x0},
m_last_nondebug_insn_use_or_next_use = {m_ptr = 0x0},
m_def = 0x0}
can_merge_accesses returns false for those 2.
These 2 access corresponds to the 2 defining rtl statements from their uses
inside the stores:
(insn 5 2 15 2 (clobber (reg:DI 0 x0 [orig:103 aD.4508 ] [103]))
"/app/example.cpp":3:23 -1
(nil))
...
(insn 18 15 16 2 (set (reg:DI 0 x0 [orig:104 aD.4508+8 ] [104])
(const_int 1 [0x1])) "/app/example.cpp":17:5 70 {*movdi_aarch64}
(expr_list:REG_EQUIV (const_int 1 [0x1])
(nil)))
Though in this case m_def for access1 is null because it was a clobber.
Even though I think we can actually merge the uses here because the access1 use
of x0 can be anything as it was "defined" by the clobber.
I am not sure where the right place to do that.
is merge_access_arrays the correct place or somewhere else?
[Bug c/117866] [15 regression] Confusing 'expected ... but argument is of type ...' (same type repeated) w/ C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117866 --- Comment #7 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:21571cdd8355f2162910d40f2f7d2dd4046f commit r15-6747-g21571cdd8355f2162910d40f2f7d2dd4046f Author: Martin Uecker Date: Mon Jan 6 15:32:16 2025 +0100 c: Restore warning for incomplete structures declared in parameter list [PR117866] In C23 mode the warning about declaring structures and union in parameter lists was removed, because it is possible to redeclare a compatible type elsewhere. This is not the case for incomplete types, so restore the warning for those types. PR c/117866 gcc/c/ChangeLog: * c-decl.cc (get_parm_info): Change condition for warning. gcc/testsuite/ChangeLog: * gcc.dg/pr117866.c: New test. * gcc.dg/strub-pr118007.c: Adapt.
[Bug bootstrap/118369] Multilib bootstrap on Debian 12 fails due to missing asm/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118369 --- Comment #9 from Matthias Klose --- let's take that on irc, maybe quicker. I've never used the approach to get the build deps from the gcc-12 package, maybe try apt source gcc-12 cd gcc-12-12* apt buil-dep . or just apt build-dep gcc-12
[Bug tree-optimization/118186] [15 regression] FAIL: gcc.dg/field-merge-16.c scan-tree-dump-times ifcombine "optimizing" 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118186 --- Comment #2 from Alexandre Oliva --- I've just confirmed that that's the fix indeed.
[Bug c++/117825] [12/13/14/15 Regression] ICE on template with -Wformat-security (error reporting routines re-entered.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117825 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:da82bf0a5fe31319735af1b67218578440ed8333 commit r14-11157-gda82bf0a5fe31319735af1b67218578440ed8333 Author: Jakub Jelinek Date: Wed Jan 8 23:12:02 2025 +0100 c++: Honor complain in cp_build_function_call_vec for check_function_arguments warnings [PR117825] The following testcase ICEs due to re-entering diagnostics. When diagnosing -Wformat-security warning, we try to print instantiation context, which calls tsubst with tf_none, but that in the end calls cp_build_function_call_vec which calls check_function_arguments which diagnoses another warning (again -Wformat-security). The other check_function_arguments caller, build_over_call, doesn't call that function if !(complain & tf_warning), so I think the best fix is to do it the same in cp_build_function_call_vec as well. 2025-01-08 Jakub Jelinek PR c++/117825 * typeck.cc (cp_build_function_call_vec): Don't call check_function_arguments if complain doesn't have tf_warning bit set. * g++.dg/warn/pr117825.C: New test. (cherry picked from commit e5180fbcbcc356c71154413588288cbd30e5198d)
[Bug target/117642] [12/13/14 Regression] __sync_lock_release() on 128bit integer does not behave according to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117642 --- Comment #11 from Jakub Jelinek --- Docs fixed for 14.3 as well.
[Bug middle-end/117847] wrong code with __builtin_stdc_rotate_left() on _BitInt of multiple of 64's (limb size) at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117847 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug c++/116108] [12/13 Regression] GCC crashes on incorrect code with -std=c++20 since r10-4719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116108 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] GCC |[12/13 Regression] GCC |crashes on incorrect code |crashes on incorrect code |with -std=c++20 since |with -std=c++20 since |r10-4719|r10-4719 --- Comment #8 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug libstdc++/118093] std::future::wait_until futex call returns EINVAL for negative timeout smaller than 1s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118093 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a7c5c4931f50b9898409d0101fad47abc9a223c3 commit r14-11160-ga7c5c4931f50b9898409d0101fad47abc9a223c3 Author: Jonathan Wakely Date: Tue Dec 17 21:32:19 2024 + libstdc++: Fix std::future::wait_until for subsecond negative times [PR118093] The current check for negative times (i.e. before the epoch) only checks for a negative number of seconds. For a time 1ms before the epoch the seconds part will be zero, but the futex syscall will still fail with an EINVAL error. Extend the check to handle this case. This change adds a redundant check in the headers too, so that we avoid even calling into the library for negative times. Both checks can be marked [[unlikely]]. The check in the headers avoids the cost of splitting the time into seconds and nanoseconds and then making a PLT call. The check inside the library matches where we were checking already, and fixes existing binaries that were compiled against older headers but use a newer libstdc++.so.6 at runtime. libstdc++-v3/ChangeLog: PR libstdc++/118093 * include/bits/atomic_futex.h (_M_load_and_test_until_impl): Return false for times before the epoch. * src/c++11/futex.cc (_M_futex_wait_until): Extend check for negative times to check for subsecond times. Add unlikely attribute. (_M_futex_wait_until_steady): Likewise. * testsuite/30_threads/future/members/118093.cc: New test. (cherry picked from commit 8ade3c3ea77e166f2873fb7ae57f9690e2b8d0e0)
[Bug middle-end/117458] ICE: in gen_lowpart_general, at rtlhooks.cc:63 when reinterpreting _Complex float as _BitInt(33)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117458 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.3 --- Comment #7 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug rtl-optimization/117095] [13/14 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117095
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:fbbc1a4ac5c7e55de1edc52cfe267b95f9621e21
commit r14-11154-gfbbc1a4ac5c7e55de1edc52cfe267b95f9621e21
Author: Jakub Jelinek
Date: Sat Dec 14 00:41:00 2024 +0100
cse: Fix up record_jump_equiv checks [PR117095]
The following testcase is miscompiled on s390x-linux with -O2 -march=z15.
The problem happens during cse2, which sees in an extended basic block
(jump_insn 217 78 216 10 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 165)
(const_int 1 [0x1]))
(label_ref 216)
(pc)))
(set (reg:SI 165)
(plus:SI (reg:SI 165)
(const_int -1 [0x])))
(clobber (scratch:SI))
(clobber (reg:CC 33 %cc))
]) "t.c":14:17 discrim 1 2192 {doloop_si64}
(int_list:REG_BR_PROB 955630228 (nil))
-> 216)
...
(insn 99 98 100 12 (set (reg:SI 138)
(const_int 1 [0x1])) "t.c":9:31 1507 {*movsi_zarch}
(nil))
(insn 100 99 103 12 (parallel [
(set (reg:SI 137)
(minus:SI (reg:SI 138)
(subreg:SI (reg:HI 135 [ a ]) 0)))
(clobber (reg:CC 33 %cc))
]) "t.c":9:31 1904 {*subsi3}
(expr_list:REG_DEAD (reg:SI 138)
(expr_list:REG_DEAD (reg:HI 135 [ a ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)
Note, cse2 has df_note_add_problem () before df_analyze, which add
(expr_list:REG_UNUSED (reg:SI 165)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
notes to the first insn (correctly so, %cc is clobbered there and pseudo
165 isn't used after the insn).
Now, cse_extended_basic_block has an extra optimization on conditional
jumps, where it records equivalence on the edge which continues in the ebb.
Here it sees (ne reg:SI 165) (const_int 1) is false on the edge and
remembers that pseudo 165 is comparison equivalent to (const_int 1),
so on insn 100 it decides to replace (reg:SI 138) with (reg:SI 165).
This optimization isn't correct here though, because the JUMP_INSN has
multiple sets. Before r0-77890 record_jump_equiv has been called from
cse_insn guarded on n_sets == 1 && any_condjump_p (insn), so it wouldn't
be done on the above JUMP_INSN where n_sets == 2. But since that change
it is guarded with single_set (insn) && any_condjump_p (insn) and that
is true because of the REG_UNUSED note. Looking at that note is
inappropriate in CSE though, because the whole intent of the pass is to
extend the lifetimes of the pseudos if equivalence is found, so the fact
that there is REG_UNUSED note for (reg:SI 165) and that the reg isn't used
later doesn't imply that it won't be used after the optimization.
So, unless we manage to process the other sets on the JUMP_INSN (it
wouldn't
be terribly hard in this exact case, the doloop insn decreases the register
by 1 and so we could just record equivalence to (const_int 0) instead, but
generally it might be hard), we should IMHO just punt if there are multiple
sets.
The patch below adds !multiple_sets (insn) check instead of replacing with
it the single_set (insn) check, because apparently any_condjump_p uses
pc_set which supports the case where PATTERN is a SET to PC (that is a
single_set (insn) && !multiple_sets (insn), PATTERN is a PARALLEL with a
single SET to PC (likewise) and some CLOBBERs, PARALLEL with two or more
SETs where the first one is SET to PC (that could be single_set (insn)
with REG_UNUSED notes but is not !multiple_sets (insn)) or PATTERN
is UNSPEC/UNSPEC_VOLATILE with SET inside of it. For the last case
!multiple_sets (insn) will be true, but IMHO we shouldn't try to derive
anything from those because we haven't checked the rest of the UNSPEC*
and we don't really know what it does.
2024-12-13 Jakub Jelinek
PR rtl-optimization/117095
* cse.cc (cse_extended_basic_block): Don't call record_jump_equiv
if multiple_sets (insn).
* gcc.c-torture/execute/pr117095.c: New test.
(cherry picked from commit b626ebc0d7888ddae16a55ca583b56a4b8434bdf)
[Bug c/117802] ICE: SIGSEGV in fold_convert_loc (fold-const.cc:2626) with __builtin_iseqsig() on _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117802 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 117614, which changed state. Bug 117614 Summary: [14 Regression] Cannot change active member of anonymous union in constant expression since r14-4771-g1d260ab0e39ea6 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117614 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/117317] [12/13 Regression] ICE on call to virtual constexpr function via comparison operator in CRTP with multiple inheritance with template since r12-4202-g09d886e671f223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE on |on call to virtual |call to virtual constexpr |constexpr function via |function via comparison |comparison operator in CRTP |operator in CRTP with |with multiple inheritance |multiple inheritance with |with template since |template since |r12-4202-g09d886e671f223|r12-4202-g09d886e671f223 --- Comment #11 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug ada/18765] illegal program not detected, "/=" when "=" is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18765 --- Comment #7 from GCC Commits --- The master branch has been updated by Marc Poulhi?s : https://gcc.gnu.org/g:3b694271bec01ed971147a0f4cb68d8c9a7d0915 commit r15-6731-g3b694271bec01ed971147a0f4cb68d8c9a7d0915 Author: Eric Botcazou Date: Sun Jan 5 17:34:41 2025 +0100 ada: Fix missing detection of late equality operator returning subtype of Boolean In Ada 2012, the compiler fails to check that a primitive equality operator for an untagged record type must appear before the type is frozen, when the operator returns a subtype of Boolean. This plugs the legality loophole but adds the debug switch -gnatd_q to go back to the previous state. gcc/ada/ChangeLog: PR ada/18765 * debug.adb (d_q): Document new usage. * sem_ch6.adb (New_Overloaded_Entity): Apply the special processing to all equality operators whose base result type is Boolean, but do not enforce the new Ada 2012 freezing rule if the result type is a proper subtype of it and the -gnatd_q switch is specified.
[Bug libstdc++/118093] std::future::wait_until futex call returns EINVAL for negative timeout smaller than 1s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118093 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.4
[Bug c++/117825] [12/13 Regression] ICE on template with -Wformat-security (error reporting routines re-entered.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117825 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[12/13/14/15 Regression]|[12/13 Regression] ICE on |ICE on template with|template with |-Wformat-security (error|-Wformat-security (error |reporting routines |reporting routines |re-entered.)|re-entered.) --- Comment #10 from Jakub Jelinek --- Fixed on the trunk and for GCC 14.3 as well.
[Bug middle-end/117459] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 with __builtin_assoc_barrier() on _BitInt(255)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117459 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.3
[Bug c/117745] [12/13 Regression] GCC hangs with invalid code with sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] GCC |[12/13 Regression] GCC |hangs with invalid code |hangs with invalid code |with sizeof |with sizeof --- Comment #14 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug middle-end/102674] internal compiler error: on fpclassify(_Decimal32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102674 --- Comment #6 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug rtl-optimization/117095] [13 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117095 Jakub Jelinek changed: What|Removed |Added Summary|[13/14 Regression] Wrong|[13 Regression] Wrong code |code since |since |r13-5103-g7c9f20fcfdc2d8|r13-5103-g7c9f20fcfdc2d8 --- Comment #10 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug rtl-optimization/113994] [13 Regression] Probable C++ code generation bug with -O2 on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994 Jakub Jelinek changed: What|Removed |Added Summary|[13/14 Regression] Probable |[13 Regression] Probable |C++ code generation bug |C++ code generation bug |with -O2 on s390x platform |with -O2 on s390x platform --- Comment #16 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug c/117641] ICE: SIGSEGV in contains_struct_check (tree.h:3788) with __sync_fetch_and_add() on _BitInt(128) on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117641 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.3 --- Comment #10 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug tree-optimization/117439] [12/13 Regression] ICE in encode_tree_to_bitpos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117439 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE in |in encode_tree_to_bitpos|encode_tree_to_bitpos --- Comment #12 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug target/118342] `a == 0 ? 32 : __builtin_ctz(a)` for Intel and AMD cores could be implemented even without BMI1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Yes, so we can use it for a == 0 ? prec : __builtin_ctzll (a); but not say
> (with small middle-end enhancements) for a == 0 ? -1 : __builtin_ctzll (a);
> because on some CPUs that would yield -1LL and on others 0xULL.
As I read the footnote from the Comment #4, the problem would be with:
long long foo (int a)
{
return a ? __builtin_ctz (a) : -1ll;
}
We declare:
(define_insn_and_split "ctz2"
[(set (match_operand:SWI48 0 "register_operand" "=r")
(ctz:SWI48
(match_operand:SWI48 1 "nonimmediate_operand" "rm")))
(clobber (reg:CC FLAGS_REG))]
without strict_low_part, so for ctzsi2, there is no guarantee that bits outside
SImode low part register will be preserved.
OTOH, we also declare:
(define_insn_and_split "*ctzsidi2_ext"
[(set (match_operand:DI 0 "register_operand" "=r")
(any_extend:DI
(ctz:SI
(match_operand:SI 1 "nonimmediate_operand" "rm"
(clobber (reg:CC FLAGS_REG))]
"TARGET_64BIT"
{
if (TARGET_BMI)
return "tzcnt{l}\t{%1, %k0|%k0, %1}";
else if (TARGET_CPU_P (GENERIC)
&& !optimize_function_for_size_p (cfun))
/* tzcnt expands to 'rep bsf' and we can use it even if !TARGET_BMI. */
return "rep%; bsf{l}\t{%1, %k0|%k0, %1}";
return "bsf{l}\t{%1, %k0|%k0, %1}";
}
which *may* clear upper 32 bits with input operand == 0. So,
movq$-1, %rax
rep bsfl%edi, %eax
ret
would be risky, because bsfl *may* clobber the highpart of %rax when %edi is 0.
[Bug middle-end/43374] ICE with __builtin_isinf() and _Decimal argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374 --- Comment #14 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug rtl-optimization/116799] [14 Regression] Miscompiled code (vim testsuite fails) on s390x at -O2 since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug c++/117614] [14 Regression] Cannot change active member of anonymous union in constant expression since r14-4771-g1d260ab0e39ea6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117614 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug libgomp/117851] all amdgcn offload tests fail with a host compiler configured with --enable-default-pie (or compiled/linked with PIE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117851 --- Comment #9 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug middle-end/118024] ICE when building openssh-9.9_p1 with -fstrub=all (internal compiler error: tree check: expected tree_list, have identifier_node in matching_alloc_calls_p, at gimple-ssa-warn-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024 --- Comment #8 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug target/65181] Support for alloca in nvptx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65181 --- Comment #13 from GCC Commits --- The trunk branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:3861d362ec7e3c50742fc43833fe9d8674f4070e commit r15-6733-g3861d362ec7e3c50742fc43833fe9d8674f4070e Author: Thomas Schwinge Date: Sat Dec 7 00:17:49 2024 +0100 nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181] ..., and use it for '-mno-soft-stack': PTX "native" stacks. PR target/65181 gcc/ * config/nvptx/nvptx.cc (nvptx_get_drap_rtx): Handle '!TARGET_SOFT_STACK'. * config/nvptx/nvptx.md (define_c_enum "unspec"): Add 'UNSPEC_STACKSAVE', 'UNSPEC_STACKRESTORE'. (define_expand "allocate_stack", define_expand "save_stack_block") (define_expand "save_stack_block"): Handle '!TARGET_SOFT_STACK', PTX 'alloca'. (define_insn "@nvptx_alloca_") (define_insn "@nvptx_stacksave_") (define_insn "@nvptx_stackrestore_"): New. * doc/invoke.texi (Nvidia PTX Options): Update '-msoft-stack', '-mno-soft-stack'. * doc/sourcebuild.texi (nvptx-specific attributes): Document 'nvptx_runtime_alloca_ptx'. (Add Options): Document 'nvptx_alloca_ptx'. gcc/testsuite/ * gcc.target/nvptx/alloca-1.c: Evolve into... * gcc.target/nvptx/alloca-1-O0.c: ... this, ... * gcc.target/nvptx/alloca-1-O1.c: ... this, and... * gcc.target/nvptx/alloca-1-sm_30.c: ... this. * gcc.target/nvptx/vla-1.c: Evolve into... * gcc.target/nvptx/vla-1-O0.c: ... this, ... * gcc.target/nvptx/vla-1-O1.c: ... this, and... * gcc.target/nvptx/vla-1-sm_30.c: ... this. * gcc.c-torture/execute/pr36321.c: Adjust. * gcc.target/nvptx/__builtin_alloca_0-1-O0.c: Likewise. * gcc.target/nvptx/__builtin_alloca_0-1-O1.c: Likewise. * gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1.c: Likewise. * gcc.target/nvptx/softstack.c: Likewise. * gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1-sm_30.c: New. * gcc.target/nvptx/alloca-2-O0.c: Likewise. * gcc.target/nvptx/alloca-3-O1.c: Likewise. * gcc.target/nvptx/alloca-4-O3.c: Likewise. * gcc.target/nvptx/alloca-5.c: Likewise. * lib/target-supports.exp (check_effective_target_alloca): Adjust. (check_nvptx_default_ptx_isa_target_architecture_at_least) (check_nvptx_runtime_ptx_isa_target_architecture_at_least) (check_effective_target_nvptx_runtime_alloca_ptx) (add_options_for_nvptx_alloca_ptx): New. libgomp/ * fortran.c (omp_get_device_from_uid_): Adjust. * testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Likewise.
[Bug sanitizer/117960] [13 Regression] "Note that the only target -fsanitize=hwaddress is currently supported on is AArch64." is not true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117960 Jakub Jelinek changed: What|Removed |Added Summary|[13/14 Regression] "Note|[13 Regression] "Note that |that the only target|the only target |-fsanitize=hwaddress is |-fsanitize=hwaddress is |currently supported on is |currently supported on is |AArch64." is not true |AArch64." is not true --- Comment #4 from Jakub Jelinek --- Fixed for 14.3 as well.
