[Bug libstdc++/112934] excessive code for std::map::erase(key)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-09 Keywords||missed-optimization
[Bug target/112932] [14] RISC-V rv64gcv_zvl256b vector: Incorrect behavior with nested loop array writing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112932 --- Comment #1 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:9363d91956931bb28735bed97035b9ec965c850f commit r14-6354-g9363d91956931bb28735bed97035b9ec965c850f Author: Juzhe-Zhong Date: Sat Dec 9 16:31:53 2023 +0800 RISC-V: Fix VLS mode movmiaslign bug PR112932 let me notice there is a bug of current VLS mode misalign pattern. Adapt it same as VLA mode. Commited as it is obvious fix. PR target/112932 gcc/ChangeLog: * config/riscv/vector.md (movmisalign): Fix VLSmode bugs. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls/misalign-1.c: Ditto. * gcc.target/riscv/rvv/autovec/pr112932.c: New test.
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #7 from Eric Botcazou --- > I must say I have no idea what WORD_REGISTER_OPERATION says about the upper > bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode) > is ZERO_EXTEND (zeros then? Yes. > Then this optimization is ok), or something else? And what it says on REGs. That it contains the result of the operation that was applied to the SUBREG as if it was applied to the entire REG, provided that word_register_operation_p is true. Otherwise, it's undefined.
[Bug target/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 --- Comment #10 from Xi Ruoyao --- For the original test case we get: x16_27 = _26 & 1; data_28 = data_15 >> 1; _29 = crc_18 >> 1; _21 = (short unsigned int) x16_27; _13 = _21 * 40961; and tree_nonzero_bits fails to _21 is either 0 or 1, for some reason.
[Bug target/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 --- Comment #11 from Xi Ruoyao --- > and tree_nonzero_bits fails to _21 is either 0 or 1, for some reason. ^ report
[Bug tree-optimization/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 Xi Ruoyao changed: What|Removed |Added Component|target |tree-optimization Target|loongarch64-*-* | --- Comment #12 from Xi Ruoyao --- This also happens for x86_64, with 13.2: .L2: movl%edi, %edx shrb%dil xorl%eax, %edx shrw%ax andl$1, %edx negl%edx andw$-24575, %dx xorl%edx, %eax subb$1, %cl jne .L2 With trunk: .L2: mov ecx, edi shr dil xor ecx, eax shr ax and ecx, 1 lea edx, [rcx+rcx*4] sal edx, 13 add edx, ecx xor eax, edx sub sil, 1 jne .L2 So this seems not only a target issue. I'll move it back to tree-optimization and open LoongArch cost model issue as a new ticket.
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 Andrew Pinski changed: What|Removed |Added Target||loongarch64-*-* Component|tree-optimization |middle-end --- Comment #13 from Andrew Pinski --- (In reply to Xi Ruoyao from comment #11) > > and tree_nonzero_bits fails to _21 is either 0 or 1, for some reason. > ^ report Oh I see that on aarch64 too ...
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #8 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #7) > > I must say I have no idea what WORD_REGISTER_OPERATION says about the upper > > bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode) > > is ZERO_EXTEND (zeros then? > > Yes. > > > Then this optimization is ok), or something else? And what it says on REGs. > > That it contains the result of the operation that was applied to the SUBREG > as if it was applied to the entire REG, provided that > word_register_operation_p is true. Otherwise, it's undefined. But if we see a REG in there, we don't really know what operation it was. Sure, if the operation is visible, we know it, but say PLUS can be extended either way. Which means punt on this optimization for WORD_REGISTER_OPERATIONS if the outer mode is word_mode, except when sub is a MEM and load_extend_op (inner_mode) == ZERO_EXTEND?
[Bug target/112936] New: LoongArch: Wrong instruction costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Bug ID: 112936
Summary: LoongArch: Wrong instruction costs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
Separated from PR112935 comment 3.
The current loongarch_rtx_cost_data constructor (for default cost model, used
by LA464 and LA664 for now) seems completely wrong. Per my micro-benchmark the
values in reality should be:
loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
: fp_add (COSTS_N_INSNS (5)),
fp_mult_sf (COSTS_N_INSNS (5)),
fp_mult_df (COSTS_N_INSNS (5)),
fp_div_sf (COSTS_N_INSNS (8)),
fp_div_df (COSTS_N_INSNS (8)),
int_mult_si (COSTS_N_INSNS (4)),
int_mult_di (COSTS_N_INSNS (4)),
int_div_si (COSTS_N_INSNS (5)),
int_div_di (COSTS_N_INSNS (5)),
branch_cost (6),
memory_latency (4) {}
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 --- Comment #14 from Xi Ruoyao --- LoongArch cost model issue is now PR112936.
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 --- Comment #15 from Andrew Pinski --- I see what is happening and kinda of see why it is not there ...
[Bug target/112936] LoongArch: Wrong instruction costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2023-12-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Xi Ruoyao --- Self-confirming as the original performance issue is from Jia Jie and the cost model issue was isolated by Andrew.
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #16 from Xi Ruoyao ---
BTW is it possible to get the value range info of (x) and combine (and y, (neg
x)) back to maskeqz in LoongArch backend? It will further improve the
performance. Or maybe expr.cc should invoke a target hook to see if (mul x, y)
should be expanded to (if_then_else x, y, 0) instead when x is in {0, 1}.
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #17 from Andrew Pinski --- So it was r14-1655-g52c92fb3f40050 which caused the issue. It is a correct fix except we sometimes insert a convert and that new ssa name does not have any global range info on it. e.g. _21 = (short unsigned int) x16_27; So instead of: bool bit0_p = tree_nonzero_bits (treeop0) == 1; bool bit1_p = tree_nonzero_bits (treeop1) == 1; We should use gimple_zero_one_valued_p bool gimple_zero_one_valued_p (tree t, tree (*valueize)(tree) ATTRIBUTE_UNUSED) Which will look through one extra convert. Let me fix this.
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=26
--- Comment #18 from Andrew Pinski ---
(In reply to Xi Ruoyao from comment #16)
> BTW is it possible to get the value range info of (x) and combine (and y,
> (neg x)) back to maskeqz in LoongArch backend? It will further improve the
> performance. Or maybe expr.cc should invoke a target hook to see if (mul x,
> y) should be expanded to (if_then_else x, y, 0) instead when x is in {0, 1}.
That would be PR 26 because RISCV backend has the same issue. I will be
fixing that but most likely for GCC 15 as I am going to fix the regression
here.
[Bug middle-end/111126] Not always using czero.eqz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26 Xi Ruoyao changed: What|Removed |Added Target|riscv* (with zicond)|riscv* (with zicond), ||loongarch*, mips*r6* CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- LoongArch and MIPS64r6 also have similar instructions.
[Bug driver/93019] memory leak in gcc -O2 reported by Valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:36be2a0e91c76da4afcd5ddc37e03f5800396387 commit r14-6356-g36be2a0e91c76da4afcd5ddc37e03f5800396387 Author: Jakub Jelinek Date: Sat Dec 9 10:28:37 2023 +0100 driver: Fix memory leak [PR93019] driver:finalize used by JIT clears the mdswitches pointer; if it was allocated before, that leaks the memory. 2023-12-09 Costas Argyris Jakub Jelinek PR driver/93019 * gcc.cc (driver::finalize): Call XDELETEVEC on mdswitches before clearing it. Signed-off-by: Costas Argyris
[Bug middle-end/109267] generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109267 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed|2023-03-23 00:00:00 |2023-12-09 --- Comment #5 from Iain Sandoe --- I am seeing this on aarch64 darwin (bootstrap fail with the new Xcode 15 linker in libgomp). It can also apply equally to targets without .cfi_ support since the generation of empty functions messes up EH there too. Note that the fix in 57438 was done in the backend, and there was a work-around suggested in that PR which does appear still usable: -D__builtin_unreachable=__builtin_trap
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #9 from Eric Botcazou --- > Which means punt on this optimization for WORD_REGISTER_OPERATIONS if the > outer mode is word_mode, except when sub is a MEM and load_extend_op > (inner_mode) == ZERO_EXTEND? Yes, this sounds like a sensible approach.
[Bug target/112937] New: [14 Regression] GCN: FAILs due to unconditional 'f->use_flat_addressing = true;'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112937
Bug ID: 112937
Summary: [14 Regression] GCN: FAILs due to unconditional
'f->use_flat_addressing = true;'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
Target Milestone: ---
Target: GCN
The unconditional GCN 'f->use_flat_addressing = true;' applied as part of
commit r14-6226-ge7d6c277fa28c0b9b621d23c471e0388d2912644 "amdgcn, libgomp:
low-latency allocator" is causing a few regressions for GCN target (not
offloading) testing (tested '-march=gfx906', '-march=gfx90a'):
C:
[-PASS:-]{+FAIL:+} gcc.dg/pr64935-1.c (test for excess errors)
xgcc: error: [...]/gcc.dg/pr64935-1.c: '-fcompare-debug' failure (length)
Fortran:
PASS: gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single -O2 (test for
excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single
-O2 execution test
PASS: gfortran.dg/team_change_1.f90 -O0 (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_change_1.f90 -O0 execution test
[Etc.]
PASS: gfortran.dg/team_end_1.f90 -O0 (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_end_1.f90 -O0 execution test
[Etc.]
PASS: gfortran.dg/team_form_1.f90 -O0 (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_form_1.f90 -O0 execution test
[Etc.]
PASS: gfortran.dg/team_number_1.f90 -O0 (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/team_number_1.f90 -O0 execution test
[Etc.]
These execution test FAILs are generally of the form:
Memory access fault by GPU node-2 (Agent handle: 0x20a1d40) on address
0x7f56. Reason: Page not present or supervisor privilege.
Additionally, I'm seeing the following in my libstdc++ enablement tree:
PASS: std/ranges/iota/max_size_type.cc -std=gnu++20 (test for excess
errors)
{+WARNING: std/ranges/iota/max_size_type.cc -std=gnu++20 execution test
program timed out.+}
[-PASS:-]{+FAIL:+} std/ranges/iota/max_size_type.cc -std=gnu++20 execution
test
PASS: std/ranges/iota/max_size_type.cc -std=gnu++26 (test for excess
errors)
{+WARNING: std/ranges/iota/max_size_type.cc -std=gnu++26 execution test
program timed out.+}
[-PASS:-]{+FAIL:+} std/ranges/iota/max_size_type.cc -std=gnu++26 execution
test
(I guess I could provide pre-processed files for those if you'd like to
reproduce.)
To restore the Fortran test cases, just reverting the GCN back end change is
not sufficient: also need to rebuild GCN target libraries. (That is, the GCN
back end change does affect code generated for GCN target libraries.)
[Bug c++/112938] New: ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Bug ID: 112938
Summary: ice with -fstrub=internal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 56839
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56839&action=edit
C++ source code
foundBugs $ ~/gcc/results/bin/gcc -c -w bug988.cc
foundBugs $ ~/gcc/results/bin/gcc -c -w -fstrub=internal bug988.cc
bt2_locks.cpp: In member function ‘void mcs_lock::spin_while_eq(const volatile
std::atomic_bool&, bool)’:
bt2_locks.cpp:36:1: error: invalid operand in unary operation
# VUSE <.MEM_1(D)>
arg.61_2 ={v} (int) expected;
during IPA pass: strub
bt2_locks.cpp:36:1: internal compiler error: verify_gimple failed
0x120d053 verify_gimple_in_cfg(function*, bool, bool)
../../trunk.year/gcc/tree-cfg.cc:5666
0x107bc9a execute_function_todo(function*, void*)
../../trunk.year/gcc/passes.cc:2088
[Bug c++/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
David Binderman changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be:
struct mcs_lock {
void lock();
void spin_while_eq(volatile bool) {}
};
void mcs_lock::lock() { spin_while_eq(false); }
Adding the feature author for their opinion.
[Bug tree-optimization/112939] New: ICE: verify_ssa failed with -O -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939
Bug ID: 112939
Summary: ICE: verify_ssa failed with -O
-ftrivial-auto-var-init=zero
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/4q74n5baY
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC)
git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
int i;
void f (void)
{
for (;;)
{
if (0)
for (;;)
{
int *a;
int *b = a;
l1:
*b = (*b != 0) ? 0 : 2;
}
if (i != 0)
goto l1;
}
}
***
Command Lines:
$ gcc -O -ftrivial-auto-var-init=zero mutant.c
mutant.c: In function ‘f’:
mutant.c:20:1: error: definition in block 5 does not dominate use in block 3
20 | }
| ^
for SSA_NAME: a_11 in statement:
# VUSE <.MEM_5>
_1 = *a_11;
during GIMPLE pass: fre
mutant.c:20:1: internal compiler error: verify_ssa failed
0x1283220 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.cc:1203
0xee93a5 execute_function_todo
../../gcc/gcc/passes.cc:2095
0xee980e execute_todo
../../gcc/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
[Bug fortran/110987] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
--- Comment #3 from Kirill Chilikin ---
The derived type T3 has zero components but not zero length as it extends T1;
the test does not crash after the following changes:
diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index 961b0b5a573..e5d12f25e5e 100644
--- a/gcc/fortran/trans.cc
+++ b/gcc/fortran/trans.cc
@@ -1624,7 +1624,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
}
else if (derived && gfc_is_finalizable (derived, NULL))
{
- if (derived->attr.zero_comp && !rank)
+ if ((derived->components == NULL) && !rank)
{
/* Any attempt to assign zero length entities, causes the gimplifier
all manner of problems. Instead, a variable is created to act as
@@ -1685,7 +1685,7 @@ gfc_finalize_tree_expr (gfc_se *se, gfc_symbol *derived,
}
}
- if (derived && derived->attr.zero_comp)
+ if (derived && (derived->components == NULL))
{
/* All the conditions below break down for zero length derived types.
*/
tmp = build_call_expr_loc (input_location, final_fndecl, 3,
[Bug libgomp/112264] Occasionally (but very rare): 'FAIL: libgomp.fortran/target-nowait-array-section.f90 -O execution test'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112264 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-09 Ever confirmed|0 |1
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #6 from Robin Dapp --- This seems to be gone when simple vsetvl (instead of lazy) is used or with -fno-schedule-insns which might indicate a vsetvl pass problem. We might have a few more of those. Maybe it would make sense to run the testsuite with an RVV-enabled valgrind. But that might give more false negatives than real findings :/
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #7 from Robin Dapp --- Here 0x105c6 vse8.v v8,(a5) is where we overwrite m. The vl is 128 but the preceding vsetvl gets a4 = 46912504507016 as AVL which seems already borken.
[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723 Luca Bacci changed: What|Removed |Added CC||luca.bacci at outlook dot com --- Comment #8 from Luca Bacci --- (In reply to Jonathan Wakely from comment #1) > The Windows behaviour fails to conform to the C and C++ standards. I think > _M_transform should check errno and throw an exception on error (which means > removing the non-throwing exceptions specification from that function). Hi Jonathan! I'm giving it a go, but I have one question: which encoding are the strings passed to _M_transform() / _M_compare() in? (libstdc++-v3/config/locale/generic/collate_members.cc) is it the execution character set? Or is it always UTF-8? I am asking because we have to convert to UTF-16 and call wcsxfrm(). Many thanks, Luca
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #8 from JuzheZhong --- Li Pan will investigate it. He will note me if there is a bug in vsetvl pass.
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #9 from Robin Dapp --- In the good version the length is 32 here because directly before the vsetvl we have: li a4,32 That seems to get lost somehow.
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 --- Comment #5 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a314edee2490259d7f7caec8eef77846bcdb608b commit r14-6357-ga314edee2490259d7f7caec8eef77846bcdb608b Author: Jonathan Wakely Date: Fri Dec 8 13:47:04 2023 + libstdc++: Fix resolution of LWG 4016 for std::ranges::to [PR112876] What I implemented in r14-6199-g45630fbcf7875b does not match what I proposed for LWG 4016, and it imposes additional, unwanted requirements on the emplace and insert member functions of the container being populated. libstdc++-v3/ChangeLog: PR libstdc++/112876 * include/std/ranges (ranges::to): Do not try to use an iterator returned by the container's emplace or insert member functions. * testsuite/std/ranges/conv/1.cc (Cont4::emplace, Cont4::insert): Use the iterator parameter. Do not return an iterator.
[Bug libstdc++/111826] __cpp_lib_format should be 202110, not 202106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cdf45e00a936a76a785c592c9730f24ef1ac25cd commit r14-6358-gcdf45e00a936a76a785c592c9730f24ef1ac25cd Author: Jonathan Wakely Date: Fri Dec 8 14:40:26 2023 + libstdc++: Fix value of __cpp_lib_format macro [PR111826] As noted in the PR, we support both features required for the 202110L value, so we should define it with that value. libstdc++-v3/ChangeLog: PR libstdc++/111826 * include/bits/version.def (format): Update value. * include/bits/version.h: Regenerate. * testsuite/std/format/functions/format.cc:
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #10 from JuzheZhong --- OK. It seems it is VSETVL BUG. I will have look at it.
[Bug tree-optimization/112940] New: ICE: verify_ssa failed: definition in block 4 does not dominate use in block 8 at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112940 Bug ID: 112940 Summary: ICE: verify_ssa failed: definition in block 4 does not dominate use in block 8 at -O with _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 56840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56840&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c testcase.c: In function 'foo': testcase.c:4:1: error: definition in block 4 does not dominate use in block 8 4 | foo (long x) | ^~~ for SSA_NAME: _15 in statement: _14 = PHI <_10(2), _15(8)> PHI argument _15 for PHI node _14 = PHI <_10(2), _15(8)> during GIMPLE pass: bitintlower testcase.c:4:1: internal compiler error: verify_ssa failed 0x175f8bf verify_ssa(bool, bool) /repo/gcc-trunk/gcc/tree-ssa.cc:1203 0x13b4355 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2095 0x13b47be 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-6356-20231209102837-g36be2a0e91c-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-6356-20231209102837-g36be2a0e91c-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231209 (experimental) (GCC)
[Bug tree-optimization/112924] [14 regression] ICE when building util-linux (error: gimple_bb (stmt) is set to a wrong basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org Status|WAITING |NEW --- Comment #3 from Jakub Jelinek --- Indeed, with -O2 -m32 pr112924.c -march=x86-64 this started with r14-6010 and went away with r14-6132.
[Bug tree-optimization/112941] New: during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941 Bug ID: 112941 Summary: during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _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 56841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56841&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during GIMPLE pass: bitintlower testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in handle_operand_addr, at gimple-lower-bitint.cc:2134 7 | foo (void) | ^~~ 0xd644e2 handle_operand_addr /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2134 0x25c9e8f lower_muldiv_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3340 0x25dd546 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6401 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-6356-20231209102837-g36be2a0e91c-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-6356-20231209102837-g36be2a0e91c-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231209 (experimental) (GCC)
[Bug tree-optimization/112924] [14 regression] ICE when building util-linux (error: gimple_bb (stmt) is set to a wrong basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:af8bbd631f5425e9be084dfd1f2b9487a31a350e commit r14-6359-gaf8bbd631f5425e9be084dfd1f2b9487a31a350e Author: Jakub Jelinek Date: Sat Dec 9 15:29:51 2023 +0100 testsuite: Add testcase for already fixed PR [PR112924] This testcase got fixed with r14-6132-g50f2a3370d177f8fe9bea0461feb710523e048a2 . I'm just adding a testcase so that it doesn't reappear. 2023-12-09 Jakub Jelinek PR tree-optimization/112924 * gcc.dg/pr112924.c: New test.
[Bug tree-optimization/112924] [14 regression] ICE when building util-linux (error: gimple_bb (stmt) is set to a wrong basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jakub Jelinek --- Fixed. *** This bug has been marked as a duplicate of bug 112827 ***
[Bug tree-optimization/112827] [14 Regression] ICE on valid code at -O1 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112827 Jakub Jelinek changed: What|Removed |Added CC||csfore at posteo dot net --- Comment #8 from Jakub Jelinek --- *** Bug 112924 has been marked as a duplicate of this bug. ***
[Bug target/112933] gcc.target/aarch64/sme2/acle-asm/read_za16_vg1x2.c fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112933 Richard Sandiford changed: What|Removed |Added Last reconfirmed||2023-12-09 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Sandiford --- Gah, forgot to test the SME2 support on BE.
[Bug target/112931] gcc.target/aarch64/sme2/acle-asm/write_za16_vg1x2.c ICEs on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112931 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-12-09 --- Comment #2 from Richard Sandiford --- Testing a patch.
[Bug target/112930] gcc.target/aarch64/sme/call_sm_switch_7.c ICEs on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112930 Richard Sandiford changed: What|Removed |Added Last reconfirmed||2023-12-09 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #2 from Richard Sandiford --- Testing a patch.
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #2 from Xi Ruoyao --- On LA464: 13095 with GCC 13.2.0 The best I've got is: 12639 with GCC 14.0.0 + -falign-loops=8 -falign-labels=4 -falign-jumps=4 -falign-functions=16 and I cannot really explain why this is the best. With the default: 12592 with GCC 14.0.0 So on LA464 the default seems not so bad...
[Bug tree-optimization/96831] gcc.dg/tree-ssa/scev-[345].c FAIL on i?86 and arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96831 Bug 96831 depends on bug 112786, which changed state. Bug 112786 Summary: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Hans-Peter Nilsson --- .
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed, thanks again for catching this divergence from the wording.
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #10 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > I must say I have no idea what WORD_REGISTER_OPERATION says about the upper > bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode) > is ZERO_EXTEND (zeros then? Then this optimization is ok), or something > else? And what it says on REGs. It says those upper bits are well-defined, i.e. whatever MD pattern is used for it eventually will emit machine code that has the exact same result for those upper bits. This is almost impossible to prove for any non-trivial target, and certainly extremely fragile.
[Bug tree-optimization/112939] [14 Regression] ICE: verify_ssa failed with -O -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |14.0 Last reconfirmed||2023-12-09 Keywords||ice-on-valid-code, ||needs-bisection Status|UNCONFIRMED |NEW Summary|ICE: verify_ssa failed with |[14 Regression] ICE: |-O |verify_ssa failed with -O |-ftrivial-auto-var-init=zer |-ftrivial-auto-var-init=zer |o |o --- Comment #1 from Andrew Pinski --- Confirmed. A change in VN/FRE which is causing this.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=48274,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=112877
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-12-09
Ever confirmed|0 |1
Target||x86_64-linux-gnu
--- Comment #2 from Andrew Pinski ---
Reduced C testcase:
```
void f(volatile short) {}
void g() { f(0); }
```
The problem happens on x86_64 and not aarch64 due to TARGET_PROMOTE_PROTOTYPES
macro.
[Bug middle-end/112877] TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-09 --- Comment #1 from Andrew Pinski --- . See PR 48274 also.
[Bug tree-optimization/112887] during GIMPLE pass: phiopt ICE: Floating point exception (SIGFPE) at tree-ssa-phiopt.c:2224 with --param=l1-cache-line-size=0x20000000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112887 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c250ff90989a71dff11e9256e99d2fa965ab1295 commit r14-6360-gc250ff90989a71dff11e9256e99d2fa965ab1295 Author: Jakub Jelinek Date: Sat Dec 9 21:41:00 2023 +0100 phiopt: Fix ICE with large --param l1-cache-line-size= [PR112887] This function is never called when param_l1_cache_line_size is 0, but it uses int and unsigned int variables to hold alignment in bits, so for large param_l1_cache_line_size it is zero and e.g. DECL_ALIGN () % param_align_bits can divide by zero. Looking at the code, the function uses tree_fits_uhwi_p on the trees before converting them using tree_to_uhwi to int variables, which looks just wrong, either it would need to punt if it doesn't fit into those and also check for overflows during the computation, or use unsigned HOST_WIDE_INT for all of this. That also fixes the division by zero, as param_l1_cache_line_size maximum is INT_MAX, that multiplied by 8 will always fit. 2023-12-09 Jakub Jelinek PR tree-optimization/112887 * tree-ssa-phiopt.cc (hoist_adjacent_loads): Change type of param_align, param_align_bits, offset1, offset2, size2 and align1 variables from int or unsigned int to unsigned HOST_WIDE_INT. * gcc.dg/pr112887.c: New test.
[Bug tree-optimization/112887] during GIMPLE pass: phiopt ICE: Floating point exception (SIGFPE) at tree-ssa-phiopt.c:2224 with --param=l1-cache-line-size=0x20000000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112887 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug middle-end/112935] [14 Regression] Performance regression in Coremarks crcu8 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #19 from Andrew Pinski ---
This patch gets us back to using `&-` rather than shifts/adds for x86_64:
```
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 6da51f2aca2..4686cacd22f 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -10209,8 +10209,9 @@ expand_expr_real_2 (sepops ops, rtx target,
machine_mode tmode,
/* Expand X*Y as X&-Y when Y must be zero or one. */
if (SCALAR_INT_MODE_P (mode))
{
- bool bit0_p = tree_nonzero_bits (treeop0) == 1;
- bool bit1_p = tree_nonzero_bits (treeop1) == 1;
+ bool gimple_zero_one_valued_p (tree, tree (*)(tree));
+ bool bit0_p = gimple_zero_one_valued_p (treeop0, nullptr);
+ bool bit1_p = gimple_zero_one_valued_p (treeop1, nullptr);
/* Expand X*Y as X&Y when both X and Y must be zero or one. */
if (bit0_p && bit1_p)
```
[Bug libstdc++/111826] __cpp_lib_format should be 202110, not 202106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826 --- Comment #2 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9f5011f9e6e347e0b91f47a118a0ce58a2c2d99a commit r13-8140-g9f5011f9e6e347e0b91f47a118a0ce58a2c2d99a Author: Jonathan Wakely Date: Fri Dec 8 14:40:26 2023 + libstdc++: Fix value of __cpp_lib_format macro [PR111826] As noted in the PR, we support both features required for the 202110L value, so we should define it with that value. libstdc++-v3/ChangeLog: PR libstdc++/111826 * include/std/format (__cpp_lib_format): Update value. * include/std/version (__cpp_lib_format): Likewise. * testsuite/std/format/functions/format.cc: Update expected value. (cherry picked from commit cdf45e00a936a76a785c592c9730f24ef1ac25cd)
[Bug libstdc++/111826] __cpp_lib_format should be 202110, not 202106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Fixed, thanks for the report.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 Bug 109162 depends on bug 111826, which changed state. Bug 111826 Summary: __cpp_lib_format should be 202110, not 202106 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758 --- Comment #11 from Eric Botcazou --- > It says those upper bits are well-defined, i.e. whatever MD pattern is used > for it eventually will emit machine code that has the exact same result for > those upper bits. No, that's not true, the set of "register operations" is restricted.
[Bug tree-optimization/112940] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 8 at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112940 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-09 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed with r14-6360-gc250ff90989a71 .
[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-12-09
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
Slightly more reduced:
```
_BitInt (2049) b2049;
unsigned _BitInt (6384) b16384;
void
foo (signed char t)
{
b2049 = b16384 * t;
}
```
[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Andrew Pinski --- FAIL: gcc.dg/torture/bfloat16-basic.c -O0 execution test FAIL: gcc.dg/torture/bfloat16-basic.c -O1 execution test FAIL: gcc.dg/torture/bfloat16-basic.c -O2 execution test FAIL: gcc.dg/torture/bfloat16-basic.c -O3 -g execution test FAIL: gcc.dg/torture/bfloat16-basic.c -Os execution test FAIL: gcc.dg/torture/bfloat16-basic.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/bfloat16-basic.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -O0 execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -O1 execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -O2 execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -O3 -g execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -Os execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/bfloat16-builtin.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test Fail when tested with `-march=armv9-a+sve2`.
[Bug libstdc++/112942] New: swap(variant&, variant&) is incorrectly marked as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
Bug ID: 112942
Summary: swap(variant&, variant&) is incorrectly marked as
deleted
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kotonartem at protonmail dot com
Target Milestone: ---
GCC rejects the following code (when using libstdc++):
```
#include
struct A
{};
void swap(A&, A&) = delete;
void foo()
{
using V = std::variant;
V a, b;
using std::swap; // this is unnecessary due to ADL
swap(a, b);
}
```
with the following message:
```
: In function 'void foo()':
:14:9: error: use of deleted function
'std::enable_if_t<(!((is_move_constructible_v<_Types> && ...) &&
(is_swappable_v<_Types> && ...)))> std::swap(variant<_Types ...>&,
variant<_Types ...>&) [with _Types = {A};
enable_if_t<(!((is_move_constructible_v<_Types> && ...) &&
(is_swappable_v<_Types> && ...)))> = void]'
14 | swap(a, b);
| ^~
In file included from :1:
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/variant:1303:5: note:
declared here
1303 | swap(variant<_Types...>&, variant<_Types...>&) = delete;
| ^~~~
```
The compiler explorer link: https://godbolt.org/z/5od4s5cf3.
There is also a similar test case that expects the current behavior:
https://github.com/gcc-mirror/gcc/blob/c250ff9/libstdc%2B%2B-v3/testsuite/20_util/variant/compile.cc#L294-L300.
> ```
> // Not swappable, and variant not swappable via the generic std::swap.
> struct C { };
> void swap(C&, C&) = delete;
>
> static_assert( !std::is_swappable_v> );
> static_assert( !std::is_swappable_v> );
> static_assert( !std::is_swappable_v> );
> ```
I believe that this behavior is incorrect and the variant should indeed be
swappable even if `swap(A&, A&)` is deleted.
My reasoning is that in [variant.specalg] the `std::is_swappable_v`
requirement is mentioned under "Constraints" section, which, according to
[structure.specifications], describes "the conditions for the function's
participation in overload resolution". That is in contrast to "Mandates"
section, which would render the program ill-formed.
And since the `swap(variant&, variant&)` overload is not considered, the
generic `template void swap(T& a, T& b)` should be chosen instead.
Unlike the former overload, it only requires `T` (aka `variant`) to be both
move constructible and move assignable, which it is.
It should be noted that libc++ handles this case correctly, i.e.
`std::is_swappable_v>` is `true`.
[Bug libstdc++/112942] swap(variant&, variant&) is incorrectly marked as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942 --- Comment #1 from Andrew Pinski --- https://wg21.cmeerw.net/lwg/issue2749
[Bug libstdc++/112942] swap(variant&, variant&) is incorrectly marked as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/pipermail/libstdc++/2016-November/045176.html
[Bug libstdc++/112942] swap(variant&, variant&) is incorrectly marked as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942 --- Comment #3 from Artem Koton --- (In reply to Andrew Pinski from comment #1) > https://wg21.cmeerw.net/lwg/issue2749 Could you elaborate? I understand that this issue discusses the constraints in question but a failure to meet them should still result in the function just being excluded from overload resolution. The program should not be ill-formed.
[Bug libstdc++/112942] swap(variant&, variant&) is incorrectly marked as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942 --- Comment #4 from Andrew Pinski --- (In reply to Artem Koton from comment #3) > (In reply to Andrew Pinski from comment #1) > > https://wg21.cmeerw.net/lwg/issue2749 > > Could you elaborate? I understand that this issue discusses the constraints > in question but a failure to meet them should still result in the function > just being excluded from overload resolution. The program should not be > ill-formed. Just giving background information of the wording changes to C++17 on std::variant and std::swap here and about the testcase you pointed to and about when it was added specifcially while changing for that defect report.
[Bug middle-end/111876] bf16 complex mul/div does not work when the target has +fp16 support or when -fexcess-precision=16 is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876 Andrew Pinski changed: What|Removed |Added Component|target |middle-end Keywords||testsuite-fail --- Comment #6 from Andrew Pinski --- I see this failure with `-march=armv9-a+sve2` . Just for record it is while testing: FAIL: gcc.dg/torture/bfloat16-complex.c -O0 (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -O0 compilation failed to produce executable FAIL: gcc.dg/torture/bfloat16-complex.c -O1 (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/bfloat16-complex.c -O2 (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -O2 compilation failed to produce executable FAIL: gcc.dg/torture/bfloat16-complex.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -O2 -flto -fno-use-linker-plugin -flto-partition=none compilation failed to produce executable FAIL: gcc.dg/torture/bfloat16-complex.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects compilation failed to produce executable FAIL: gcc.dg/torture/bfloat16-complex.c -O3 -g (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -O3 -g compilation failed to produce executable FAIL: gcc.dg/torture/bfloat16-complex.c -Os (test for excess errors) UNRESOLVED: gcc.dg/torture/bfloat16-complex.c -Os compilation failed to produce executable
[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867 --- Comment #8 from Andrew Pinski --- Created attachment 56842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56842&action=edit Patch which I will be submitting soon
[Bug target/112936] LoongArch: Wrong instruction costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936 Xi Ruoyao changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Decembe ||r/640012.html Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org
[Bug target/112936] LoongArch: Wrong instruction costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936 --- Comment #2 from Xi Ruoyao --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640012.html
[Bug libstdc++/104928] std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928 --- Comment #2 from Nate Eldredge --- This bug is still present. Tested and reproduced with g++ 13.1.0 (Ubuntu package), and by inspection of the source code, it's still in the trunk as well. Encountered on StackOverflow: https://stackoverflow.com/questions/77626624/race-condition-in-morriss-algorithm
