[Bug c++/113332] [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Patrick Palka changed: What|Removed |Added Last reconfirmed||2024-01-11 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105637 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Patrick Palka --- Started with r13-984-g44a5bd6d933d86
[Bug c++/86689] [11/12/13/14 Regression] Some combination of SFINAE, overloading, and type deduction showing version inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86689 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105481 --- Comment #5 from Patrick Palka --- Looks like this is fixed on trunk and the 13/12 release branches by the fix for PR105481 r13-6853-g4e2cdb1ddb5f6a.
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Tamar Christina --- Fixed, sorry for the breakage.
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 --- Comment #4 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:da1e651e9c00b9c6100b2ea915631eba0e0d07ba commit r14-7142-gda1e651e9c00b9c6100b2ea915631eba0e0d07ba Author: Tamar Christina Date: Thu Jan 11 14:44:18 2024 + testsuite: remove -save-temps from many tests [PR113319] This removes -save-temps from the tests I've introduced to fix the LTO mismatches. gcc/testsuite/ChangeLog: PR testsuite/113319 * gcc.dg/bic-bitmask-13.c: Remove -save-temps. * gcc.dg/bic-bitmask-14.c: Likewise. * gcc.dg/bic-bitmask-15.c: Likewise. * gcc.dg/bic-bitmask-16.c: Likewise. * gcc.dg/bic-bitmask-17.c: Likewise. * gcc.dg/bic-bitmask-18.c: Likewise. * gcc.dg/bic-bitmask-19.c: Likewise. * gcc.dg/bic-bitmask-20.c: Likewise. * gcc.dg/bic-bitmask-21.c: Likewise. * gcc.dg/bic-bitmask-22.c: Likewise. * gcc.dg/bic-bitmask-7.c: Likewise. * gcc.dg/vect/vect-early-break-run_1.c: Likewise. * gcc.dg/vect/vect-early-break-run_10.c: Likewise. * gcc.dg/vect/vect-early-break-run_2.c: Likewise. * gcc.dg/vect/vect-early-break-run_3.c: Likewise. * gcc.dg/vect/vect-early-break-run_4.c: Likewise. * gcc.dg/vect/vect-early-break-run_5.c: Likewise. * gcc.dg/vect/vect-early-break-run_6.c: Likewise. * gcc.dg/vect/vect-early-break-run_7.c: Likewise. * gcc.dg/vect/vect-early-break-run_8.c: Likewise. * gcc.dg/vect/vect-early-break-run_9.c: Likewise.
[Bug rtl-optimization/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 --- Comment #16 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:a729b6e002fe76208f33fdcdee49d6a310a1940e commit r14-7141-ga729b6e002fe76208f33fdcdee49d6a310a1940e Author: Vladimir N. Makarov Date: Thu Jan 11 08:46:26 2024 -0500 [PR112918][LRA]: Fixing IRA ICE on m68k Some GCC tests on m68K port of LRA is failed on `maximum number of generated reload insns per insn achieved`. The problem is in that for subreg reload LRA can not narrow reg class more from ALL_REGS to GENERAL_REGS and then to data regs or address regs. The patch permits narrowing reg class from reload insns if this results in successful matching of reg operand. This is the second version of the patch to fix the PR. This version adds matching with and without narrowing reg class and preferring match without narrowing classes. gcc/ChangeLog: PR rtl-optimization/112918 * lra-constraints.cc (SMALL_REGISTER_CLASS_P): Move before in_class_p. (in_class_p): Restrict condition for narrowing class in case of allow_all_reload_class_changes_p. (process_alt_operands): Try to match operand without and with narrowing reg class. Discourage narrowing the class. Finish insn matching only if there is no class narrowing. (curr_insn_transform): Pass true to in_class_p for reg operand win.
[Bug tree-optimization/113330] ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113330 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-01-11 --- Comment #2 from Jakub Jelinek --- Created attachment 57044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57044=edit gcc14-pr113330.patch Untested fix.
[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 commit r14-7139-g897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 Author: Richard Biener Date: Thu Jan 11 12:02:43 2024 +0100 tree-optimization/113126 - vector extension compare optimization The following makes sure the resulting boolean type is the same when eliding a float extension. PR tree-optimization/113126 * match.pd ((double)float CMP (double)float -> float CMP float): Make sure the boolean type is the same. * fold-const.cc (fold_binary_loc): Likewise. * gcc.dg/torture/pr113126.c: New testcase.
[Bug tree-optimization/112505] [11/12/13/14 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104 since r10-4076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ec345df53556ec581590347f71c3d9ff3cdbca76 commit r14-7140-gec345df53556ec581590347f71c3d9ff3cdbca76 Author: Richard Biener Date: Thu Jan 11 14:00:33 2024 +0100 tree-optimization/112505 - bit-precision induction vectorization Vectorization of bit-precision inductions isn't implemented but we don't check this, instead we ICE during transform. PR tree-optimization/112505 * tree-vect-loop.cc (vectorizable_induction): Reject bit-precision induction. * gcc.dg/vect/pr112505.c: New testcase.
[Bug tree-optimization/113330] ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113330 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is the invalid build_bitint_type (65536, 0) case I was talking about in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html but not really sure where it should punt on that.
[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112280 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-01-11 --- Comment #9 from Richard Biener --- I have a patch.
[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324 --- Comment #2 from Mikael Pettersson --- I can reproduce with gcc-10.5.0 hosted on x86_64-pc-linux-gnu targeting vax-netbsdelf, but not with gcc-11.4.0. 12.3.0, or 13.2.0.
[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #2 from jules at gcc dot gnu.org --- I haven't been able to reproduce this with our local testing infrastructure on the powerpc64le machine available to me (i.e., the test works for me there). I'd be a bit surprised about a machine dependence at this early stage in parsing, but here we go! Let me know if there's any other information that might help track this down.
[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769 Bug 110769 depends on bug 110641, which changed state. Bug 110641 Summary: [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2230-g7e904d6c7f2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2230-g7e904d6c7f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed by r14-7138-g05e8ef2a05b477
[Bug tree-optimization/110769] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Richard Biener --- Fixed by r14-7138-g05e8ef2a05b477
[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068 since r14-2675-gef28aadad6e5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111043 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed by r14-7138-g05e8ef2a05b477
[Bug tree-optimization/112636] [14 Regression] ICE on valid code at -O1 (but not at -O{0,s,2,3}) with "-ftree-vectorize": in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112636 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/112636] [14 Regression] ICE on valid code at -O1 (but not at -O{0,s,2,3}) with "-ftree-vectorize": in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112636 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:05e8ef2a05b477589cae25af3311bad0f68a90fe commit r14-7138-g05e8ef2a05b477589cae25af3311bad0f68a90fe Author: Richard Biener Date: Thu Jan 11 13:35:51 2024 +0100 tree-optimization/112636 - estimate niters before header copying The following avoids a mismatch between an early query for maximum number of iterations of a loop and a late one when through ranger we'd get iterations estimated. Instead make sure we compute niters before querying the iteration bound. PR tree-optimization/112636 * tree-ssa-loop-ch.cc (ch_base::copy_headers): Call estimate_numbers_of_iterations before querying get_max_loop_iterations_int. (pass_ch::execute): Initialize SCEV and loops appropriately. * gcc.dg/pr112636.c: New testcase.
[Bug tree-optimization/113323] ICE: tree check: expected none of vector_type, have vector_type in bitint_precision_kind, at gimple-lower-bitint.cc:131 with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113323 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-11 --- Comment #1 from Jakub Jelinek --- Created attachment 57043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57043=edit gcc14-pr113323.patch Untested fix.
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #9 from Jonathan Wakely ---
I'm reopening this because the fix changes the behaviour of some code:
https://cplusplus.github.io/LWG/issue4014
As noted there, std::ranlux48_base(UINT_MAX+1LL)() changed behaviour.
Originally that yielded 22575453646312 but after the commits above it yields
23223501020940
This is what I proposed for 4014 and restores the original behaviour:
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -541,8 +541,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
subtract_with_carry_engine<_UIntType, __w, __s, __r>::
seed(result_type __value)
{
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 3809. Is std::subtract_with_carry_engine supposed to work?
+ // 4014. LWG 3809 changes behavior of some existing code
+ if (__value == 0u)
+ __value = default_seed;
+ else
+ __value %= 2147483563u;
+
std::linear_congruential_engine
- __lcg(__value == 0u ? default_seed : __value);
+ __lcg(__value);
const size_t __n = (__w + 31) / 32;
[Bug tree-optimization/112505] [11/12/13/14 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104 since r10-4076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Richard Biener --- I have a patch.
[Bug tree-optimization/113316] during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) at -O with uninitialized _BitInt() function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113316 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-01-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 57042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57042=edit gcc14-pr113316.patch Untested fix.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #14 from Jan Hubicka --- > I think the issue might be that whoever is creating > __static_initialization_and_destruction_0 fails to honor the active > target pragma. Which means back to my suggestion to have multiple ones > when different target options are on the individual CTORs and any of them > have always-inline (with always-inline we can't rely on an out-of-line copy > to exist). If I remember right, __static_initialization_and_destruction_0 call all static constructors of priority 0. So it has really no active pragma since it may change across translation unit. We also have similar code in IPA where we collect constructors across whole program. Motivation was to get them inlined and obtain better code locality. Back then Firefox had iostram constructor in every object file and those ctors made whole text segment to be loaded on demand during startup. Probably correct solution would be to group construtor into groups by compatible optimization/target pgramas in the inliner's definition. A quick hack would be to generate wrapper calls which will "eat" the always inline...
[Bug c++/113332] [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 --- Comment #1 from Sam James --- Created attachment 57041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57041=edit invalid.ii Here's an invalid reduced version. Re-reducing...
[Bug tree-optimization/112636] [14 Regression] ICE on valid code at -O1 (but not at -O{0,s,2,3}) with "-ftree-vectorize": in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112636
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Richard Biener ---
The issue is that should_duplicate_loop_header_p we call after
basic_block header = loop->header;
if (!get_max_loop_iterations_int (loop))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Loop %d never loops.\n", loop->num);
scale_loop_profile (loop, profile_probability::always (), 0);
loops_to_unloop.safe_push (loop);
loops_to_unloop_nunroll.safe_push (0);
continue;
ends up calling estimate_numbers_of_iterations () only then actually
updating the upper bound we check above. It does so hidden via
#0 estimate_numbers_of_iterations (loop=0x7700e4b0)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-niter.cc:4806
#1 0x019434ef in loop_exits_before_overflow (
base=, step=,
at_stmt=, loop=0x7700e4b0)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-niter.cc:5259
#2 0x019440b0 in scev_probably_wraps_p (var=,
base=, step=,
at_stmt=, loop=0x7700e4b0,
use_overflow_semantics=true)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-niter.cc:5511
#3 0x01bb97ea in get_scev_info (r=...,
name=, stmt=,
l=0x7700e4b0, init=@0x7fffa898: ,
step=@0x7fffa890: ,
dir=@0x7fffa88c: EV_DIR_DECREASES)
at /space/rguenther/src/gcc/gcc/vr-values.cc:204
#4 0x01bb9d6d in range_of_var_in_loop (v=...,
name=, l=0x7700e4b0,
stmt=, query=0x4961550)
at /space/rguenther/src/gcc/gcc/vr-values.cc:271
#5 0x02edf824 in fold_using_range::range_of_ssa_name_with_loop_info (
this=0x7fffb46f, r=..., name=,
...
#22 0x018f3f77 in should_duplicate_loop_header_p (
header=, loop=0x7700e4b0,
ranger=0x4961550, limit=0x7fffd88c, invariant_exits=0x47e60f0,
static_exits=0x4961040)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-ch.cc:251
#23 0x018f59d7 in (anonymous namespace)::ch_base::copy_headers (
this=0x47f2a30, fun=0x771e2000)
at /space/rguenther/src/gcc/gcc/tree-ssa-loop-ch.cc:831
The best is to analyze niters for the loop we try to process.
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 Ken Matsui changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.5 --- Comment #7 from Ken Matsui --- Fixed in 11.5, 12.4, 13.3. Thank you for filing this issue, Davide!
[Bug tree-optimization/113334] New: wrong code with _BitInt() shift at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334 Bug ID: 113334 Summary: wrong code with _BitInt() shift at -O0 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-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 57040 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57040=edit reduced testcase I cannot tell for sure that the code is defined, but I don't see anything breaking pre-C23 rules, if applied to _BitInt(). Output: $ x86_64-pc-linux-gnu-gcc testcase.c $ ./a.out Aborted It works fine on -O1 and above. $ 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-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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 --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20240111 (experimental) (GCC)
[Bug c/113315] during GIMPLE pass: bitintlower0 ICE: in lower_mergeable_stmt, at gimple-lower-bitint.cc:2310 with _BitInt() used as array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113315 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-11 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 57039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57039=edit gcc14-pr113315.patch Untested fix.
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #3 from Richard Biener --- We're endlessly inlining during IPA. Honza, please have a look.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 Jonathan Wakely changed: What|Removed |Added Depends on||113318 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > I remain confused about how to implement this. We could use > newlocale(loc.name()) to try to open a C locale from the C++ locale's name, > and if that works use nl_langinfo_l to get the locale's encoding, P1185 (PR 113318) provides a standard API for doing that. So it probably makes sense to implement that part of P1185 before doing P2419. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 [Bug 113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Ken Matsui : https://gcc.gnu.org/g:6c4882dd9453d096429cfb4652f25915a931e155 commit r11-11188-g6c4882dd9453d096429cfb4652f25915a931e155 Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely (cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Ken Matsui : https://gcc.gnu.org/g:da19967df3ad5d123888ef24b4fd84be047df226 commit r12-10089-gda19967df3ad5d123888ef24b4fd84be047df226 Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely (cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Ken Matsui : https://gcc.gnu.org/g:3e51890ef351e7fb9e836c6a48f20ca97294dc16 commit r13-8209-g3e51890ef351e7fb9e836c6a48f20ca97294dc16 Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely (cherry picked from commit df147e2ee7199d33d66959c6509ce9c21072077f)
[Bug libstdc++/113250] std::filesystem::equivalent("", "/") should throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 --- Comment #3 from GCC Commits --- The master branch has been updated by Ken Matsui : https://gcc.gnu.org/g:df147e2ee7199d33d66959c6509ce9c21072077f commit r14-7135-gdf147e2ee7199d33d66959c6509ce9c21072077f Author: Ken Matsui Date: Wed Jan 10 22:08:07 2024 -0800 libstdc++: Fix error handling in filesystem::equivalent [PR113250] This patch made std::filesystem::equivalent correctly throw an exception when either path does not exist as per [fs.op.equivalent]/4. PR libstdc++/113250 libstdc++-v3/ChangeLog: * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&. * src/filesystem/ops.cc (fs::equivalent): Likewise. * testsuite/27_io/filesystem/operations/equivalent.cc: Handle error codes. * testsuite/experimental/filesystem/operations/equivalent.cc: Likewise. Signed-off-by: Ken Matsui Reviewed-by: Jonathan Wakely
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Target Milestone|--- |14.0
[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126 Richard Biener changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Richard Biener --- diff --git a/gcc/match.pd b/gcc/match.pd index 876a9d1c06e..abbd03742f9 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -6792,11 +6792,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) && exact_real_truncate (TYPE_MODE (double_type_node), )) type1 = double_type_node; } - tree newtype -= (element_precision (TREE_TYPE (@00)) > element_precision (type1) - ? TREE_TYPE (@00) : type1); + tree newtype += (element_precision (TREE_TYPE (@00)) > element_precision (type1) + ? TREE_TYPE (@00) : type1); } - (if (element_precision (TREE_TYPE (@0)) > element_precision (newtype)) + (if (element_precision (TREE_TYPE (@0)) > element_precision (newtype) + && is_truth_type_for (newtype, type)) (cmp (convert:newtype @00) (convert:newtype @10 as I thought with AVX512VL we can handle this, but for V2SFmode we get V2SImode as mask_mode. And changing the test to V4SF/V4DFmode reveals that we don't use float-extend (I'd have to trace vector lowering and forwprop). There might be an opportunity to improve what we do for convertvector. But it fixes the testcase.
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #7 from GCC Commits ---
The master branch has been updated by LuluCheng :
https://gcc.gnu.org/g:ea2a9c76a1dcffbbec6e53655bef9236d3a8e691
commit r14-7134-gea2a9c76a1dcffbbec6e53655bef9236d3a8e691
Author: Yang Yujie
Date: Thu Jan 11 09:07:10 2024 +0800
LoongArch: Implement option save/restore
LTO option streaming and target attributes both require per-function
target configuration, which is achieved via option save/restore.
We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
context in addition to other automatically maintained option states
(via the "Save" option property in the .opt files).
Tested on loongarch64-linux-gnu without regression.
PR target/113233
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark options with
the "Save" property.
* config/loongarch/loongarch.opt: Same.
* config/loongarch/loongarch-opts.cc: Refresh -mcmodel= state
according to la_target.
* config/loongarch/loongarch.cc: Implement TARGET_OPTION_{SAVE,
RESTORE} for the la_target structure; Rename option conditions
to have the same "la_" prefix.
* config/loongarch/loongarch.h: Same.
[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 --- Comment #1 from Richard Biener --- These are exception handling region labels, possibly nvptx has no way to do EH.
[Bug c++/113332] [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.4
[Bug libstdc++/113320] libstdc++ accepts std::format(std::move(runtime_fmt), 42);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I implemented the R0 paper, not the final spec. I already have a patch to fix this.
[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Alex Coplan --- Should be fixed, thanks for the report, and sorry for the breakage.
[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 --- Comment #13 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:5400778f69d19a94017561c7de02510d9c0899e6 commit r14-7132-g5400778f69d19a94017561c7de02510d9c0899e6 Author: Alex Coplan Date: Thu Jan 11 10:16:24 2024 + aarch64: Fix dwarf2cfi ICEs due to recent CFI note changes [PR113077] In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes attached to callee saves (in aarch64_save_callee_saves). That patch changed the ldp/stp representation to use unspecs instead of PARALLEL moves. This meant that we needed to attach CFI notes to all frame-related pair saves such that dwarf2cfi could still emit the appropriate CFI (it cannot interpret the unspecs directly). The patch also attached REG_CFA_OFFSET notes to individual saves so that the ldp/stp pass could easily preserve them when forming stps. In that change I chose to use REG_CFA_OFFSET, but as the PR shows, that choice was problematic in that REG_CFA_OFFSET requires the attached store to be expressed in terms of the current CFA register at all times. This means that even scheduling of frame-related insns can break this invariant, leading to ICEs in dwarf2cfi. The old behaviour (before that change) allowed dwarf2cfi to interpret the RTL directly for sp-relative saves. This change restores that behaviour by using REG_FRAME_RELATED_EXPR instead of REG_CFA_OFFSET. REG_FRAME_RELATED_EXPR effectively just gives a different pattern for dwarf2cfi to look at instead of the main insn pattern. That allows us to attach the old-style PARALLEL move representation in a REG_FRAME_RELATED_EXPR note and means we are free to always express the save addresses in terms of the stack pointer. Since the ldp/stp fusion pass can combine frame-related stores, this patch also updates it to preserve REG_FRAME_RELATED_EXPR notes, and additionally gives it the ability to synthesize those notes when combining sp-relative saves into an stp (the latter always needs a note due to the unspec representation, the former does not). gcc/ChangeLog: PR target/113077 * config/aarch64/aarch64-ldp-fusion.cc (filter_notes): Add fr_expr param to extract REG_FRAME_RELATED_EXPR notes. (combine_reg_notes): Handle REG_FRAME_RELATED_EXPR notes, and synthesize these if needed. Update caller ... (ldp_bb_info::fuse_pair): ... here. (ldp_bb_info::try_fuse_pair): Punt if either insn has writeback and either insn is frame-related. (find_trailing_add): Punt on frame-related insns. * config/aarch64/aarch64.cc (aarch64_save_callee_saves): Use REG_FRAME_RELATED_EXPR instead of REG_CFA_OFFSET. gcc/testsuite/ChangeLog: PR target/113077 * gcc.target/aarch64/pr113077.c: New test.
[Bug analyzer/113333] New: analyzer: False positives with calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Bug ID: 11
Summary: analyzer: False positives with calloc()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: buczek at molgen dot mpg.de
Target Milestone: ---
Analyzer assumen that a pointer allocated by calloc() can be != NULL.
** Code:
#include
char **f(void) {
char **vec = calloc(1, sizeof(char *));
if (vec)
for (char **p=vec ; *p ; p++);
return vec;
}
** Result:
: In function 'f':
:5:29: warning: heap-based buffer over-read [CWE-126]
[-Wanalyzer-out-of-bounds]
5 | for (char **p=vec ; *p ; p++);
| ^~
'f': events 1-6
|
|3 | char **vec = calloc(1, sizeof(char *));
| | ^
| | |
| | (1) capacity: 8 bytes
|4 | if (vec)
| |~
| ||
| |(2) following 'true' branch (when 'vec' is non-NULL)...
|5 | for (char **p=vec ; *p ; p++);
| | ~ ~~ ~~~
| | | | |
| | | | (5) ...to here
| | | (4) following 'true' branch...
| | | (6) out-of-bounds read from byte 8
till byte 15 but region ends at byte 8
| | (3) ...to here
|
:5:29: note: read of 8 bytes from after the end of the region
5 | for (char **p=vec ; *p ; p++);
| ^~
:5:29: warning: use of uninitialized value '*p' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
'f': events 1-6
|
|3 | char **vec = calloc(1, sizeof(char *));
| | ^
| | |
| | (1) region created on heap here
|4 | if (vec)
| |~
| ||
| |(2) following 'true' branch (when 'vec' is non-NULL)...
|5 | for (char **p=vec ; *p ; p++);
| | ~ ~~ ~~~
| | | | |
| | | | (5) ...to here
| | | (4) following 'true' branch...
| | | (6) use of uninitialized value '*p'
here
| | (3) ...to here
|
Compiler returned: 0
https://gcc.godbolt.org/z/h6bPeYc3T
[Bug c++/113332] New: [12/13/14 regression] ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332
Bug ID: 113332
Summary: [12/13/14 regression] ICE when building fcitx-5.1.6
Product: gcc
Version: 14.0
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 57038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57038=edit
ibusfrontend.cpp.ii.xz
Originally reported downstream by Toralf Förster at
https://bugs.gentoo.org/921765 with GCC 13 (13.2.1 20231216) but I can
reproduce it with 14 (14.0.0 20240107) too.
```
$ g++ -c ibusfrontend.cpp.ii
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/unique_ptr.h:37,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/memory:78,
from
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/lib/fcitx/../fcitx-utils/dbus/servicewatcher.h:10,
from
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.h:11,
from
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.cpp:8:
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/tuple: In substitution of
‘template, std::allocator > >
>::_TCC::value>::__is_implicitly_default_constructible(),
bool>::type > constexpr
std::tuple, std::allocator > > >::tuple() [with _Dummy = void; typename
std::enable_if, std::allocator > >
>::_TCC::value>::__is_implicitly_default_constructible(),
bool>::type = ]’:
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.cpp:594:0:
recursively required from ‘constexpr
fcitx::dbus::DBusStruct::DBusStruct() [with Args =
{std::vector,
std::allocator >
>}]’
594 | FCITX_OBJECT_VTABLE_PROPERTY(
/var/tmp/portage/app-i18n/fcitx-5.1.6/work/fcitx5-5.1.6/src/frontend/ibusfrontend/ibusfrontend.cpp:594:0:
required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/tuple:763:62: internal
compiler error: in lambda_expr_this_capture, at cp/lambda.cc:825
763 | _TCC<_Dummy>::__is_implicitly_default_constructible(),
| ~~~^~
0x55781543e3c2 lambda_expr_this_capture(tree_node*, int)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/lambda.cc:825
0x5578166f2080 maybe_dummy_object(tree_node*, tree_node**)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/tree.cc:4408
0x5578165d0e8e finish_call_expr(tree_node*, vec**,
bool, bool, int)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/semantics.cc:2968
0x55781678c531 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:20845
0x5578167bc701 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:12693
0x5578167bc701 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:12681
0x5578167bc701 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:13845
0x557816831076 tsubst_aggr_type_1
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:14120
0x557816831076 tsubst_aggr_type
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:14090
0x5578167093ed tsubst(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:1
0x557816a1a5e2 type_unification_real
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:23316
0x557816a18cb7 fn_type_unification(tree_node*, tree_node*, tree_node*,
tree_node* const*, unsigned int, tree_node*, unification_kind_t, int,
conversion**, bool, bool)
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/pt.cc:22390
0x557816a17a82 add_template_candidate_real(z_candidate**, tree_node*,
tree_node*, tree_node*, tree_node*, vec const*,
tree_node*, tree_node*, tree_node*, int, tree_node*, unification_kind_t, bool,
int) [clone .isra.0]
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/call.cc:3631
0x5578165de1b0 add_template_candidate
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/call.cc:3721
0x5578165de1b0 add_candidates
/usr/src/debug/sys-devel/gcc-14.0.0_pre20240107/gcc-14-20240107/gcc/cp/call.cc:6686
0x5578168bf6e1 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
[Bug target/113326] Optimize vector shift with constant delta on shifting-count operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #7 from Feng Xue ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > One more thing:
> > ```
> > vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> > vect_shift_1 = vect_value >> { 4, 5, 6, 7 };
> > vect_shift_2 = vect_value >> { 8, 9, 10, 11 };
> > vect_shift_3 = vect_value >> { 12, 13, 14, 15 };
> > ```
> > vs
> > ```
> > vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> > vect_shift_1 = vect_shift_0 >> { 4, 4, 4, 4 };
> > vect_shift_2 = vect_shift_0 >> { 8, 8, 8, 8 };
> > vect_shift_3 = vect_shift_0 >> { 12, 12, 12, 12 };
> > ```
> >
> > the first has fully independent operations while in the second case, there
> > is one dependent and the are independent operations.
> >
> > On cores which has many vector units the first one might be faster than the
> > second one. So this needs a cost model too.
>
> Note the vectorizer has the shift values dependent as well (across
> iterations),
> we just constant propagate after unrolling here.
>
> Note this is basically asking for "strength-reduction" of expensive
> constants which could be more generally useful and not only for this
> specific shift case. Consider the same example but with an add instead
> of a shift for example, the same exact set of constants will appear.
It is. But only find that vector shift has special treatment to constant
operands based on its numerical pattern. No sure any other operator would be.
BTW, here is a scalar-version strength-reduction for shift, like:
int a = value >> n;
int b = value >> (n + 6);
==>
int a = value >> n;
int b = a >> 6; // (n + 6) is not needed
But this is not covered by current scalar strength-reduction pass.
[Bug target/113331] New: AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 Bug ID: 113331 Summary: AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- Created attachment 57037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57037=edit Test case The attached file fails to compile with AMD GCN offloading on current mainline. It also fails on GCC 13.2.0 as packaged in Debian, so this doesn't appear to be a regression. $ g++ -fopenmp -foffload=amdgcn-amdhsa -save-temps dup-syms.cc -o dup-syms ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:256:1: error: symbol '.LEHB0' is already defined .LEHB0: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:258:1: error: symbol '.LEHE0' is already defined .LEHE0: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:288:1: error: symbol '.LEHB1' is already defined .LEHB1: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:290:1: error: symbol '.LEHE1' is already defined .LEHE1: ^ The test case doesn't trigger with NVPTX offloading, but I don't think that definitely implies that this is something GCN-specific (vs. generically offload-related).
[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 Alex Coplan changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2024-January |il/gcc-patches/2024-January |/642313.html|/642530.html --- Comment #12 from Alex Coplan --- v3 patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642530.html
[Bug tree-optimization/113330] New: ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113330 Bug ID: 113330 Summary: ICE: verify_gimple failed: conversion of register to a different size in 'view_convert_expr' with -O -fstack-check=generic and _BitInt() 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 57036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57036=edit reduced testcase Maybe related to PR113297 Compiler output: $ x86_64-pc-linux-gnu-gcc -O --param=large-stack-frame=131072 -fstack-check=generic --param=sccvn-max-alias-queries-per-access=0 testcase.c testcase.c: In function 'foo': testcase.c:15:1: error: conversion of register to a different size in 'view_convert_expr' 15 | } | ^ VIEW_CONVERT_EXPR<_BitInt(65535)>(SR.6_11); _4 = VIEW_CONVERT_EXPR<_BitInt(65535)>(SR.6_11); during GIMPLE pass: esra testcase.c:15:1: internal compiler error: verify_gimple failed 0x1557dbd verify_gimple_in_cfg(function*, bool, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5666 0x13c7774 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2088 0x13c7cce execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 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-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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 --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7127-20240110200826-g2105c49bbe8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20240111 (experimental) (GCC)
[Bug target/113326] Optimize vector shift with constant delta on shifting-count operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #6 from Richard Biener ---
(In reply to Andrew Pinski from comment #5)
> One more thing:
> ```
> vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> vect_shift_1 = vect_value >> { 4, 5, 6, 7 };
> vect_shift_2 = vect_value >> { 8, 9, 10, 11 };
> vect_shift_3 = vect_value >> { 12, 13, 14, 15 };
> ```
> vs
> ```
> vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
> vect_shift_1 = vect_shift_0 >> { 4, 4, 4, 4 };
> vect_shift_2 = vect_shift_0 >> { 8, 8, 8, 8 };
> vect_shift_3 = vect_shift_0 >> { 12, 12, 12, 12 };
> ```
>
> the first has fully independent operations while in the second case, there
> is one dependent and the are independent operations.
>
> On cores which has many vector units the first one might be faster than the
> second one. So this needs a cost model too.
Note the vectorizer has the shift values dependent as well (across iterations),
we just constant propagate after unrolling here.
Note this is basically asking for "strength-reduction" of expensive
constants which could be more generally useful and not only for this
specific shift case. Consider the same example but with an add instead
of a shift for example, the same exact set of constants will appear.
[Bug libstdc++/106308] Consider using statx(2) for std::filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106308 Ken Matsui changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||ice-on-valid-code Ever confirmed|0 |1 Last reconfirmed||2024-01-11 --- Comment #1 from Richard Biener --- I wonder if you can try newer GCC since 10.5 is no longer maintained?
[Bug middle-end/113322] [14 Regression] internal compiler error: tree check: expected none of vector_type, have vector_type in expand_single_bit_test, at expr.cc:13375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1
[Bug testsuite/113319] Random LTO test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319 Richard Biener changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #3 from Richard Biener --- I'm also doing this and remember running into this once. This is because of the -save-temps use (I asked for them to be removed ...), without -save-temps temporary filenames are used. -save-temps should never be used (IIRC assembler scanning triggers it though)
[Bug analyzer/113329] New: analyzer: False positive analyzer-fd-use-without-check with dup2()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113329
Bug ID: 113329
Summary: analyzer: False positive analyzer-fd-use-without-check
with dup2()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: buczek at molgen dot mpg.de
Target Milestone: ---
Using a closed file descriptor as the second argument of dup2() is a valid
usage. It makes sense, because the implicit close of dup2() doesn't return
close errors to the caller, so an explicit close might be preferred.
** Code:
#include
void f(int oldfd, int newfd) {
close(newfd);
dup2(oldfd, newfd);
}
** Result:
: In function 'f':
:4:5: warning: 'dup2' on possibly invalid file descriptor 'newfd'
[-Wanalyzer-fd-use-without-check]
4 | dup2(oldfd, newfd);
| ^~
'f': events 1-2
|
|3 | close(newfd);
| | ^~~~
| | |
| | (1) closed here
|4 | dup2(oldfd, newfd);
| | ~~
| | |
| | (2) 'newfd' could be invalid
|
Compiler returned: 0
https://gcc.godbolt.org/z/8zac19e15
[Bug analyzer/109839] -Wanalyzer-fd-leak false positive with routine dup2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109839
Donald Buczek changed:
What|Removed |Added
CC||buczek at molgen dot mpg.de
--- Comment #1 from Donald Buczek ---
Correct, dup2() does not allocate a new file descriptor, so the returned file
descriptor can't be leaked.
Reduced test case:
#include
void f(int old, int new) {
int r = dup2(old, new);
}
https://gcc.godbolt.org/z/6sP9v1r5a
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 112740, which changed state. Bug 112740 Summary: [14 Regression] wrong code with vector compare on riscv64 at -O0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Should be fixed now.
[Bug tree-optimization/111003] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2161-g237e83e2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111003 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:96fb3908d9b8e30f8d8355fbb133d25625a0fee9 commit r14-7130-g96fb3908d9b8e30f8d8355fbb133d25625a0fee9 Author: Richard Biener Date: Thu Jan 11 08:52:48 2024 +0100 tree-optimization/111003 - new testcase Testcase for fixed PR. PR tree-optimization/111003 gcc/testsuite/ * gcc.dg/tree-ssa/pr111003.c: New testcase.
[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 --- Comment #14 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e1f2d58a1e2536f13d3f2ea2d7373ae62cec9125 commit r14-7129-ge1f2d58a1e2536f13d3f2ea2d7373ae62cec9125 Author: Richard Biener Date: Wed Jan 10 14:54:10 2024 +0100 middle-end/112740 - vector boolean CTOR expansion issue The optimization to expand uniform boolean vectors by sign-extension works only for dense masks but it failed to check that. PR middle-end/112740 * expr.cc (store_constructor): Check the integer vector mask has a single bit per element before using sign-extension to expand an uniform vector. * gcc.dg/pr112740.c: New testcase.
[Bug ipa/113197] [12/13/14 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug target/113326] Optimize vector shift with constant delta on shifting-count operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #5 from Andrew Pinski ---
One more thing:
```
vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
vect_shift_1 = vect_value >> { 4, 5, 6, 7 };
vect_shift_2 = vect_value >> { 8, 9, 10, 11 };
vect_shift_3 = vect_value >> { 12, 13, 14, 15 };
```
vs
```
vect_shift_0 = vect_value >> { 0, 1, 2, 3 };
vect_shift_1 = vect_shift_0 >> { 4, 4, 4, 4 };
vect_shift_2 = vect_shift_0 >> { 8, 8, 8, 8 };
vect_shift_3 = vect_shift_0 >> { 12, 12, 12, 12 };
```
the first has fully independent operations while in the second case, there is
one dependent and the are independent operations.
On cores which has many vector units the first one might be faster than the
second one. So this needs a cost model too.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 --- Comment #13 from Richard Biener --- I think the issue might be that whoever is creating __static_initialization_and_destruction_0 fails to honor the active target pragma. Which means back to my suggestion to have multiple ones when different target options are on the individual CTORs and any of them have always-inline (with always-inline we can't rely on an out-of-line copy to exist). Yes, for libstdc++ purposes which seems to get more and more "always-inline" it would be good to have a different attribute that would only cause to disregard inline limits and not have "always-inline" semantics. [[inline_without_limits]] or [[inline_no_limits]]
