[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #40 from Xi Ruoyao --- mips patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648070.html (tested with -mabi=64)
[Bug tree-optimization/114396] [14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #9 from Richard Biener ---
(In reply to Robin Dapp from comment #8)
> No fallout on x86 or aarch64.
>
> Of course using false instead of TYPE_SIGN (utype) is also possible and
> maybe clearer?
Well, wi::from_mpz doesn't take a sign argument. It's comment says
/* Returns X converted to TYPE. If WRAP is true, then out-of-range
values of VAL will be wrapped; otherwise, they will be set to the
appropriate minimum or maximum TYPE bound. */
wide_int
wi::from_mpz (const_tree type, mpz_t x, bool wrap)
I'm not sure if we really want saturating behavior here, so 'true' is
more correct? Note if we want an unsigned result we should pass utype here,
that might be the bug? So
begin = wi::from_mpz (utype, res, true);
?
The to_mpz args look like they could be mixing signs as well:
case vect_step_op_mul:
{
tree utype = unsigned_type_for (type);
init_expr = gimple_convert (stmts, utype, init_expr);
wide_int skipn = wi::to_wide (skip_niters);
wide_int begin = wi::to_wide (step_expr);
auto_mpz base, exp, mod, res;
wi::to_mpz (begin, base, TYPE_SIGN (type));
TYPE_SIGN (step_expr)?
wi::to_mpz (skipn, exp, UNSIGNED);
TYPE_SIGN (skip_niters) (which should be UNSIGNED I guess)?
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #32 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:6a55e39bdb1fdb570730c08413ebbe744e493411 commit r14-9565-g6a55e39bdb1fdb570730c08413ebbe744e493411 Author: Richard Biener Date: Tue Mar 19 15:25:16 2024 +0100 middle-end/113396 - int128 array index and value-ranges The following fixes bogus truncation of a value-range for an int128 array index when computing the maximum extent for a variable array reference. Instead of possibly slowing things down by using widest_int the following makes sure the range bounds fit within the constraints offset_int were designed for. PR middle-end/113396 * tree-dfa.cc (get_ref_base_and_extent): Use index range bounds only if they fit within the address-range constraints of offset_int. * gcc.dg/torture/pr113396.c: New testcase.
[Bug middle-end/113396] [13 Regression] csmith: differences from -O2 to -O3 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Richard Biener changed: What|Removed |Added Known to work||14.0 Summary|[13/14 Regression] csmith: |[13 Regression] csmith: |differences from -O2 to -O3 |differences from -O2 to -O3 |since |since |r13-1268-g8c99e307b20c50|r13-1268-g8c99e307b20c50 --- Comment #33 from Richard Biener --- Fixed on trunk sofar.
[Bug libstdc++/114401] New: libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 Bug ID: 114401 Summary: libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jblair149 at gmail dot com Target Milestone: --- Created attachment 57742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57742&action=edit Source code for test program demonstrating the issue with allocator destruction on node handle insertion. Summary: Implementation in the following functions that reinsert nodes into `_Rb_tree` and `_Hashtable` may set the node handle data pointer to `nullptr`. This prevents stateful allocators from being properly destructed when extracting and reinserting nodes. Functions in stl_tree.h impacted: `insert_return_type _Rb_tree_impl::_M_reinsert_node_unique(node_type&& __nh)` `iterator _Rb_tree_impl::_M_reinsert_node_equal(node_type&& __nh)` `iterator _Rb_tree_impl::_M_reinsert_node_hint_unique(const_iterator __hint, node_type&& __nh)` `iterator _Rb_tree_impl::_M_reinsert_node_hint_equal(const_iterator __hint, node_type&& __nh)` Functions in hashtable.h impacted: `insert_return_type _Hashtable::_M_reinsert_node_unique(node_type&& __nh)` `insert_return_type _Hashtable::_M_reinsert_node_multi(const_iterator __hint, node_type&& __nh)` Details: The allocator of the node is asserted to be equal to the allocator of the underlying tree or hashtable in each function, but otherwise the allocator is unused, and on successful insertion `__nh._M_ptr` is set to `nullptr`. Following that, in the destructor of `_Node_handle_common`, `_M_reset()` is never called since the node is detected as `empty()`. Further, the union `_Optional_alloc` defined within `_Node_handle_common` has a no-op destructor, so only a manual invocation of `_Optional_alloc::release()` can trigger the destructor of the allocator contained, which may only be invoked if active. As a result, the allocator instance within the node is never destructed once the node has been reinserted into the tree or hashtable. This doesn't matter for stateless allocators, but for stateful ones this can result in a memory leak. One potential solution is to: 1) Add a new method to `_Node_handle_common` that will be called after a node is reinserted rather than simply setting `_M_ptr` to `nullptr`. That method would invoke `_M_alloc.release()` like `_M_reset()` does, and set the pointer `_M_ptr` to `nullptr`, but omit the actions to destroy the object and deallocate the memory since the node has been returned to a compatible container. 2) Within each of the functions mentioned within the files above, replace `__nh._M_ptr = nullptr;` with an invocation of the function in (1). I do not know for certain this is the maximal extent of the issue when reinserting extracted nodes, but I've expanded from my initial issue using `std::set` to the associative containers I'm aware of which expose `node_handle`. I also am not familiar with the naming conventions within the library. To that end, I'm omitting a patch since this may require discussion. I believe the current master branch of GCC exhibits the issue; I've confirmed it is present at least as of commit 994d8f922b9d88f45775f57a490409ab1c3baf59. This issue is likely present in past releases as well, but I don't know how that should be handled. Within the repository, the files I know are impacted are: gcc.git/libstdc++-v3/include/bits/node_handle.h gcc.git/libstdc++-v3/include/bits/stl_tree.h gcc.git/libstdc++-v3/include/bits/hashtable.h I'm attaching a relatively minimal program which demonstrates the issue. The program uses a logging, stateful allocator within a `std::set`, inserts elements, extracts a node, modifies the value of the element within the node, reinserts the node, and triggers the destruction of the set by the end of scope. Compilation of the program is as follows: g++ test_node_reinsert.cpp -o test_node_reinsert The test program may be run without arguments. The output of this program prior to the fix: Begin scope for allocator and set. initial construction allocate memory pools allocator copied; active count = 2 allocator copied; active count = 3 allocator copied; active count = 4 allocator destructed; active count = 3 allocator destructed; active count = 2 allocator copied; active count = 3 End scope for allocator and set. allocator destructed; active count = 2 allocator destructed; active count = 1 Allocator should be completely desctructed. The output of this program after my (hacky?) fix, following the instructions above: Begin scope for allocator and set. initial construction allocate memory pools allocator copied; active count = 2 allocator copied; active count = 3 al
[Bug target/112651] RISC-V Vector new option -mvect-lmul required to force LMUL values (rather than --param=riscv-autovec-lmul to hint at values)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651 --- Comment #6 from GCC Commits --- The master branch has been updated by Demin Han : https://gcc.gnu.org/g:cd1ce3b326d49c16bade1fb76daa2ee67586efc9 commit r14-9566-gcd1ce3b326d49c16bade1fb76daa2ee67586efc9 Author: demin.han Date: Wed Mar 13 18:43:26 2024 +0800 RISC-V: Introduce option -mrvv-max-lmul for RVV autovec Following replacement of -param=riscv-autovec-preference with -mrvv-vector-bits, this patch replaces -param=riscv-autovec-lmul with -mrvv-max-lmul. -param issue is mentioned in following links: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112648 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112651 Tested On RV64 and RV32, no regression. PR target/112651 gcc/ChangeLog: * config/riscv/riscv-opts.h (enum riscv_autovec_lmul_enum): Rename (enum rvv_max_lmul_enum): Ditto (TARGET_MAX_LMUL): Ditto * config/riscv/riscv-v.cc (preferred_simd_mode): Ditto * config/riscv/riscv-vector-costs.cc (costs::record_potential_unexpected_spills): Ditto (costs::better_main_loop_than_p): Ditto * config/riscv/riscv.opt: Replace -param=riscv-autovec-lmul with -mrvv-max-lmul gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/autovec/bug-2.C: Replace option * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-ice-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-ice-2.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-ice-3.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-mixed-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-2.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-3.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-4.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-5.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-6.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-7.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-2.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-3.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-4.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-5.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-6.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-10.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-11.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-12.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-2.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-3.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-5.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-7.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-9.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-10.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-11.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-12.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-13.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-14.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-2.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-3.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-4.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-5.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-6.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-7.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-8.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-9.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/no-dynamic-lmul-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr111317.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr111848.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr113112-1.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr113112-2.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr113112-3.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr113112-4.c: Ditto * gcc.dg/vect/costmodel/riscv/rvv/pr113112-5.c: Ditto * gcc.dg/v
[Bug target/114402] New: rs6000: ICE when long double is ieee128 format by default but without vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402
Bug ID: 114402
Summary: rs6000: ICE when long double is ieee128 format by
default but without vsx
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
When I was doing a patch to make us only have two 128bit fp on rs6000, I found
that we can have long double with ieee128 format by default and even not having
vsx support, but a simple test case with comparison triggers ICE as below:
long double a;
long double b;
int foo() {
if (a > b)
return 0;
else
return 1;
}
/opt/gcc-nightly/trunk/bin/gcc test.c -mno-vsx
test.c: In function ‘foo’:
test.c:9:1: error: unrecognizable insn:
9 | }
| ^
(insn 9 8 10 2 (set (reg:CCFP 123)
(compare:CCFP (reg:TF 117 [ a.0_1 ])
(reg:TF 118 [ b.1_2 ]))) "test.c":5:6 -1
(nil))
during RTL pass: vregs
test.c:9:1: internal compiler error: in extract_insn, at recog.cc:2812
0x102b7353 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/rtl-error.cc:108
0x102b73a7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/rtl-error.cc:116
0x10c6636b extract_insn(rtx_insn*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/recog.cc:2812
0x107ef797 instantiate_virtual_regs_in_insn
/home/gccbuild/gcc_trunk_git/gcc/gcc/function.cc:1611
0x107ef797 instantiate_virtual_regs
/home/gccbuild/gcc_trunk_git/gcc/gcc/function.cc:1994
0x107ef797 execute
/home/gccbuild/gcc_trunk_git/gcc/gcc/function.cc:2041
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/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #6 from Kewen Lin --- (In reply to Martin Jambor from comment #5) > I'd like to ping this, are there plans to implement this in the near-ish > term? Some weeks ago, Naveen had been doing some experiments to see if there is a better way for function tracer support, and if the idea works and the experiment result is promising, he may request something different, so we are still waiting for that. @Naveen Feel free to correct me if any misunderstanding.
[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #65 from Martin Jambor --- I hope to have some jump-function comparison functions ready for testing later today.
[Bug target/114402] rs6000: ICE when long double is ieee128 format by default but without vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114402 Kewen Lin changed: What|Removed |Added Target||powerpc64*-linux-gnu Keywords||ice-on-valid-code Target Milestone|--- |15.0 Known to fail||12.3.1, 13.2.1
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400 --- Comment #1 from Jonathan Wakely --- The resolution of LWG 3950 has not been implemented, at all. The use of __type_identity_t there dates from 2019 (r10-1886-g0d67cd380d37f2) and replaced earlier uses of common_type_t which date from the initial commit of std::experimental::string_view (r0-126555-g77cba5af77ccf8). The current code is 100% conforming, since the method of disambiguation is unspecified currently. LWG 3950 should be approved in a few days, and then we'll have to decide what to do (we can't use type_identity unconditionally because it doesn't exist in C++17, which is why I used __type_identity_t in the first place).
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400
--- Comment #2 from Jonathan Wakely ---
One option would be to make __type_identity_t an alias for type_identity_t in
C++20:
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -156,13 +156,30 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
using __conditional_t
= typename __conditional<_Cond>::template type<_If, _Else>;
+#ifdef __cpp_lib_type_identity // C++ >= 20
+ /** * Identity metafunction.
+ * @since C++20
+ * @{
+ */
+ template
+struct type_identity { using type = _Tp; };
+
+ template
+using type_identity_t = typename type_identity<_Tp>::type;
+ /// @}
+
+ template
+using __type_identity_t = type_identity_t<_Tp>;
+ template
+using __type_identity_t = type_identity_t<_Tp>;
+#else
/// @cond undocumented
template
-struct __type_identity
-{ using type = _Type; };
+using __type_identity = type_identity<_Type>;
template
using __type_identity_t = typename __type_identity<_Tp>::type;
+#endif
namespace __detail
{
@@ -3600,19 +3617,6 @@ template
/// @}
#endif // __cpp_lib_remove_cvref
-#ifdef __cpp_lib_type_identity // C++ >= 20
- /** * Identity metafunction.
- * @since C++20
- * @{
- */
- template
-struct type_identity { using type = _Tp; };
-
- template
-using type_identity_t = typename type_identity<_Tp>::type;
- /// @}
-#endif
-
#ifdef __cpp_lib_unwrap_ref // C++ >= 20
/** Unwrap a reference_wrapper
* @since C++20
I don't think we have any uses of __type_identity or __type_identity_t where
this will cause ABI changes. None of the types using __type_identity_t in
constructors are explicitly instantiated in the library.
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400
--- Comment #3 from Jonathan Wakely ---
Oops, that was meant to be:
#ifdef __cpp_lib_type_identity // C++ >= 20
/** * Identity metafunction.
* @since C++20
* @{
*/
template
struct type_identity { using type = _Tp; };
template
using type_identity_t = typename type_identity<_Tp>::type;
/// @}
template
using __type_identity = type_identity<_Tp>;
template
using __type_identity_t = type_identity_t<_Tp>;
#else
/// @cond undocumented
template
using __type_identity
{ using type = _Type; };
template
using __type_identity_t = typename __type_identity<_Tp>::type;
#endif
But that messes up the @cond / @endcond nesting. Anyway, something like that.
[Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 --- Comment #6 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5e64228fe1f7ec536da314246eec968aea0d704d commit r14-9567-g5e64228fe1f7ec536da314246eec968aea0d704d Author: Jakub Jelinek Date: Wed Mar 20 10:34:51 2024 +0100 system.h: rename vec_step to workaround powerpc/clang bug [PR114369] On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote: > Gerald Pfeifer writes: > > I have seen an increasing number of reports of GCC failing to > > build with clang on powerpc (on FreeBSD, though that's probably > > immaterial). > > > > Turns out that clang has vec_step as a reserved word on powerpc > > with AltiVec. > > > > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c. > > > > > > The best approach I can see is to rename vec_step. Before I prepare > > a patch: what alternate name/spelling would you prefer? > > Would it work to #define vec_step to vec_step_ or something on affected > hosts, say in system.h? > > I'd prefer that to renmaing since "vec_step" does seem the most natural > name for the variable. The equivalent scalar variable is "step" and > other vector values in the surrounding code also use the "vec_" prefix. So like this? If/when clang finally fixes https://github.com/llvm/llvm-project/issues/85579 on their side, we can then limit it to clang versions which still have the bug. I've git grepped for vec_set and appart from altivec.h it is just used in tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs, rs6000-vecdefines.h (but that header is only included from altivec.h and vec_step is then redefined to the function-like macro) and in rs6000-overload.def but that file is processed with a generator, not included in C/C++ sources. 2024-03-20 Jakub Jelinek PR bootstrap/114369 * system.h (vec_step): Define to vec_step_ when compiling with clang on PowerPC.
[Bug tree-optimization/114322] [14 Regression] SCEV analysis failed for bases like A[(i+x)*stride] since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114322 --- Comment #4 from GCC Commits --- The master branch has been updated by Hao Liu : https://gcc.gnu.org/g:4c276896d646c2dbc8047fd81d6e65f8c5ecf01d commit r14-9569-g4c276896d646c2dbc8047fd81d6e65f8c5ecf01d Author: Hao Liu Date: Wed Mar 20 17:37:01 2024 +0800 testsuite: add the case to cover the vectorization of A[(i+x)*stride] [PR114322] This issues has been fixed by r14-9540-ge0e9499a in PR114151. Tested on aarch64-linux-gnu. gcc/testsuite/ChangeLog: PR tree-optimization/114322 * gcc.dg/vect/pr114322.c: New testcase.
[Bug middle-end/114348] Corrupt SARIF output on stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348 --- Comment #6 from Tobias Specht --- Thanks for fixing this! Waiting for the gcc 13 backport. Having formatted json output sounds like a nice feature for me too.
[Bug tree-optimization/114365] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 5 at -O with _BitInt() shift in a bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114365 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:456e10f28b36aa417e0db145556831c4f979fbd7 commit r14-9570-g456e10f28b36aa417e0db145556831c4f979fbd7 Author: Jakub Jelinek Date: Wed Mar 20 10:55:07 2024 +0100 bitint: Fix handling of conditional bitfield loads [PR114365] For the m_var_msb (aka left shift) case of large/huge _BitInt bitfield loads handle_load adds a PHI node, but I forgot to actually update the temporary the code later on uses, so the PHI result was unused and the code incorrectly used something that wasn't valid SSA form. In particular, we emitted if (_29 != 2) goto ; [80.00%] else goto ; [20.00%] [local count: 1073741824]: _33 = VIEW_CONVERT_EXPR(s.D.2771)[_31]; [local count: 1073741824]: # _34 = PHI <_33(4), 0(3)> _35 = _32 >> 31; _36 = _33 << 33; _37 = _36 | _35; _38 = _37 << _19; where instead of _33 the _36 def stmt should be using _34. Fixed thusly. 2024-03-20 Jakub Jelinek PR tree-optimization/114365 * gimple-lower-bitint.cc (bitint_large_huge::handle_load): When adding a PHI node, set iv2 to its result afterwards. * gcc.dg/bitint-102.c: New test.
[Bug tree-optimization/114365] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 5 at -O with _BitInt() shift in a bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114365 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Should be fixed now.
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400 --- Comment #4 from Jiang An --- (In reply to Jonathan Wakely from comment #1) > The resolution of LWG 3950 has not been implemented, at all. Hmm... r14-5349 seems "implementing the resolution" per the commit message. Perhaps I misread something.
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400 --- Comment #5 from Jonathan Wakely --- It was simplifying the overload set, consistent with the proposed resolution of 3950. If 3950 breaks existing implementations, then arguably 3950 is wrong and should not be approved.
[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #10 from Jiang An --- I think this is basically CWG2709 (https://cplusplus.github.io/CWG/issues/2709.html). Given CWG2709 is closed as NAD, we should reject such initializations.
[Bug tree-optimization/114403] New: [14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 Bug ID: 114403 Summary: [14 regression] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 57743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57743&action=edit build-llvm.sh I get the following test failures for LLVM 17.0.6: ``` Failed Tests (17): LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.d.ll LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.g16.a16.ll LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.g16.ll LLVM :: CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.image.sample.cd.g16.ll LLVM :: CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.image.sample.g16.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.nsa.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.a16.dim.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.cd.a16.dim.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.cd.g16.encode.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.cd.g16.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.dim.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.g16.a16.dim.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.g16.encode.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.g16.ll LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.o.dim.ll LLVM :: CodeGen/NVPTX/wmma.py ``` I can reproduce it with -O3 -march=znver -fno-vect-cost-model. It also then shows up if Clang is used to build Firefox. I will do the usual narrowing down but my success rate for producing test cases from LLVM is poor ;) Picking the first one: ``` FAIL: LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll (5582 of 50819) TEST 'LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll' FAILED Script: -- : 'RUN: at line 2'; /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc -global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o - /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll | /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck -check-prefix=GFX9 /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll : 'RUN: at line 3'; /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc -global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx1010 -stop-after=legalizer -o - /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll | /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck -check-prefix=GFX10 /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll : 'RUN: at line 4'; /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc -global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx1100 -stop-after=legalizer -o - /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll | /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck -check-prefix=GFX11 /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll -- Exit Code: 2 Command Output (stderr): -- + : 'RUN: at line 2' + /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc -global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o - /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll + /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck -check-prefix=GFX9 /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc -global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o - /var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll 1. Running pass 'Function Pass Manager' on module '/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll'. 2. Running pass 'E
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 Sam James changed: What|Removed |Added Summary|[14 regression] |[14 regression] LLVM ||miscompiled with -O3 ||-march=znver2 ||-fno-vect-cost-model --- Comment #1 from Sam James --- Bisecting GCC first then I'll bisect object files in LLVM.
[Bug c/114404] New: [11] GCC reorders stores when it probably shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404
Bug ID: 114404
Summary: [11] GCC reorders stores when it probably shouldn't
Product: gcc
Version: 11.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
Reproducible with gcc commit 1b5510a59163.
I'm writing this up as a result of the following linux kernel discussion:
https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d...@gmail.com/
https://lore.kernel.org/bpf/20240320015515.11883-1-...@linux.ibm.com/
In the following code:
extern const char bpf_plt[];
extern const char bpf_plt_ret[];
extern const char bpf_plt_target[];
static void bpf_jit_plt(void *plt, void *ret, void *target)
{
memcpy(plt, bpf_plt, BPF_PLT_SIZE);
*(void **)((char *)plt + (bpf_plt_ret - bpf_plt)) = ret;
*(void **)((char *)plt + (bpf_plt_target - bpf_plt)) = target ?: ret;
}
GCC 11's sched1 pass reorders memcpy() and assignments. In GCC 12 this
behavior is gone after
commit 2e96b5f14e4025691b57d2301d71aa6092ed44bc
Author: Aldy Hernandez
Date: Tue Jun 15 12:32:51 2021 +0200
Backwards jump threader rewrite with ranger.
but this seems to be accidental. Internally, output_dependence() for the
respective mems returns false, because it believes that they are based on
different SYMBOL_REFs. This may be because on the C level we are not allowed
to subtract pointers to different objects.
However, a possible solution to this should be casting pointers to longs, since
C pointer subtraction rules would no longer apply, but in practice this does
nothing.
In the attached minimized preprocessed source with long casts we get:
stg %r3,232(%r2,%r15)
ltgr%r11,%r11
locgrne %r3,%r11
stg %r3,232(%r1,%r15)
la %r2,0(%r1,%r9)
la %r3,232(%r1,%r15)
mvc 232(16,%r15),0(%r5)
mvc 248(16,%r15),16(%r5)
lghi%r4,8
brasl %r14,s390_kernel_write@PLT
so the assignments are placed before the memcpy().
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #2 from Sam James ---
Better output (includes the assertion failure):
```
$ /home/sam/data/build/llvm-project-test/bin/llc -global-isel
-mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o -
/home/sam/git/llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
llc: /home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:243:
llvm::ScopedHashTableScope::~ScopedHashTableScope()
[with K = {anonymous}::CallValue; V = std::pair; KInfo = llvm::DenseMapInfo<{anonymous}::CallValue>; AllocatorTy =
llvm::MallocAllocator]: Assertion `HT.TopLevelMap[ThisEntry->getKey()] ==
ThisEntry && "Scope imbalance!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace.
Stack dump:
0. Program arguments: /home/sam/data/build/llvm-project-test/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o
-
/home/sam/git/llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
1. Running pass 'Function Pass Manager' on module
'/home/sam/git/llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll'.
2. Running pass 'Early CSE' on function '@sample_d_2d'
#0 0x7f1df2a1709f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/sam/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:602:22
#1 0x7f1df2a1411b llvm::sys::RunSignalHandlers()
/home/sam/git/llvm-project/llvm/lib/Support/Signals.cpp:104:20
#2 0x7f1df2a1411b SignalHandler(int)
/home/sam/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:403:31
#3 0x7f1df226ac10 (/usr/lib64/libc.so.6+0x3bc10)
#4 0x7f1df22c029c (/usr/lib64/libc.so.6+0x9129c)
#5 0x7f1df226ab62 raise (/usr/lib64/libc.so.6+0x3bb62)
#6 0x7f1df22534f0 abort (/usr/lib64/libc.so.6+0x244f0)
#7 0x7f1df2253418 (/usr/lib64/libc.so.6+0x24418)
#8 0x7f1df2263392 (/usr/lib64/libc.so.6+0x34392)
#9 0x7f1df412f794 ~ScopedHashTableScope
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:243:7
#10 0x7f1df412f794 ~ScopedHashTableScope
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:235:1
#11 0x7f1df412f794 ~NodeScope
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:667:9
#12 0x7f1df412f794 ~StackNode
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:687:9
#13 0x7f1df412f794 (anonymous namespace)::EarlyCSE::run()
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:1708:14
#14 0x7f1df4131085 (anonymous
namespace)::EarlyCSELegacyCommonPass::runOnFunction(llvm::Function&)
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:1782:3
#15 0x7f1df2ee1291 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1435:40
#16 0x7f1df2ee179c llvm::ilist_node_base::getNext() const
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ilist_node_base.h:29:45
#17 0x7f1df2ee179c
llvm::ilist_node_impl>::getNext()
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ilist_node.h:67:66
#18 0x7f1df2ee179c
llvm::ilist_iterator, false, false>::operator++()
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ilist_iterator.h:157:25
#19 0x7f1df2ee179c llvm::FPPassManager::runOnModule(llvm::Module&)
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1480:22
#20 0x7f1df2ee1f5d runOnModule
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1557:7
#21 0x7f1df2ee1f5d llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:535:55
#22 0x55c1916feb5b compileModule(char**, llvm::LLVMContext&)
/home/sam/git/llvm-project/llvm/tools/llc/llc.cpp:754:66
#23 0x55c1916f3753 main
/home/sam/git/llvm-project/llvm/tools/llc/llc.cpp:416:5
#24 0x7f1df2254e58 (/usr/lib64/libc.so.6+0x25e58)
#25 0x7f1df2254f15 __libc_start_main (/usr/lib64/libc.so.6+0x25f15)
#26 0x55c1916f3d01 _start
(/home/sam/data/build/llvm-project-test/bin/llc+0x10d01)
Aborted
```
[Bug c/114404] [11] GCC reorders stores when it probably shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404 --- Comment #1 from Ilya Leoshkevich --- Created attachment 57744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57744&action=edit preprocessed source
[Bug c/114404] [11] GCC reorders stores when it probably shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404 --- Comment #2 from Ilya Leoshkevich --- Created attachment 57745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57745&action=edit cc1 invocation
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400
--- Comment #6 from Jonathan Wakely ---
Alternatively:
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -602,15 +602,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// deduction and the other argument gets implicitly converted to the deduced
// type (see N3766).
+#if __cpp_lib_three_way_comparison
template
[[nodiscard]]
constexpr bool
operator==(basic_string_view<_CharT, _Traits> __x,
- __type_identity_t> __y)
+ type_identity_t> __y)
noexcept
{ return __x.size() == __y.size() && __x.compare(__y) == 0; }
-#if __cpp_lib_three_way_comparison
template
[[nodiscard]]
constexpr auto
@@ -620,7 +620,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
-> decltype(__detail::__char_traits_cmp_cat<_Traits>(0))
{ return __detail::__char_traits_cmp_cat<_Traits>(__x.compare(__y)); }
#else
- template
+ template
+[[nodiscard]]
+constexpr bool
+operator==(basic_string_view<_CharT, _Traits> __x,
+ __type_identity_t> __y)
+noexcept
+{ return __x.size() == __y.size() && __x.compare(__y) == 0; }
+
+me _CharT, typename _Traits>
[[nodiscard]]
constexpr bool
operator==(basic_string_view<_CharT, _Traits> __x,
Our other uses of __type_identity_t (e.g. in container constructors) are
probably OK. Users can't overload those, and the exact signatures of member
functions are unspecified anyway (we can add/remove default arguments).
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396 Sam James changed: What|Removed |Added Summary|[14 Regression] Vector: |[13/14 Regression] Vector: |Runtime mismatch at -O2 |Runtime mismatch at -O2 |with -fwrapv|with -fwrapv --- Comment #10 from Sam James --- (In reply to Robin Dapp from comment #3) > -O3 -mavx2 -fno-vect-cost-model -fwrapv seems to be sufficient. This crashes for me with GCC 13 too.
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396 --- Comment #11 from Sam James --- Bisecting.
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
--- Comment #21 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #20)
> here is the current list as far as I can tell:
> config/locale/dragonfly/codecvt_members.cc
> config/locale/gnu/codecvt_members.cc
> config/locale/gnu/messages_members.cc
See above.
> include/bits/fstream.tcc
This is potentially unbounded. A malicious user could use filebuf::setbuf to
give the filebuf a huge buffer, and imbue a custom codecvt facet with a large
do_max_length(). Then the alloca would use buflen * maxlen. That could even
overflow. In practice the maximum size will be BUFSZ*4 or so.
> include/bits/locale_facets.tcc (some there are ok as the values are actually
> constant)
maximum alloca for the formatted integer is sizeof(wchar_t) * 5 * sizeof(long
long) + 1
but then we allocate io.width() * sizeof(wchar_t) which could be set to
something huge by a silly user. We also do three alloca calls in the same
function.
For a formatted float it's numeric_limits::digits10 * 3 for the
first alloca, but we use alloca several times, and the max depends on
io.precision() and io.width() so we might need a large buffer.
These need some sanity checks, and use the heap as a fallback. See PR 87228 for
that.
> include/bits/locale_facets_nonio.tcc
These are all fixed size and small.
> include/ext/codecvt_specializations.h (BOM case)
Depends on the size of the input being converted, which could be large. This is
unsafe (but I don't think anybody uses this extension).
> include/ext/string_conversions.h
The worst case is std::to_wstring(long double) which uses:
sizeof(wchar_t) * (__numeric_traits::__max_exponent10 + 20)
So maximum 4 * (4932 + 20) == 19808
That's too big.
> include/std/format (non-char type formating and localization)
Tightly bounded to 2 * ndigits * sizeof(wchar_t) + prefix_len
The worst case is something like std::format("{:#0b}", LLONG_MIN) where the
alloca will be for 2 * 64 * 4 + 3 which is only 515 bytes.
> src/c++11/functexcept.cc (__throw_out_of_range_fmt)
strlen(fmt) + 512, where fmt is ~40 bytes. Users could call that function
themselves, but then that's their problem. It's an internal impl detail, and
our uses are safe.
> src/c++11/snprintf_lite.cc (__throw_insufficient_space)
Another internal impl detail, but this one is not even visible to users. No
declaration in headers, not exported from the shared lib. This one uses alloca
for the same size as __throw_out_of_range_fmt + 104 bytes, but we've already
done the first alloca, so it's (strlen(fmt) + 512) * 2 + 104.
[Bug libstdc++/114401] libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-03-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396 Sam James changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #12 from Sam James --- (In reply to Sam James from comment #11) > Bisecting. commit r13-7988-g82919cf4cb2321 Author: liuhongt Date: Wed Oct 18 10:08:24 2023 +0800 Avoid compile time hog on vect_peel_nonlinear_iv_init for nonlinear induction vec_step_op_mul when iteration count is too big. There's loop in vect_peel_nonlinear_iv_init to get init_expr * pow (step_expr, skip_niters). When skipn_iters is too big, compile time hogs. To avoid that, optimize init_expr * pow (step_expr, skip_niters) to init_expr << (exact_log2 (step_expr) * skip_niters) when step_expr is pow of 2, otherwise give up vectorization when skip_niters >= TYPE_PRECISION (TREE_TYPE (init_expr)).
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv since r13-7988-g82919cf4cb2321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396 Sam James changed: What|Removed |Added Known to fail||13.2.1 --- Comment #13 from Sam James --- That commit got backported so 13.2 is fine, but releases/gcc-13 isn't.
[Bug target/114404] [11] GCC reorders stores when it probably shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404 Richard Biener changed: What|Removed |Added Component|c |target --- Comment #3 from Richard Biener --- Sounds similar to PR113255. Yes, the code is undefined and you should cast the pointers to uintptr_t but for the RTL problem that won't help. Note the increment of 'plt' is similarly invalid so that has to be uintptr_t as well. It might be that different (no) REG_POINTER marking will then avoid the latent PR113255 issue from triggering. It might be that the s390 cpymem expander does some bogus REG_POINTER marking as well (or that it lacks marking, causing the heuristics to go wrong). You can check whether backporting the PR113255 fix avoids the issue, but I do not consider backporting the revs suitable.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |14.0
[Bug testsuite/109596] [14 Regression] Lots of guality testcase fails on x86_64 after r14-162-gcda246f8b421ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #10 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #9)
> BTW, just curious, r14-162 had:
>/* Ensure that the header will have just the latch as a predecessor
> inside the loop. */
> - if (!single_pred_p (exit->dest))
> + if (!single_pred_p (nonexit->dest))
> {
> - header = split_edge (exit);
> + header = split_edge (nonexit);
> exit = single_pred_edge (header);
> }
> chunk, shouldn't that be nonexit = single_pred_edge (header); or is that
> line correct?
Regarding that, e.g. gcc.c-torture/compile/pr70199.c testcase at -O1 -g shows
both cases, once where single_pred_p (nonexit->dest) and once where
!single_pred_p (nonexit->dest) and we split the nonexit edge.
Or the !single_pred_p case is also in c-c++-common/gomp/pr59917-2.c,
gcc.dg/torture/pr83685.c.
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #34 from Richard Biener --- (In reply to Andreas Krebbel from comment #1) > This appears to be triggered by try_combine unnecessarily setting back the > position by returning the i2 insn. > > When 866 is inserted into 973 866 still needs to be kept around for other > users. So try_combine first merges the two sets into a parallel and > immediately notices that this can't be recognized. Because none of the sets > is a trivial move it is split again into two separate insns. Although the > new i2 pattern exactly matches the input i2 combine considers this to be a > new insn and triggers all the scanning log link creation and eventually > returns it what let's the combine start all over at 866. > > Due to that combine tries many of the substitutions more than 400x. > > Trying 866 -> 973: > 866: r22393:DI=r22391:DI+r22392:DI > 973: r22499:DF=r22498:DF*[r22393:DI] > REG_DEAD r22498:DF > Failed to match this instruction: > (parallel [ > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) > ]) > Failed to match this instruction: > (parallel [ > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) > ]) > Successfully matched this instruction: > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) So this is "unchanged", do we re-combine into it? > Successfully matched this instruction: > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) This one is changed. > allowing combination of insns 866 and 973 > original costs 4 + 4 = 8 > replacement costs 4 + 4 = 8 > modifying insn i2 866: r22393:DI=r22391:DI+r22392:DI > deferring rescan insn with uid = 866. > modifying insn i3 973: r22499:DF=r22498:DF*[r22391:DI+r22392:DI] > REG_DEAD r22498:DF > deferring rescan insn with uid = 973. The change itself looks reasonable given costs, though maybe 2 -> 2 combinations should not trigger when the cost remains the same? In this case it definitely doesn't look profitable, does it? Well, in theory it might hide latency and the 2nd instruction can issue at the same time as the first.
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv since r13-7988-g82919cf4cb2321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|14.0|13.3 --- Comment #14 from Richard Biener --- Thus P1.
[Bug tree-optimization/114405] New: ICE: in min_value, at wide-int.cc:344 with _BitInt() bitfield arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405 Bug ID: 114405 Summary: ICE: in min_value, at wide-int.cc:344 with _BitInt() bitfield arithmetics Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57746&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during GIMPLE pass: dom testcase.c: In function 'foo': testcase.c:6:1: internal compiler error: in min_value, at wide-int.cc:344 6 | foo () | ^~~ 0x8b5cef wi::min_value(unsigned int, signop) /repo/gcc-trunk/gcc/wide-int.cc:344 0xe905c0 irange::set_varying(tree_node*) /repo/gcc-trunk/gcc/value-range.h:1084 0x26a548d ranger_cache::get_global_range(vrange&, tree_node*) const /repo/gcc-trunk/gcc/gimple-range-cache.cc:1019 0x26a548d ranger_cache::get_global_range(vrange&, tree_node*) const /repo/gcc-trunk/gcc/gimple-range-cache.cc:1015 0x26a01eb gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*) /repo/gcc-trunk/gcc/gimple-range.cc:131 0x164a000 cprop_operand /repo/gcc-trunk/gcc/tree-ssa-dom.cc:2038 0x164c402 cprop_into_stmt /repo/gcc-trunk/gcc/tree-ssa-dom.cc:2115 0x164c402 dom_opt_dom_walker::optimize_stmt(basic_block_def*, gimple_stmt_iterator*, bool*) /repo/gcc-trunk/gcc/tree-ssa-dom.cc:2343 0x164dc97 dom_opt_dom_walker::before_dom_children(basic_block_def*) /repo/gcc-trunk/gcc/tree-ssa-dom.cc:1748 0x263f7ae dom_walker::walk(basic_block_def*) /repo/gcc-trunk/gcc/domwalk.cc:311 0x164e728 execute /repo/gcc-trunk/gcc/tree-ssa-dom.cc:939 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9570-20240320105507-g456e10f28b3-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9570-20240320105507-g456e10f28b3-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240320 (experimental) (GCC)
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277 --- Comment #22 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #21) > (In reply to Andrew Pinski from comment #20) > > src/c++11/snprintf_lite.cc (__throw_insufficient_space) > > Another internal impl detail, but this one is not even visible to users. No > declaration in headers, not exported from the shared lib. This one uses > alloca for the same size as __throw_out_of_range_fmt + 104 bytes, but we've > already done the first alloca, so it's (strlen(fmt) + 512) * 2 + 104. There's also __concat_size_t in that file, but it only uses alloca for 3*sizeof(size_t), and that is unnecessary and should be replaced with std::to_chars.
[Bug middle-end/114406] New: Optimizations with ">>", div, mod and mul where operands are all positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114406
Bug ID: 114406
Summary: Optimizations with ">>", div, mod and mul where
operands are all positive
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Explorer09 at gmail dot com
Target Milestone: ---
GCC missed some optimizations on the right shift (>>), division (/)
and modulo (%) operations where the signedness of the operations,
and the bit width of the operations, do not matter.
When the operands can be found at compile time to be all positive,
and the results can't overflow, then it won't matter whether a signed
(arithmetic) right shift or an unsigned (logical) shift is to be used.
The same applies to division, modulo and multiplication.
My main complaint was on the right shift, where I discovered that
(value = 0x >> count) and (value = 0xU >> count) can produce
different code size. Technically it shouldn't matter whether I used
that unsigned cast ('U' suffix) on the constant literal.
Here I mention two cases where the operands can be known to be
positive:
1. The operand is a constant, evaluated to be positive.
2. The operand originates from an unsigned type, up-cast to a longer,
signed type.
(bug 102580 mentioned the third case where the operand can only be
nonnegative after a conditional, which is not part of my cases.)
Here is the test code where I think can help GCC developers.
The expected outcome would be all functions optimized to simply
{ return true; } statements. The actual results between GCC and Clang
are noted in comments.
```c
// Tested in Compiler Explorer (godbolt.org)
// GCC 13.2 x86-64 with '-Os' option
// Clang 18.1.0 x86-64 with '-Os' option
#include
#include
// Right shift tests
// -
bool test_rshift_1(unsigned char count) {
// Positive constants in 'int' and 'unsigned int' types
int a = 12345 >> count;
int b = 12345U >> count;
int32_t c = 0x7FFF >> count;
uint32_t d = 0x7FFFU >> count;
return a == b && (int32_t)c == d;
}
// test_rshift_1
// GCC fails; Clang succeeds
// (GCC can recognize 0x7FFF and 0x7FFFU are identical and
// emits one load instruction, but emits separate SAR and SHR (x86)
// instructions not knowing they make the same results in this case.)
bool test_rshift_2a(unsigned char count) {
// Positive constants with different bit width
long long a = 0x7FFF >> count;
long long b = 0x7FFFLL >> count;
unsigned long long c = 0x7FFFU >> count;
unsigned long long d = 0x7FFFULL >> count;
return a == b && c == d && (unsigned long long)b == d;
}
// test_rshift_2a
// Both GCC and Clang fail
// (Both do not recognize 0x7FFF and 0x7FFFLL are identical
// and that the load instructions can be merged.)
bool test_rshift_2b(unsigned char count) {
// By the C standard, 0x8000 should be interpreted as unsigned
// but ultimately the width and signedness do not matter
long long a = 0x8000LL >> count;
long long b = 0x8000U >> count;
long long c = 0x8000 >> count;
return a == b && b == c;
}
// test_rshift_2b
// Both GCC and Clang fail (details same as above)
bool test_rshift_3(uint16_t x, unsigned char count) {
// 'x' is known to be positive despite the signed type up-cast
int32_t a = (int32_t)x >> count;
uint32_t b = (uint32_t)x >> count;
return (uint32_t)a == b;
}
// test_rshift_3
// GCC fails (SAR and SHR not merged); Clang succeeds
bool test_rshift_4(uint32_t x, unsigned char count) {
// 'x' is known to be positive despite the signed type up-cast
uint32_t a = x >> count;
int64_t b = (int64_t)x >> count;
return a == (uint32_t)b && (int64_t)a == b;
}
// test_rshift_4
// Both GCC and Clang fail
// (Both missed that type width do not matter here; GCC also missed
// on SAR and SHR not merged.
// Interesting note: GCC can omit the (a == (uint32_t)b) comparison,
// but only when the ((int64_t)a == b) comparison is presented
// first. In this particular example, GCC missed as well.)
// Division and modulo tests
// -
bool test_div_1(uint8_t divisor) {
// The signedness of division do not matter when the dividend and
// divisor are both positive.
// Here the dividend is a constant, and divisor is promoted from
// an unsigned type.
// (The C standard requires 'int' to have at least 16 bits)
int a = 12345 / divisor;
int b = 12345U / divisor;
return a == b;
}
// test_div_1
// GCC fails; Clang succeeds
// (GCC can recognize identical constants and emits one load
// instruction, but emits separate IDIV and DIV (x86) instructions
// not knowing they can be merged.)
bool test_div_2(uint8_t divisor) {
// Positive constants with different bit width
int16_t a = (int16_t)(32767 / divisor);
int32_t b = (int32_t)32767 / divisor;
l
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv since r13-7988-g82919cf4cb2321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396
--- Comment #15 from Hongtao Liu ---
(In reply to Richard Biener from comment #9)
> (In reply to Robin Dapp from comment #8)
> > No fallout on x86 or aarch64.
> >
> > Of course using false instead of TYPE_SIGN (utype) is also possible and
> > maybe clearer?
>
> Well, wi::from_mpz doesn't take a sign argument. It's comment says
>
> /* Returns X converted to TYPE. If WRAP is true, then out-of-range
>values of VAL will be wrapped; otherwise, they will be set to the
>appropriate minimum or maximum TYPE bound. */
> wide_int
> wi::from_mpz (const_tree type, mpz_t x, bool wrap)
>
> I'm not sure if we really want saturating behavior here, so 'true' is
> more correct? Note if we want an unsigned result we should pass utype here,
> that might be the bug? So
>
> begin = wi::from_mpz (utype, res, true);
>
> ?
Yes, it should be.
>
> The to_mpz args look like they could be mixing signs as well:
>
> case vect_step_op_mul:
> {
> tree utype = unsigned_type_for (type);
> init_expr = gimple_convert (stmts, utype, init_expr);
> wide_int skipn = wi::to_wide (skip_niters);
> wide_int begin = wi::to_wide (step_expr);
> auto_mpz base, exp, mod, res;
> wi::to_mpz (begin, base, TYPE_SIGN (type));
>
> TYPE_SIGN (step_expr)?
step_expr should have same type as init_expr.
>
> wi::to_mpz (skipn, exp, UNSIGNED);
>
> TYPE_SIGN (skip_niters) (which should be UNSIGNED I guess)?
skipn must be a postive value, so I assume UNSIGNED/SIGNED doesn't make any
difference here.
[Bug tree-optimization/114396] [13/14 Regression] Vector: Runtime mismatch at -O2 with -fwrapv since r13-7988-g82919cf4cb2321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114396 Hongtao Liu changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #16 from Hongtao Liu --- Mine.
[Bug middle-end/114406] Optimizations with ">>", div, mod and mul where operands are all positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114406 Xi Ruoyao changed: What|Removed |Added Resolution|--- |DUPLICATE CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Xi Ruoyao --- Dup. *** This bug has been marked as a duplicate of bug 89163 ***
[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 Xi Ruoyao changed: What|Removed |Added CC||Explorer09 at gmail dot com --- Comment #2 from Xi Ruoyao --- *** Bug 114406 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- Maybe we can at least perform the canonization for shifting a constant as 114406 requests.
[Bug c++/114395] [c++20+] std::is_constructible_v result of const reference incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114395 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-03-20
[Bug target/114407] New: Typo 'enabing' in loongarch-opts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114407 Bug ID: 114407 Summary: Typo 'enabing' in loongarch-opts.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: translation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: loongarch "enabing %qs promotes %<%s%s%> to %<%s%s%>" Should be "enabling".
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 --- Comment #13 from Roland Illig --- See also bug 114407.
[Bug tree-optimization/114405] ICE: in min_value, at wide-int.cc:344 with _BitInt() bitfield arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-03-20 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 57747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57747&action=edit gcc14-pr114405.patch Untested fix.
[Bug target/114404] [11] GCC reorders stores when it probably shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404 --- Comment #4 from Ilya Leoshkevich --- Thanks, cherry-picking https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a98d5130a6dcff2ed4db371e500550134777b8cf helped both with the minimized testcase and the actual kernel bug. What you describe there - reassociation causing a wrong base term to be selected - matches what I've seen during debugging as well. So let's close this as a duplicate.
[Bug target/114404] [11] GCC reorders stores when it probably shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Richard Biener --- Duplicate then. *** This bug has been marked as a duplicate of bug 49330 ***
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 Richard Biener changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #33 from Richard Biener --- *** Bug 114404 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 --- Comment #4 from Kang-Che Sung --- (In reply to Xi Ruoyao from comment #2) > *** Bug 114406 has been marked as a duplicate of this bug. *** I can't say bug 114406 is an exact duplicate of this one. Although my report mainly addresses right shift, I also mentioned division, modulo and multiplication. These can also be optimized where the signedness of the operations do not matter.
[Bug libstdc++/114401] libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Jonathan Wakely --- Created attachment 57748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57748&action=edit Untested patch to fix all assoc containers Thanks for the report and analysis. This should do it.
[Bug libstdc++/114401] libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.5 Keywords||wrong-code
[Bug ipa/114408] New: Crash when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408
Bug ID: 114408
Summary: Crash when invoking strcmp multiple times with
-fsanitize=undefined -O1 -fanalyzer -flto
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int main(){}
int HMAP_unset_copy(const char *key) {
return __builtin_strcmp("a", key) + __builtin_strcmp("a", key);
}
Compiling this program with `-fsanitize=undefined -O1 -fanalyzer -flto` results
in the following:
: In function 'HMAP_unset_copy':
:4:41: warning: check of 'key_4(D)' for NULL after already
dereferencing it [-Wanalyzer-deref-before-check]
4 | return __builtin_strcmp("a", key) + __builtin_strcmp("a", key);
| ^
'HMAP_unset_copy': events 1-2
|
|4 | return __builtin_strcmp("a", key) + __builtin_strcmp("a",
key);
| |^~
| |||
| ||(2) pointer 'key_4(D)' is
checked for NULL here but it was already dereferenced at (1)
| |(1) pointer 'key_4(D)' is dereferenced here
|
during IPA pass: whole-program
At top level:
lto1: internal compiler error: in release_function_body, at cgraph.cc:1813
0x221519c internal_error(char const*, ...)
???:0
0x926a67 fancy_abort(char const*, int, char const*)
???:0
0xa1a687 cgraph_node::release_body(bool)
???:0
0xa1c2d2 cgraph_node::remove()
???:0
0xcea661 symbol_table::remove_unreachable_nodes(_IO_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 <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: /opt/compiler-explorer/gcc-snapshot/bin/gcc returned
1 exit status
compilation terminated.
/opt/compiler-explorer/gcc-trunk-20240320/bin/../lib/gcc/x86_64-linux-gnu/14.0.1/../../../../x86_64-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Compiler returned: 1
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #42 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b089ceb365e5132e4b2a8acfb18127bbee2d0d00 commit r14-9574-gb089ceb365e5132e4b2a8acfb18127bbee2d0d00 Author: Jakub Jelinek Date: Wed Mar 20 16:59:21 2024 +0100 epiphany: Fix up epiphany_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, epiphany seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #41 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:68eca9b6aefeb40bdd4c55e42528cb32d1e2935b commit r14-9573-g68eca9b6aefeb40bdd4c55e42528cb32d1e2935b Author: Jakub Jelinek Date: Wed Mar 20 16:59:08 2024 +0100 csky: Fix up csky_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, csky seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/csky/csky.cc (csky_setup_incoming_varargs): Only skip csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #43 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:22612a8b5e0853c530f98fc7c0d6f6812b36518d commit r14-9575-g22612a8b5e0853c530f98fc7c0d6f6812b36518d Author: Jakub Jelinek Date: Wed Mar 20 16:59:32 2024 +0100 ft32: Fix up ft32_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, ft32 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #44 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:921eb457c5b105bcd84eaeac22067e9b03d5b9d1 commit r14-9576-g921eb457c5b105bcd84eaeac22067e9b03d5b9d1 Author: Jakub Jelinek Date: Wed Mar 20 16:59:43 2024 +0100 m32r: Fix up m32r_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, m32r seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/m32r/m32r.cc (m32r_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #46 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4c9d2810908004b7e04599b426aca5ee1bd16735 commit r14-9578-g4c9d2810908004b7e04599b426aca5ee1bd16735 Author: Jakub Jelinek Date: Wed Mar 20 17:00:08 2024 +0100 nios2: Fix up nios2_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, nios2 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #45 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b22a9c7dd29a14a217de8b86d3e100e4e8b7785e commit r14-9577-gb22a9c7dd29a14a217de8b86d3e100e4e8b7785e Author: Jakub Jelinek Date: Wed Mar 20 16:59:56 2024 +0100 nds32: Fix up nds32_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, nds32 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #47 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b05ee9b69e4644cefbb94a768c4ea302fd44b934 commit r14-9579-gb05ee9b69e4644cefbb94a768c4ea302fd44b934 Author: Jakub Jelinek Date: Wed Mar 20 17:00:51 2024 +0100 visium: Fix up visium_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, visium seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/visium/visium.cc (visium_setup_incoming_varargs): Only skip TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL.
[Bug ipa/108802] [11/12/13 Regression] missed inlining of call via pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 Martin Jambor changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |missed inlining of call via |missed inlining of call via |pointer to member function |pointer to member function --- Comment #10 from Martin Jambor --- Fixed on trunk. I may consider backporting to GCC 13 but probably not to earlier versions.
[Bug ipa/114254] [11/12/13 regression] Indirect inlining through C++ member pointers fails if the underlying class has a virtual function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254 Martin Jambor changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13 regression] |Indirect inlining through |Indirect inlining through |C++ member pointers fails |C++ member pointers fails |if the underlying class has |if the underlying class has |a virtual function |a virtual function --- Comment #3 from Martin Jambor --- Fixed on trunk. I may consider backporting to GCC 13 but probably not to earlier versions.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 Sam James changed: What|Removed |Added Summary|[14 regression] LLVM|[14 regression] LLVM |miscompiled with -O3|miscompiled with -O3 |-march=znver2 |-march=znver2 |-fno-vect-cost-model|-fno-vect-cost-model since ||r14-6822-g01f4251b8775c8 CC||tnfchris at gcc dot gnu.org --- Comment #3 from Sam James --- r14-6822-g01f4251b8775c8 so far, isolating it is a pain because sometimes llvm-tblgen will segfault during the build (it's built-and-then-run to generate machine descriptions).
[Bug libgcc/114397] wrong code with _BitInt() division at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114397 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-03-20 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 57749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57749&action=edit gcc14-pr114397.patch Untested fix.
[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #66 from Martin Jambor --- Created attachment 57750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57750&action=edit Patch comparing jump functions I'm testing this patch. (Not sure how to best check that it does not inadvertently pessimize ICF too much, except for ICF testcases.)
[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #67 from Jakub Jelinek --- (In reply to Martin Jambor from comment #66) > Created attachment 57750 [details] > Patch comparing jump functions > > I'm testing this patch. (Not sure how to best check that it does not > inadvertently pessimize ICF too much, except for ICF testcases.) Bet modify the patch slightly (for testing only), so instead of those 3 return_false_with_msg it would just set some flag somewhere that the pair is not ICF optimizable, then after the early return false in sem_function::merge check that flag and log into some /tmp/ file using appending if the ICF merge would be done and the flag wasn't set, or if the ICF merge wouldn't be done (and in that case return false too), bootstrap/regtest with such patch, plus build a few other packages (firefox, libreoffice) and then get statistics from the log file on what percentage of ICF folding it now prevents.
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #2 from Thorsten Glaser --- Sure? bug 110934 was about =all and using =used fixed the ICE back then. Now it ICEs in both.
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 --- Comment #3 from Andrew Pinski --- (In reply to Thorsten Glaser from comment #2) > Sure? bug 110934 was about =all and using =used fixed the ICE back then. Now > it ICEs in both. Including on the trunk of GCC?
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 --- Comment #4 from Andrew Pinski --- (In reply to Thorsten Glaser from comment #2) > Sure? bug 110934 was about =all and using =used fixed the ICE back then. Now > it ICEs in both. Yes it is a dup because it is about the FP registers in the reduced testcase there is a double type which is used and =used will ICE due to the FP register being used and needing to be zero'ed.
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 --- Comment #5 from Andrew Pinski --- Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934#c11 .
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 --- Comment #6 from Thorsten Glaser --- Oh okay. I have no easy way to check the trunk; gcc-snapshot_1:20240117-1 failed to build (due to an ICE in libgo). In about two days, gcc-14_14-20240315-1 should be built, which I can check then, if that helps (I’m not sure if the fix was before gcc-14 was branched off).
[Bug target/114358] ICE in change_address_1, at emit-rtl.cc:2287 on m68k-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #7 from Sam James --- (It's not branched yet.)
[Bug middle-end/110316] [11/12/13/14 Regression] g++.dg/ext/timevar1.C and timevar2.C fail erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110316 --- Comment #6 from seurer at gcc dot gnu.org --- Was this only fixed for trunk? I started seeing it for gcc 13: g:5b928badac560ad48e0e9fc480096ff396d9d9c6, r13-8468-g5b928badac560a make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/ext/timevar1.C" FAIL: g++.dg/ext/timevar1.C -std=gnu++98 (internal compiler error: in validate_phases, at timevar.cc:626) FAIL: g++.dg/ext/timevar1.C -std=gnu++98 (test for excess errors) # of expected passes7 # of unexpected failures2
[Bug target/114407] Typo 'enabing' in loongarch-opts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114407 --- Comment #1 from GCC Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:806621dc14f893476dd6f2a9ae5cf773f3b0951b commit r14-9582-g806621dc14f893476dd6f2a9ae5cf773f3b0951b Author: Xi Ruoyao Date: Thu Mar 21 04:01:17 2024 +0800 LoongArch: Fix a typo [PR 114407] gcc/ChangeLog: PR target/114407 * config/loongarch/loongarch-opts.cc (loongarch_config_target): Fix typo in diagnostic message, enabing -> enabling.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Uroš Bizjak changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #10 from Uroš Bizjak ---
Huh, is this really fixed?
--cut here--
extern int __seg_gs m;
int foo (void)
{
return m;
}
extern __thread int n;
int bar (void)
{
return n;
}
extern int o;
int baz (void)
{
return o;
}
--cut here--
gcc -O2 -fsanitize=address:
foo:
.LASANPC0:
.LFB0:
.cfi_startproc
movl$m, %eax
movq%rax, %rdx
andl$7, %eax
shrq$3, %rdx
addl$3, %eax
movzbl 2147450880(%rdx), %edx
cmpb%dl, %al
jl .L2
testb %dl, %dl
jne .L13
.L2:
movl%gs:m(%rip), %eax
ret
.L13:
pushq %rax
.cfi_def_cfa_offset 16
movl$m, %edi
call__asan_report_load4
.cfi_endproc
.LFE0:
.size foo, .-foo
.p2align 4
.globl bar
.type bar, @function
The memory access is still annotated with asan code.
I did test patched gcc by building a kernel with named address spaces, but I'm
not sure I did it correctly anymore - I was not able to boot recent -tip with
KASAN and enabled named address spaces.
[Bug target/114407] Typo 'enabing' in loongarch-opts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114407 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- Fixed, thanks for report!
[Bug middle-end/110316] [11/12/13/14 Regression] g++.dg/ext/timevar1.C and timevar2.C fail erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110316 --- Comment #7 from Andrew Pinski --- (In reply to seurer from comment #6) > Was this only fixed for trunk? I started seeing it for gcc 13: Yes it was only fixed on the trunk. The ICE only happens when -ftime-report is used which most folks won't run into the issue and it only happens when there is a short time spent in many of the passes so it won't show up when folks try to use -ftime-report to see where the time is mostly spent. So backporting seems not high priority except to have a clean testsuite results.
[Bug c++/114409] New: ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Bug ID: 114409
Summary: ICE after adding novector pragmas (internal compiler
error: in tsubst_expr, at cp/pt.cc:21794)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 57751
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57751&action=edit
EarlyCSE.cpp.ii.xz
While working on PR114403, I was adding novector pragmas and ended up hitting
an ICE.
```
$ g++ -c
/home/sam/data/build/llvm-project-test/lib/Transforms/Scalar/CMakeFiles/LLVMScalarOpts.dir/EarlyCSE.cpp.ii
In file included from
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:18:
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h: In
instantiation of ‘llvm::ScopedHashTableScope::~ScopedHashTableScope() [with K = {anonymous}::SimpleValue; V =
llvm::Value*; KInfo = llvm::DenseMapInfo<{anonymous}::SimpleValue>; AllocatorTy
= llvm::RecyclingAllocator,
llvm::ScopedHashTableVal<{anonymous}::SimpleValue, llvm::Value*> >]’:
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:671:9:
required from here
671 | : Scope(AvailableValues), LoadScope(AvailableLoads),
| ^~
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:241:36:
internal compiler error: in tsubst_expr, at cp/pt.cc:21794
241 | while (ScopedHashTableVal *ThisEntry = LastValInScope) {
|^
0x55963b55a154 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:21794
0x55963cdda158 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:20637
0x55963b55a4ff tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:21776
0x55963d07cfa1 tsubst_stmt
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:19438
0x55963d07dbe9 tsubst_stmt
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:18676
0x55963d07cfe3 tsubst_stmt
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:18398
0x55963d07cea6 tsubst_stmt
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:18771
0x55963d07cfe3 tsubst_stmt
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:18398
0x55963d07cea6 tsubst_stmt
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:18771
0x55963d3347e8 instantiate_body
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:27064
0x55963cf46498 instantiate_decl(tree_node*, bool, bool)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:27349
0x55963ca8a8c1 instantiate_pending_templates(int)
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/pt.cc:27425
0x55963ca7f13a c_parse_final_cleanups()
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/cp/decl2.cc:5151
0x55963d25b647 c_common_parse_file()
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/c-family/c-opts.cc:1329
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/114409] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409 --- Comment #1 from Sam James --- If you can think of a workaround, please let me know, as unfortunately this loop is the one where the assert in the other bug gets hit :(
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:811145b10ff30608bb5ea459ea277219ada4f13d commit r12-10286-g811145b10ff30608bb5ea459ea277219ada4f13d Author: Harald Anlauf Date: Mon Mar 18 19:36:59 2024 +0100 Fortran: error recovery in frontend optimization [PR103715] gcc/fortran/ChangeLog: PR fortran/103715 * frontend-passes.cc (check_externals_expr): Prevent invalid read in case of mismatch of external subroutine with function. gcc/testsuite/ChangeLog: PR fortran/103715 * gfortran.dg/pr103715.f90: New test. (cherry picked from commit 3be2b8f475f22c531d6cef1b041c0573b3ea5133)
[Bug c++/114409] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409 --- Comment #2 from Andrew Pinski --- Just an FYI, using unroll instead of novect also ICEs. Let me reduce this and see if it is a regression.
[Bug c++/114409] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #3 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> If you can think of a workaround, please let me know, as unfortunately this
> loop is the one where the assert in the other bug gets hit :(
An easy workaround is to add:
asm("":::"memory");
Right after the opening `{`.
But that might be too much of a hammer in some cases ...
[Bug c++/114409] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Sam James from comment #1)
> > If you can think of a workaround, please let me know, as unfortunately this
> > loop is the one where the assert in the other bug gets hit :(
>
> An easy workaround is to add:
> asm("":::"memory");
>
> Right after the opening `{`.
> But that might be too much of a hammer in some cases ...
Even a simple `__builtin_printf("");` added to the loop might avoid the
vectorization to figure out where the wrong code happens.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #4 from Sam James --- Created attachment 57752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57752&action=edit EarlyCSE.cpp.ii.xz The bad object seems to be EarlyCSE.cpp.o. Building it with -O0 makes things work.
[Bug c++/114409] ICE after adding novector pragmas (internal compiler error: in tsubst_expr, at cp/pt.cc:21794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409 --- Comment #5 from Sam James --- Thanks, I'll play with those...
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 --- Comment #11 from GCC Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7294f1a7aa457fe24d11270f06fd15c2b3ffd4ab commit r11-11287-g7294f1a7aa457fe24d11270f06fd15c2b3ffd4ab Author: Harald Anlauf Date: Mon Mar 18 19:36:59 2024 +0100 Fortran: error recovery in frontend optimization [PR103715] gcc/fortran/ChangeLog: PR fortran/103715 * frontend-passes.c (check_externals_expr): Prevent invalid read in case of mismatch of external subroutine with function. gcc/testsuite/ChangeLog: PR fortran/103715 * gfortran.dg/pr103715.f90: New test. (cherry picked from commit 3be2b8f475f22c531d6cef1b041c0573b3ea5133)
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to open branches. Closing.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #11 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #10)
> Huh, is this really fixed?
IMO, this patch is also needed:
--cut here--
diff --git a/gcc/asan.cc b/gcc/asan.cc
index cfe83106460..54dcc3a38db 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -2764,7 +2764,9 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
&& poly_int_tree_p (DECL_SIZE (inner), &decl_size)
&& known_subrange_p (bitpos, bitsize, 0, decl_size))
{
- if (VAR_P (inner) && DECL_THREAD_LOCAL_P (inner))
+ if (VAR_P (inner)
+ && (DECL_THREAD_LOCAL_P (inner)
+ || !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (inner)
return;
/* If we're not sanitizing globals and we can tell statically that this
access is inside a global variable, then there's no point adding
--cut here--
But unfortunately, it doesn't result in bootable kernel.
[Bug fortran/24546] [meta-bug] gfortran debugging problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546 Bug 24546 depends on bug 49565, which changed state. Bug 49565 Summary: character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- After reading this ancient thread, I don't see anything left to do. Closing.
[Bug fortran/94377] [PDT] ICE when deallocating a parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2020-06-09 00:00:00 |2024-3-20 Keywords||ice-on-valid-code Summary|Won't compile when |[PDT] ICE when deallocating |deallocating a |a parameterized derived |parameterized derived type |type --- Comment #6 from anlauf at gcc dot gnu.org --- Confirmed. Intel and NAG compile the code.
[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77517 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #9) > It appears that all testcases in this PR give more or less meaningful > error messages for >= 9.5.0, and error recovery is clean under valgrind. > > I think this one can be closed. Finally closing.
[Bug analyzer/109251] [13/14 Regression] -Wanalyzer-deref-before-check false positives seen in Linux kernel due to check in macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109251 --- Comment #1 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:9093f275e0a3430e4517e782e7f5419d403113f7 commit r14-9586-g9093f275e0a3430e4517e782e7f5419d403113f7 Author: David Malcolm Date: Wed Mar 20 18:33:11 2024 -0400 analyzer: fix -Wanalyzer-deref-before-check false positive seen in loop header macro [PR109251] gcc/analyzer/ChangeLog: PR analyzer/109251 * sm-malloc.cc (deref_before_check::emit): Reject cases where the check is in a loop header within a macro expansion. (deref_before_check::loop_header_p): New. gcc/testsuite/ChangeLog: PR analyzer/109251 * c-c++-common/analyzer/deref-before-check-pr109251-1.c: New test. * c-c++-common/analyzer/deref-before-check-pr109251-2.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/109251] [13 Regression] -Wanalyzer-deref-before-check false positives seen in Linux kernel due to check in macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109251 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Summary|[13/14 Regression] |[13 Regression] |-Wanalyzer-deref-before-che |-Wanalyzer-deref-before-che |ck false positives seen in |ck false positives seen in |Linux kernel due to check |Linux kernel due to check |in macros |in macros --- Comment #2 from David Malcolm --- Should be fixed for GCC 14 by the above patch. Keeping open to track backporting to GCC 13.
[Bug ada/114398] [13/14 regression] Storage_Error with 'Access of function returning limited type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114398 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|Unexpected storage error in |[13/14 regression] |return statement that |Storage_Error with 'Access |should return a limited |of function returning |controlled type.|limited type CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2024-03-20 --- Comment #1 from Eric Botcazou --- This does not compile on the mainline: eric@localhost:~/Downloads> ~/install/gcc/bin/gcc -c reproducer.adb +===GNAT BUG DETECTED==+ | 14.0.1 20240311 (experimental) [master 1d193fb3484] (x86_64-suse-linux) | | Assert_Failure exp_attr.adb:2411 | | Error detected at reproducer.adb:74:13 | | Compiling reproducer.adb pragma Assert (Extra_Formals_Match_OK (E => Entity (Pref), Ref_E => Btyp_DDT));
