[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #32 from Florian Weimer ---
There's this in standards.texi:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions. GCC requires the
freestanding environment provide @code{memcpy}, @code{memmove},
@code{memset} and @code{memcmp}.
Finally, if @code{__builtin_trap} is used, and the target does
not implement the @code{trap} pattern, then GCC emits a call
to @code{abort}.
Maybe that would be a place to mention this issue, too?
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #33 from rguenther at suse dot de ---
On Thu, 23 Nov 2023, fw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
>
> --- Comment #32 from Florian Weimer ---
> There's this in standards.texi:
>
> Most of the compiler support routines used by GCC are present in
> @file{libgcc}, but there are a few exceptions. GCC requires the
> freestanding environment provide @code{memcpy}, @code{memmove},
> @code{memset} and @code{memcmp}.
> Finally, if @code{__builtin_trap} is used, and the target does
> not implement the @code{trap} pattern, then GCC emits a call
> to @code{abort}.
>
> Maybe that would be a place to mention this issue, too?
Will add.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #14 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6ce952188ab39e303e4f63e474b5cba83b5b12fd commit r14-5771-g6ce952188ab39e303e4f63e474b5cba83b5b12fd Author: Jakub Jelinek Date: Thu Nov 23 09:13:37 2023 +0100 c++: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348] The following patch implements the user generated static_assert messages next to string literals. As I wrote already in the PR, in addition to looking through the paper I looked at the clang++ testcase for this feature implemented there from paper's author and on godbolt played with various parts of the testcase coverage below, and there are some differences between what the patch implements and what clang++ implements. The first is that clang++ diagnoses if M.size () or M.data () methods are present, but aren't constexpr; while the paper introduction talks about that, the standard wording changes don't seem to require that, all they say is that those methods need to exist (assuming accessible and the like) and be implicitly convertible to std::size_t or const char *, but rest is only if the static assertion fails. If there is intent to change that wording, the question is how far to go, e.g. while M.size () could be constexpr, they could e.g. return some class object which wouldn't have constexpr conversion operator to size_t/const char * and tons of other reasons why the constant evaluation could fail. Without actually evaluating it I don't see how we could guarantee anything for non-failed static_assert. The second difference is that static_assert (false, "foo"_myd); in the testcase is normal failed static assertion and static_assert (true, "foo"_myd); would be accepted, while clang++ rejects it. IMHO "foo"_myd doesn't match the syntactic requirements of unevaluated-string as mentioned in http://eel.is/c++draft/dcl.pre#10 , and because a constexpr udlit operator can return something which is valid, it shouldn't be rejected just in case. Last is clang++ ICEs on non-static data members size/data. The first version of this support had a difference where M.data () was not a constant expression but a core constant expression, but if M.size () != 0 M.data ()[0] ... M.data ()[M.size () - 1] were integer constant expressions. We don't have any routine to test whether an expression is a core constant expression, so what the code does is try silently whether M.data () is a constant expression (maybe_constant_value), if it is, nice, we can use that result to attempt to optimize the extraction of the message from it if it is some recognized form involving a STRING_CST and just to double-check try to constant evaluate M.data ()[0] and M.data ()[M.size () - 1] expressions as boundaries but not anything in between. If M.data () is not a constant expression, we don't fail, but use a slower method of evaluating M.data ()[i] for i 0, 1, ... M.size () - 1. And if M.size () == 0, the above wouldn't evaluate anything, so we try to constant evaluate (M.data (), 0) as constant expression, which should succeed if M.data () is a core constant expression and fail otherwise. The patch assumes that these expressions are manifestly constant evaluated. The patch implements what I see in the paper, because it is unclear what further changes will be voted in (and the changes can be done at that point). The initial patch used tf_none in 6 spots so that just the static_assert specific errors were emitted and not others, but during review this has been changed, so that we emit both the more detailed errors why something wasn't found or wasn't callable or wasn't convertible and diagnostics that static_assert second argument needs to satisfy some of the needed properties. 2023-11-23 Jakub Jelinek PR c++/110348 gcc/ * doc/invoke.texi (-Wno-c++26-extensions): Document. gcc/c-family/ * c.opt (Wc++26-extensions): New option. * c-cppbuiltin.cc (c_cpp_builtins): For C++26 predefine __cpp_static_assert to 202306L rather than 201411L. gcc/cp/ * parser.cc: Implement C++26 P2741R3 - user-generated static_assert messages. (cp_parser_static_assert): Parse message argument as conditional-expression if it is not a pure string literal or several of them concatenated followed by closing paren. * semantics.cc (finish_static_assert): Handle message which is not STRING_CST. For condition with bare parameter packs return early. * pt.cc (tsubst_expr) : Also tsubst_expr message and make sure that if it wasn't originally STRING_CST, it isn't
[Bug target/112672] [14 Regression] wrong code with __builtin_parityl() at -O and above on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/112673] [14 Regression] ICE verify_gimple failed since r14-5557-g6dd4c703be17fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug debug/112674] [14 Regression] Compare-debug failure after recent change on c6x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112674 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-11-23 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |14.0 --- Comment #2 from Richard Biener --- I will have a look.
[Bug target/112675] [14 Regression] r14-5385-g0a140730c97087 caused regression on testcases for i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail, wrong-code Target Milestone|--- |14.0
[Bug target/112676] [14 regression] ICE in extract_insn, at recog.cc:2804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |14.0
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #34 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7758cb4b53e8a33642709402ce582f769eb9fd18 commit r14-5772-g7758cb4b53e8a33642709402ce582f769eb9fd18 Author: Richard Biener Date: Thu Nov 23 08:54:56 2023 +0100 middle-end/32667 - document cpymem and memcpy exact overlap requirement The following amends the cpymem documentation to mention that exact overlap needs to be handled gracefully, also noting that the target runtime is expected to behave the same way where -ffreestanding docs mention the set of routines required. PR middle-end/32667 * doc/md.texi (cpymem): Document that exact overlap of source and destination needs to work. * doc/standards.texi (ffreestanding): Mention memcpy is required to handle the exact overlap case.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #35 from Jakub Jelinek --- Note, clang makes the same assumption apparently (while MSVC emits rep movs inline and ICC either that, or calls _intel_fast_memcpy). As I mentioned earlier, if glibc and other libraries provide an alias to memcpy or memmove (whichever guarantees that exact overlap will be handled right in the implementation), GCC could start using that instead of memcpy for those cases. And it would be up to the libraries to decide which implementation satisfies that.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Now implemented for GCC 14.
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 110348, which changed state. Bug 110348 Summary: [C++26] P2741R3 - User-generated static_assert messages https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/110345] [C++26] P2552R3 - On the ignorability of standard attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110345 --- Comment #2 from Jakub Jelinek --- The fallthrough stuff is still outstanding I think and I'll have a look. part is done in r14-5561-g52eedfa00960f2d255ec542626e3531a65aa8bb8 The rest unresolved.
[Bug target/111170] [13/14 regression] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) since r13-6552-gd11e088210a551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70 --- Comment #12 from Costas Argyris --- I think this can be considered as fixed now, since the new --disable-win32-utf8-manifest configure option leaves out the utf8 manifest and you shouldn't have a problem running gcc even on XP if you configure with that. However, you do need to build using the latest sources to use that option, since the patch was pushed to the master branch just earlier today.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #16 from corentinjabot at gmail dot com --- (In reply to Jakub Jelinek from comment #15) > Now implemented for GCC 14. Thanks for working on this > As I wrote already in the PR, in addition to looking through the paper > I looked at the clang++ testcase for this feature implemented there from > paper's author and on godbolt played with various parts of the testcase > coverage below, and there are some differences between what the patch > implements and what clang++ implements. > > The first is that clang++ diagnoses if M.size () or M.data () methods > are present, but aren't constexpr; while the paper introduction talks > about > that, the standard wording changes don't seem to require that, all they > say > is that those methods need to exist (assuming accessible and the like) > and be implicitly convertible to std::size_t or const char *, but rest is > only if the static assertion fails. If there is intent to change that > wording, the question is how far to go, e.g. while M.size () could be > constexpr, they could e.g. return some class object which wouldn't have > constexpr conversion operator to size_t/const char * and tons of other > reasons why the constant evaluation could fail. Without actually > evaluating > it I don't see how we could guarantee anything for non-failed > static_assert. Clang always evaluate if i recall, the error is actually a warning that defaults to error. > > The second difference is that > static_assert (false, "foo"_myd); > in the testcase is normal failed static assertion and > static_assert (true, "foo"_myd); > would be accepted, while clang++ rejects it. IMHO > "foo"_myd doesn't match the syntactic requirements of unevaluated-string > as mentioned in http://eel.is/c++draft/dcl.pre#10 , and because > a constexpr udlit operator can return something which is valid, it > shouldn't > be rejected just in case. Seems like a bug in Clang indeed, I will investigate. > Last is clang++ ICEs on non-static data members size/data. You have a reproducer for that ?
[Bug target/112547] 9% exec time regression of 462.libquantum SPEC on AMD zen4 CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547 Filip Kastl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Filip Kastl --- Setting status to RESOLVED WORKSFORME
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 112547, which changed state. Bug 112547 Summary: 9% exec time regression of 462.libquantum SPEC on AMD zen4 CPU https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug target/112672] [14 Regression] wrong code with __builtin_parityl() at -O and above on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #4 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #3) > parityhi2 should have: > rtx extra = gen_reg_rtx (HImode); > emit_move_insn (extra, operands[1]); > emit_insn (gen_parityhi2_cmp (extra)); > > Or something similar because parityqi2_cmp clobbers its argument. Exactly. I have a patch in testing.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #17 from Jakub Jelinek --- (In reply to corentinjabot from comment #16) > Clang always evaluate if i recall, the error is actually a warning that > defaults to error. I initially had a warning for it, but Jason preferred not to warn at all. Non-constexpr methods/functions is just one of many reasons why it could fail to constant evaluate. > > Last is clang++ ICEs on non-static data members size/data. > > You have a reproducer for that ? The static_assert1.C test above. https://godbolt.org/z/s3fffdsEq
[Bug target/112677] New: ASAN reports stack-buffer-overflow in tree-vect-loop.cc vect_is_simple_use when compiling with -mavx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677 Bug ID: 112677 Summary: ASAN reports stack-buffer-overflow in tree-vect-loop.cc vect_is_simple_use when compiling with -mavx512 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Created attachment 56670 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56670&action=edit A list of testcases triggering this error On many testcases from the GCC testsuite an ASAN-instrumented GCC reports stack-buffer-overflow error in vect_is_simple_use at tree-vect-loop.cc:13584 file. All of the errors happen when compiling with some kind of -mavx512 option or with -march=skylake-avx512. I'm attaching a list of testcases that trigger this error. Compiler configured with: --enable-languages=default,jit,lto,go,d --enable-host-shared --enable-checking=release --disable-multilib --with-build-config=bootstrap-asan One example of a testcase where this error occurs is g++.dg/opt/pr112374.C. Running gcc src/gcc/testsuite/g++.dg/opt/pr112374.C -O2 -march=skylake-avx512 results in ==46365==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f41ef71c6f8 at pc 0x0562f3ab bp 0x7ffee76484d0 sp 0x7ffee76484c8 WRITE of size 8 at 0x7f41ef71c6f8 thread T0 #0 0x562f3aa in vect_is_simple_use(tree_node*, vec_info*, vect_def_type*, tree_node**, _stmt_vec_info**, gimple**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-stmts.cc:13584 #1 0x2c708ad in vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*, _slp_instance*, vec*) /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:7632 #2 0x2c971b5 in vect_analyze_loop_operations /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:2149 #3 0x2c971b5 in vect_analyze_loop_2 /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:3011 #4 0x2c9dc43 in vect_analyze_loop_1 /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:3450 #5 0x2ca037e in vect_analyze_loop(loop*, vec_info_shared*) /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:3604 #6 0x2d9f495 in try_vectorize_loop_1 /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vectorizer.cc:1066 #7 0x2da0cd9 in execute /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vectorizer.cc:1298 #8 0x1f4a262 in execute_one_pass(opt_pass*) /home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2641 #9 0x1f4bb8c in execute_pass_list_1 /home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2750 #10 0x1f4bbb2 in execute_pass_list_1 /home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2751 #11 0x1f4bbb2 in execute_pass_list_1 /home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2751 #12 0x1f4bc25 in execute_pass_list(function*, opt_pass*) /home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2761 #13 0x130a814 in cgraph_node::expand() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:1841 #14 0x130a814 in cgraph_node::expand() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:1794 #15 0x131004d in expand_all_functions /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2024 #16 0x131004d in symbol_table::compile() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2398 #17 0x131004d in symbol_table::compile() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2309 #18 0x1316999 in symbol_table::finalize_compilation_unit() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2583 #19 0x23492cf in compile_file /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:473 #20 0x7e26dd in do_compile /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2129 #21 0x7e26dd in toplev::main(int, char**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2285 #22 0x7ed873 in main /home/worker/buildworker/tiber-gcc-asan/build/gcc/main.cc:39 #23 0x7f41f10281af in __libc_start_call_main (/lib64/libc.so.6+0x281af) (BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab) #24 0x7f41f1028278 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x28278) (BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab) #25 0x7ef1d4 in _start ../sysdeps/x86_64/start.S:115 Address 0x7f41ef71c6f8 is located in stack of thread T0 at offset 1784 in frame #0 0x2c6e69f in vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*, _slp_instance*, vec*) /home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:7385 This frame has 145 object(s): [48, 50) '' [64, 66) '' [80, 84) 'dt' (line
[Bug libstdc++/110879] [14 Regression] Unnecessary reread from memory in a loop with std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110879 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:256d64b3460807f33ff2f70e676801bdcf908c1c commit r14-5774-g256d64b3460807f33ff2f70e676801bdcf908c1c Author: Jonathan Wakely Date: Wed Nov 22 21:24:08 2023 + c++: Require C++11 for g++.dg/opt/pr110879.C [PR110879] The _M_realloc_insert member does not have the trivial relocation optimization for C++98, which seems to be why the _M_end_of_storage member does not get optimized away. Make this test unsupported for C++98. gcc/testsuite/ChangeLog: PR libstdc++/110879 * g++.dg/opt/pr110879.C: Require C++11 or later.
[Bug middle-end/112336] fsanitize=address vs _BitInt with a non-mode size (smaller than max mode size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f9982ef4f55bd3a63745e03ac6d68b4a92fa8bce commit r14-5776-gf9982ef4f55bd3a63745e03ac6d68b4a92fa8bce Author: Jakub Jelinek Date: Thu Nov 23 12:59:54 2023 +0100 expr: Fix &bitint_var handling in initializers [PR112336] As the following testcase shows, we ICE when trying to emit ADDR_EXPR of a bitint variable which doesn't have mode width. The problem is in the EXTEND_BITINT stuff which makes sure we treat the padding bits on memory reads from user bitint vars as undefined. When expanding ADDR_EXPR on such vars inside outside of initializers, expand_expr_addr* uses EXPAND_CONST_ADDRESS modifier and EXTEND_BITINT does nothing, but in initializers it keeps using EXPAND_INITIALIZER modifier. So, we need to treat EXPAND_INITIALIZER the same as EXPAND_CONST_ADDRESS for this regard. 2023-11-23 Jakub Jelinek PR middle-end/112336 * expr.cc (EXTEND_BITINT): Don't call reduce_to_bit_field_precision if modifier is EXPAND_INITIALIZER. * gcc.dg/bitint-41.c: New test.
[Bug middle-end/112336] fsanitize=address vs _BitInt with a non-mode size (smaller than max mode size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 Tamar Christina changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Tamar Christina --- Thanks! that seems to be all we've noticed. Thanks for the quick fixes!
[Bug target/112670] RISC-V: Run fail on pr65518.c with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
--- Comment #2 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:35a688f434159a923420310860c5bc721e29a741
commit r14-5777-g35a688f434159a923420310860c5bc721e29a741
Author: Juzhe-Zhong
Date: Thu Nov 23 19:59:52 2023 +0800
RISC-V: Disable AVL propagation of vrgather instruction
This patch fixes following FAILs in zvl1024b of both RV32/RV64:
FAIL: gcc.c-torture/execute/990128-1.c -O2 execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.c-torture/execute/990128-1.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gcc.c-torture/execute/990128-1.c -O3 -g execution test
FAIL: gcc.dg/torture/pr58955-2.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
The root case can be simpliy described in this following small case:
https://godbolt.org/z/7GaxbEGzG
typedef int64_t v1024b __attribute__ ((vector_size (128)));
void foo (void *out, void *in, int64_t a, int64_t b)
{
v1024b v = {a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a};
v1024b v2 = {b,b,b,b,b,b,b,b,b,b,b,b,b,b,b,b};
v1024b index = *(v1024b*)in;
v1024b v3 = __builtin_shuffle (v, v2, index);
__riscv_vse64_v_i64m1 (out, (vint64m1_t)v3, 10);
}
Incorrect ASM:
foo:
li a5,31
vsetivlizero,10,e64,m1,ta,mu
vmv.v.x v2,a5
vl1re64.v v1,0(a1)
vmv.v.x v4,a2
vand.vv v1,v1,v2
vmv.v.x v3,a3
vmsgeu.vi v0,v1,16
vrgather.vv v2,v4,v1 --> AVL = VLMAX according to codes.
vadd.vi v1,v1,-16
vrgather.vv v2,v3,v1,v0.t --> AVL = VLMAX according to codes.
vse64.v v2,0(a0) --> AVL = 10 according to codes.
ret
For vrgather dest, source, index instruction, when index may has the value
> the following store AVL
that is index value > 10. In this situation, the codes above will end up
with:
The source vector of vrgather has undefined value on index >= AVL (which is
10 in this case).
So disable AVL propagation for vrgather instruction.
PR target/112599
PR target/112670
gcc/ChangeLog:
* config/riscv/riscv-avlprop.cc (alv_can_be_propagated_p): New
function.
(vlmax_ta_p): Disable vrgather AVL propagation.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr112599-1.c: New test.
[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
--- Comment #3 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:35a688f434159a923420310860c5bc721e29a741
commit r14-5777-g35a688f434159a923420310860c5bc721e29a741
Author: Juzhe-Zhong
Date: Thu Nov 23 19:59:52 2023 +0800
RISC-V: Disable AVL propagation of vrgather instruction
This patch fixes following FAILs in zvl1024b of both RV32/RV64:
FAIL: gcc.c-torture/execute/990128-1.c -O2 execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/990128-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.c-torture/execute/990128-1.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gcc.c-torture/execute/990128-1.c -O3 -g execution test
FAIL: gcc.dg/torture/pr58955-2.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions execution test
The root case can be simpliy described in this following small case:
https://godbolt.org/z/7GaxbEGzG
typedef int64_t v1024b __attribute__ ((vector_size (128)));
void foo (void *out, void *in, int64_t a, int64_t b)
{
v1024b v = {a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a};
v1024b v2 = {b,b,b,b,b,b,b,b,b,b,b,b,b,b,b,b};
v1024b index = *(v1024b*)in;
v1024b v3 = __builtin_shuffle (v, v2, index);
__riscv_vse64_v_i64m1 (out, (vint64m1_t)v3, 10);
}
Incorrect ASM:
foo:
li a5,31
vsetivlizero,10,e64,m1,ta,mu
vmv.v.x v2,a5
vl1re64.v v1,0(a1)
vmv.v.x v4,a2
vand.vv v1,v1,v2
vmv.v.x v3,a3
vmsgeu.vi v0,v1,16
vrgather.vv v2,v4,v1 --> AVL = VLMAX according to codes.
vadd.vi v1,v1,-16
vrgather.vv v2,v3,v1,v0.t --> AVL = VLMAX according to codes.
vse64.v v2,0(a0) --> AVL = 10 according to codes.
ret
For vrgather dest, source, index instruction, when index may has the value
> the following store AVL
that is index value > 10. In this situation, the codes above will end up
with:
The source vector of vrgather has undefined value on index >= AVL (which is
10 in this case).
So disable AVL propagation for vrgather instruction.
PR target/112599
PR target/112670
gcc/ChangeLog:
* config/riscv/riscv-avlprop.cc (alv_can_be_propagated_p): New
function.
(vlmax_ta_p): Disable vrgather AVL propagation.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr112599-1.c: New test.
[Bug target/112670] RISC-V: Run fail on pr65518.c with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from JuzheZhong --- Fixed
[Bug tree-optimization/112678] New: Massive slowdown of compilation time with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678 Bug ID: 112678 Summary: Massive slowdown of compilation time with PGO Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz CC: hubicka at gcc dot gnu.org Target Milestone: --- Between g:37183018134049a7 and g:af7fa3135b6b046f there is a big increase of compilation time when compiling with profile guided optimization. Happens on both O2 and Ofast with lto both disabled or enabled on x86_64 machines and aarch64 machine. Some plots that show this: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.110.8 (380% slowdown) https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=589.337.8 (700% slowdown) https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=286.407.8 (660% slowdown) All plots show compilation times of SPEC benchmarks.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 --- Comment #2 from CVS Commits --- The master branch has been updated by Di Zhao : https://gcc.gnu.org/g:746344dd53807d840c29f52adba10d0ab093bd3d commit r14-5779-g746344dd53807d840c29f52adba10d0ab093bd3d Author: Di Zhao Date: Thu Nov 9 15:06:37 2023 +0800 swap ops in reassoc to reduce cross backedge FMA Previously for ops.length >= 3, when FMA is present, we don't rank the operands so that more FMAs can be preserved. But this brings more FMAs with loop dependency, which lead to worse performance on some targets. Rank the oprands (set width=2) when: 1. avoid_fma_max_bits is set. 2. And loop dependent FMA sequence is found. In this way, we don't have to discard all the FMA candidates in the bad shaped sequence in widening_mul, instead we can keep fewer FMAs without loop dependency. With this patch, there's about 2% improvement in 510.parest_r 1-copy run on ampere1 (with "-Ofast -mcpu=ampere1 -flto --param avoid-fma-max-bits=512"). PR tree-optimization/110279 gcc/ChangeLog: * tree-ssa-reassoc.cc (get_reassociation_width): check for loop dependent FMAs. (reassociate_bb): For 3 ops, refine the condition to call swap_ops_for_binary_stmt. gcc/testsuite/ChangeLog: * gcc.dg/pr110279-1.c: New test.
[Bug middle-end/112679] New: ICE in expand_float, at optabs.cc:5724 with bitint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112679
Bug ID: 112679
Summary: ICE in expand_float, at optabs.cc:5724 with bitint
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: jakub at redhat dot com
Target Milestone: ---
Compiling testsuite/gcc.dg/bitint-35.c
ICE since initial commits - r14-3751-g8c984a1c3693df.
$ gcc bitint-35.c -frounding-math
bitint-35.c: In function ‘foo’:
bitint-35.c:12:19: warning: overflow in conversion from ‘_BitInt(30)’ to
‘_BitInt(27)’ changes value from ‘-390288573’ to ‘12364611’ [-Woverflow]
12 | _BitInt(27) d = -390288573wb; /* { dg-warning
"overflow in conversion from '_BitInt\\\(30\\\)' to '_BitInt\\\(27\\\)' changes
value from '-390288573' to '12364611'" } */
| ^
bitint-35.c:13:28: warning: conversion from ‘unsigned _BitInt(29)’ to ‘unsigned
_BitInt(27)’ changes value from ‘309641337’ to ‘41205881’ [-Woverflow]
13 | unsigned _BitInt(27) e = 309641337uwb;/* { dg-warning
"conversion from 'unsigned _BitInt\\\(29\\\)' to 'unsigned _BitInt\\\(27\\\)'
changes value from '309641337' to '41205881'" } */
|^~~~
bitint-35.c:16:19: warning: overflow in conversion from ‘int’ to ‘_BitInt(27)’
changes value from ‘-390288573’ to ‘12364611’ [-Woverflow]
16 | _BitInt(27) h = -390288573; /* { dg-warning
"overflow in conversion from 'int' to '_BitInt\\\(27\\\)' changes value from
'-390288573' to '12364611'" } */
| ^
bitint-35.c:17:28: warning: conversion from ‘unsigned int’ to ‘unsigned
_BitInt(27)’ changes value from ‘309641337’ to ‘41205881’ [-Woverflow]
17 | unsigned _BitInt(27) i = 309641337U; /* { dg-warning
"conversion from 'unsigned int' to 'unsigned _BitInt\\\(27\\\)' changes value
from '309641337' to '41205881'" } */
|^~
bitint-35.c:20:11: warning: overflow in conversion from ‘_BitInt(64)’ to ‘int’
changes value from ‘-8087431137529383656’ to ‘-1105152744’ [-Woverflow]
20 | int l = -8087431137529383656wb; /* { dg-warning
"overflow in conversion from '_BitInt\\\(64\\\)' to 'int' changes value from
'-8087431137529383656' to '-1105152744'" } */
| ^
bitint-35.c:21:20: warning: conversion from ‘unsigned _BitInt(61)’ to ‘unsigned
int’ changes value from ‘1664073919553255778’ to ‘3338058082’ [-Woverflow]
21 | unsigned int m = 1664073919553255778uwb; /* { dg-warning
"conversion from 'unsigned _BitInt\\\(61\\\)' to 'unsigned int' changes value
from '1664073919553255778' to '3338058082'" } */
|^~
during RTL pass: expand
bitint-35.c:23:12: internal compiler error: in expand_float, at optabs.cc:5729
23 | _Float32 n =
51441631083309184313435496923626431699697406185384986811300218556561965470218425783308778801748592322915101142266821623326688106425864884688172114173397118407357447763009120wb;
/* { dg-warning "conversion from '_BitInt\\\(575\\\)' to '_Float32' changes
value from
'0x353eab28b46b03ea99b84f9736cd8dbe5e986915a0383c3cb381c0da41e31b3621c75fd53262bfcb1b0e6251dbf00f3988784e29b08b65640c263e4d0959832a20e2ff5245be1e60'
to '\\\+Inff32'" "" { target bitint575 } } */
|^
0x7e2b67 expand_float(rtx_def*, rtx_def*, int)
/home/mjires/git/GCC/master/gcc/optabs.cc:5729
0xc06bc8 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/mjires/git/GCC/master/gcc/expr.cc:9945
0xae0440 expand_gimple_stmt_1
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:3983
0xae0440 expand_gimple_stmt
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:4044
0xae65f6 expand_gimple_basic_block
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6100
0xae7f36 execute
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6835
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.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap --enable-checking
--enable-languages=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)
[Bug target/112676] [14 regression] ICE in extract_insn, at recog.cc:2804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676 --- Comment #1 from Manuel Lauss --- Created attachment 56671 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56671&action=edit another testcase Another testcase, one of a few from virtualbox: g++ -O2 -march=znver4 -mtune=znver4 -mno-avx -c alt-sha1.i /tmp-ram/portage/app-emulation/virtualbox-7.0.12/work/VirtualBox-7.0.12/src/VBox/Runtime/common/checksum/alt-sha1.cpp: In function 'bool RTSha1Check(const void*, size_t, const uint8_t*)': /tmp-ram/portage/app-emulation/virtualbox-7.0.12/work/VirtualBox-7.0.12/src/VBox/Runtime/common/checksum/alt-sha1.cpp:533:1: error: unrecognizable insn: (insn 23 22 24 2 (set (reg:V16QI 109) (xor:V16QI (reg:V16QI 108) (mem/c:V16QI (reg:DI 107) [0 MEM [(void *)&Ctx + 328B]+0 S16 A64]))) "/tmp-ram/portage/app-emulation/virtualbox-7.0.12/work/VirtualBox-7.0.12/src/VBox/Runtime/common/checksum/alt-sha1.cpp":529:23 -1 (nil)) during RTL pass: vregs /tmp-ram/portage/app-emulation/virtualbox-7.0.12/work/VirtualBox-7.0.12/src/VBox/Runtime/common/checksum/alt-sha1.cpp:533:1: internal compiler error: in extract_insn, at recog.cc:2804
[Bug tree-optimization/112678] [14 regression] Massive slowdown of compilation time with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678 Sam James changed: What|Removed |Added Target Milestone|--- |14.0
[Bug c++/112680] New: g++-13 segfault on std::regex_match with c++11 or above -O2 and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680
Bug ID: 112680
Summary: g++-13 segfault on std::regex_match with c++11 or
above -O2 and lto
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: costamagnagianfranco at yahoo dot it
Target Milestone: ---
Created attachment 56672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56672&action=edit
reproduce test case
This used to work with g++-10 and started to fail with g++-11 g++-12 and g++-13
sh runme.sh
Segmentation fault (core dumped)
g++-12 main.cpp -std=c++11 -O2 -flto=auto -o main && ./main
The main is really simple, load two strings, and call regex function
#include
#include
#include
#include
int main()
{
std::ifstream t("file.txt");
std::stringstream file;
file << t.rdbuf();
std::string filestr = file.str();
std::ifstream t2("regex.txt");
std::stringstream filepathregex;
filepathregex << t2.rdbuf();
std::string regexstr = filepathregex.str();
const std::regex regex(regexstr);
std::regex_match(filestr.begin(), filestr.end(), regex);
}
I attached the tarball with the files to reproduce the issue.
The content triggering the issue was originated by the testsuite dump of
zim-tools
https://launchpad.net/ubuntu/+source/zim-tools/3.2.0-1build1
[Bug tree-optimization/112678] [14 regression] Massive slowdown of compilation time with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||sebastian.huber@embedded-br ||ains.de --- Comment #1 from Richard Biener --- Hmm, the -fprofile-update mode default didn't change, did it? I'm guessing that for some reason the generated code is different for -fprofile-update=single now? Note IIRC "compile-time" for SPEC with PGO includes the training run itself, so that might be also the reason for the slowdown (runtime performance regression of the instrumented binary).
[Bug target/112681] New: [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 Bug ID: 112681 Summary: [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56673 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56673&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -mfma -mno-sse4.2 testcase.C testcase.C: In function 'int foo()': testcase.C:11:1: error: unrecognizable insn: 11 | } | ^ (insn 8 7 9 2 (set (reg:V16QI 104) (xor:V16QI (reg:V16QI 103) (mem/c:V16QI (reg/f:DI 102) [0 MEM [(void *)&b + 8B]+0 S16 A64]))) "testcase.C":10:27 -1 (nil)) during RTL pass: vregs testcase.C:11:1: internal compiler error: in extract_insn, at recog.cc:2804 0x8d9b93 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:108 0x8d9c10 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.cc:116 0x8c8a7f extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.cc:2804 0x14032bd instantiate_virtual_regs_in_insn /repo/gcc-trunk/gcc/function.cc:1610 0x14032bd instantiate_virtual_regs /repo/gcc-trunk/gcc/function.cc:1993 0x14032bd execute /repo/gcc-trunk/gcc/function.cc:2040 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-5779-20231123205631-g746344dd538-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-5779-20231123205631-g746344dd538-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231123 (experimental) (GCC)
[Bug libstdc++/112682] New: More efficient std::basic_string move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112682
Bug ID: 112682
Summary: More efficient std::basic_string move construction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
A few places in bits/basic_string.h have the following code:
```
if (__str._M_is_local())
{
_M_init_local_buf();
traits_type::copy(_M_local_buf, __str._M_local_buf,
__str.length() + 1);
}
```
Despite the knowledge, that `__str.length()` is not greater than 15 the
compiler emits (and inlines) a memcpy call. That results in a quite big set of
instructions https://godbolt.org/z/j35MMfxzq
Replacing `__str.length() + 1` with `_S_local_capacity + 1` explicitly forces
the compiler to copy the whole `__str._M_local_buf`. As a result the assembly
becomes almost 5 times shorter and without any function calls or multiple
conditional jumps https://godbolt.org/z/bfq8bxra9
P.S.: not sure, if it is allowed to copy uninitialized data via
traits_type::copy and would the sanitizers be happy with such copy attempt.
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 Rainer Orth changed: What|Removed |Added Host|hppa*-*-linux* |hppa*-*-linux*, ||*-*-solaris2.11 Build|hppa*-*-linux* |hppa*-*-linux*, ||*-*-solaris2.11 Target|hppa*-*-linux* |hppa*-*-linux*, ||*-*-solaris2.11 CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth --- I'm seeing the same failures on Solaris (both sparc and x86): * On x86, it's 32-bit only. * On sparc, it's both 32 and 64-bit: FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc:52: test_max_depth(): Assertion '! t.empty()' failed. FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test terminate called after throwing an instance of 'std::out_of_range' what(): basic_stack_trace::at: bad frame number FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test terminate called after throwing an instance of 'std::out_of_range' what(): basic_stacktrace::at: bad frame number FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++26 execution test /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc:40: void test_cons(): Assertion '! s3.empty()' failed.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #36 from Rich Felker ---
> the assembly generated by the current implementations already supports that
> case.
Our memcpy is not written in asm but in C, and it has the restrict qualifier on
src and dest. This entitles a compiler to emit asm equivalent to if (src==dest)
system("rm -rf /") if it likes. I don't know how you can write a valid C
implementation of memcpy that "doesn't care" about 100% overlap without giving
up restrict (and the benefits it entails) entirely.
If you're happy with a branch, you could probably take restrict off the
arguments and do something like:
if (src==dest) return;
const char *restrict src2 = src;
char *restrict dest2 = dest;
...
but that's shoving the branch into memcpy where it's a cost on every caller
making dynamic memcpys with potentially tiny size (like qsort, etc.) and
obeying the contract not to call with overlapping src/dest, rather than just
imposing it on bad callers.
[Bug libstdc++/112569] libstdc++-v3/include/ranges:1456: missing check for self-assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112569 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- This is exactly as it should be. There's no guarantee that self-move-assignment on the associated range is a no-op, so the cache must be invalidated.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #37 from Rich Felker --- Also: has anyone even looked at what happens if a C memcpy with proper use of restrict gets LTO-inlined into a caller with GCC-generated memcpy calll where src==dest? That sounds like a case likely to blow up...
[Bug libstdc++/112593] FAIL: 26_numerics/headers/cmath/equivalent_functions.cc on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112593 Rainer Orth changed: What|Removed |Added Summary|FAIL: |FAIL: |26_numerics/headers/cmath/e |26_numerics/headers/cmath/e |quivalent_functions.cc on |quivalent_functions.cc on |Solaris 11.3|Solaris Target|sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||i386-pc-solaris2.11 CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- The test also FAILs on Solaris 11.4, both sparc and x86, 32 and 64-bit. However, the failure mode is different: /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/26_numerics/headers/cmath/equivalent_functions.cc:120: void test_float_overload(): Assertion 'std::asin(x) == std::asinf(x)' failed. I wouldn't worry too much about the 11.3 failure (if it's 11.3-only): 11.3 support is deprecated and was supported to be removed from trunk before the GCC 14 release. However, I've held off from the actual removal until new sparc and x86 Solaris 11.4 cfarm systems are in place.
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/111948] subrange modifies a const size object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948 Jonathan Wakely changed: What|Removed |Added Depends on||112439 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=112439| Target Milestone|--- |13.3 --- Comment #8 from Jonathan Wakely --- This hasn't been fixed yet, so I'll add the library workaround. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439 [Bug 112439] [13/14 Regression] Modification of a member overlapping with a [[no_unique_address]] member in the constructor is incorrectly rejected in constant evaluation
[Bug tree-optimization/112683] New: Optimizing memcpy range by extending to word bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112683
Bug ID: 112683
Summary: Optimizing memcpy range by extending to word bounds
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the minimized source code from libstdc++
```
struct string {
unsigned long _M_string_length;
enum { _S_local_capacity = 15 };
char _M_local_buf[_S_local_capacity + 1];
};
string copy(const string& __str) noexcept {
string result;
if (__str._M_string_length > __str._S_local_capacity)
__builtin_unreachable();
result._M_string_length = __str._M_string_length;
__builtin_memcpy(result._M_local_buf, __str._M_local_buf,
__str._M_string_length + 1);
return result;
}
```
Right now GCC with -O2 emits a long assembly with ~50 instructions
https://godbolt.org/z/a89bh17hd
However, note that
* the `result._M_local_buf` is uninitialized,
* there's at most 16 bytes to copy to `result._M_local_buf` which is of size 16
bytes
So the compiler could optimize the code to always copy 16 bytes. The behavior
change is not observable by user as the uninitialized bytes could contain any
data, including the same bytes as `_str._M_local_buf`.
As a result of always copying 16 bytes, the assembly becomes more than 7 times
shorter, conditional jumps go away: https://godbolt.org/z/r5GPYTs4Y
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #38 from Tim Ruffing --- (In reply to Rich Felker from comment #36) > If you're happy with a branch, you could probably take restrict off the > arguments and do something like: > > if (src==dest) return; > const char *restrict src2 = src; > char *restrict dest2 = dest; > ... > I'm not saying that such an implementation will be a good idea, but just a remark: You could, in fact, keep restrict for the arguments in this case, because the object pointed to by src and dest is not accessed at all when src==dest. So this is correct code according to the standard. (The exact semantics of restrict are a bit involved...)
[Bug libstdc++/112593] FAIL: 26_numerics/headers/cmath/equivalent_functions.cc on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112593 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-11-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- (In reply to Rainer Orth from comment #1) > The test also FAILs on Solaris 11.4, both sparc and x86, 32 and 64-bit. > However, > the failure mode is different: > > /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/26_numerics/headers/ > cmath/equivalent_functions.cc:120: void test_float_overload(): Assertion > 'std::asin(x) == std::asinf(x)' failed. That looks like a similar problem though. std::asin(float) probably calls std::__asinf, which apparently gives a different result to ::asinf. If you comment out the call to test_float_overload() in main, it might fail at the same place in test_long_double_overload (or maybe somewhere else!) > I wouldn't worry too much about the 11.3 failure (if it's 11.3-only): 11.3 > support is deprecated and was supported to be removed from trunk before the > GCC 14 release. However, I've held off from the actual removal until new > sparc and x86 Solaris 11.4 cfarm systems are in place. Yeah, the cfarm is the only way I can test on Solaris, so that's why I use 11.3 with -enable-obsolete.
[Bug tree-optimization/112678] [14 regression] Massive slowdown of compilation time with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
--- Comment #2 from Jan Hubicka ---
Seems we changed default to locking increments.
jh@ryzen4:/tmp> cat t.C
void
test()
{
}
jh@ryzen4:/tmp> ~/trunk-install/bin/g++ -O2 -fprofile-generate t.C -S ; grep
lock t.s
lock addl $1, __gcov0._Z4testv(%rip)
lock addl %eax, __gcov0._Z4testv+4(%rip)
jh@ryzen4:/tmp> g++ -O2 -fprofile-generate t.C -S ; grep lock t.s
jh@ryzen4:/tmp>
so r:20a3c74c347429c109bc7002285b735be83f6a0b
Honza
[Bug tree-optimization/112678] [14 regression] Massive slowdown of compilation time with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678 --- Comment #3 from CVS Commits --- The master branch has been updated by Sebastian Huber : https://gcc.gnu.org/g:8674d70ce37ca3249a641fb418c6849d4f95f348 commit r14-5783-g8674d70ce37ca3249a641fb418c6849d4f95f348 Author: Sebastian Huber Date: Thu Nov 23 14:45:50 2023 +0100 gcov: No atomic ops for -fprofile-update=single gcc/ChangeLog: PR tree-optimization/112678 * tree-profile.cc (tree_profiling): Do not use atomic operations for -fprofile-update=single.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #39 from Tim Ruffing --- (In reply to Rich Felker from comment #36) > Our memcpy is not written in asm but in C, and it has the restrict qualifier > on src and dest. For my curiosity, can you point me to this implementation? I couldn't find a memcpy with restrict in the libc source, but I suspect that's just because I'm not familiar with the code base.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #40 from Sam James --- https://git.musl-libc.org/cgit/musl/tree/src/string/memcpy.c#n5
[Bug lto/112680] g++-13 segfault on std::regex_match with c++11 or above -O2 and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2023-11-23 Component|c++ |lto
[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666 --- Comment #2 from Francisco Paisana --- Jonathan Wakely, thanks a lot for your clarification. I finally got it. In summary, we established that: 1. if a type T (in my case C) has no user-defined ctor, it will be zero-initialized. 2. and for that T, "each non-static data member ... is zero-initialized." For others that might fall into the same trap as me, the important detail in 2 is that members are "zero-initialized" and not "value-initialized". If non-static data members were value-initialized (not the case!), then my original comment would have been true based on the clause (see https://en.cppreference.com/w/cpp/language/zero_initialization): "Zero-initialization is performed in the following situations: ... 2) As part of value-initialization sequence [...] for members of value-initialized class types that have no constructors." I wonder if there is a way to forbid the members of a class type from ever being zero-initialized in C++. In any case, we can mark this issue as solved.
[Bug c++/112680] g++-13 segfault on std::regex_match with c++11 or above -O2 and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680 Jonathan Wakely changed: What|Removed |Added Component|lto |c++ --- Comment #1 from Jonathan Wakely --- ASan shows there's a stack overflow, even without -flto=auto
[Bug c++/112680] g++-13 segfault on std::regex_match with c++11 or above -O2 and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680 Jonathan Wakely changed: What|Removed |Added Blocks||102445 --- Comment #2 from Jonathan Wakely --- It could just be the well known problem of resource exhaustion with our recursive std::regex implementation. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 [Bug 102445] [meta-bug] std::regex issues
[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666 Francisco Paisana changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Francisco Paisana --- This ended up being a misinterpretation of the C++ standard.
[Bug target/89316] ICE with -mforce-indirect-call and -fsplit-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316 --- Comment #15 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:2f3f8952ff1736dd6a087ddb4106077db3502bb9 commit r14-5784-g2f3f8952ff1736dd6a087ddb4106077db3502bb9 Author: Uros Bizjak Date: Thu Nov 23 15:45:59 2023 +0100 i386: Fix ICE with -mforce-indirect-call and -fsplit-stack [PR89316] With the above two options, use a temporary register regno (as returned from split_stack_prologue_scratch_regno) as an indirect call scratch register to hold __morestack function address. On 64-bit targets, two temporary registers are always available, so load the function addres in %r11 and call __morestack_large_model with its one-argument-register value rn %r10. On 32-bit targets, bail out with a "sorry" if the temporary register can not be obtained. On 32-bit targets, also emit PIC sequence that re-uses the obtained indirect call scratch register before moving the function address to it. We can not set up %ebx PIC register in this case, but __morestack is prepared for this situation and sets it up by itself. PR target/89316 gcc/ChangeLog: * config/i386/i386.cc (ix86_expand_split_stack_prologue): Obtain scratch regno when flag_force_indirect_call is set. On 64-bit targets, call __morestack_large_model when flag_force_indirect_call is set and on 32-bit targets with -fpic, manually expand PIC sequence to call __morestack. Move the function address to an indirect call scratch register. gcc/testsuite/ChangeLog: * g++.target/i386/pr89316.C: New test. * gcc.target/i386/pr112605-1.c: New test. * gcc.target/i386/pr112605-2.c: New test. * gcc.target/i386/pr112605.c: New test.
[Bug middle-end/112653] PTA should handle correctly escape information of values returned by a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #7 from Jan Hubicka ---
Thanks for explanation. I think it is quite common pattern that new object is
construted and worked on and later returned, so I think we ought to handle this
correctly.
Another example just came up in
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637878.html
We should gnerate same code for the following two functions:
#include
auto
f()
{
std::vector x;
x.reserve(10);
for (int i = 0; i < 10; ++i)
x.push_back(0);
return x;
}
auto
g()
{ return std::vector(10, 0); }
but we don't since we lose track of values stored in x after every call to new.
[Bug target/112672] [14 Regression] wrong code with __builtin_parityl() at -O and above on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672 --- Comment #5 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b2d17bdd45b582b93e89c00b04763a45f97d7a34 commit r14-5785-gb2d17bdd45b582b93e89c00b04763a45f97d7a34 Author: Uros Bizjak Date: Thu Nov 23 16:17:57 2023 +0100 i386: Wrong code with __builtin_parityl [PR112672] gen_parityhi2_cmp instruction clobbers its input operand, so use a temporary register in the call to gen_parityhi2_cmp. PR target/112672 gcc/ChangeLog: * config/i386/i386.md (parityhi2): Use temporary register in the call to gen_parityhi2_cmp. gcc/testsuite/ChangeLog: * gcc.target/i386/pr112672.c: New test.
[Bug target/89316] ICE with -mforce-indirect-call and -fsplit-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #16 from Uroš Bizjak --- Fixed for gcc-14.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #41 from post+gcc at ralfj dot de ---
> This entitles a compiler to emit asm equivalent to if (src==dest) system("rm
> -rf /") if it likes.
No it does not. restrict causes UB if the two pointers are used to access the
same memory. It has nothing to do with whether the pointers are equal. So it
would have to be "if (src==dest && n>0)" and the compiler would have to first
prove that "n>0" implies that later accesses through both pointers occur at
offset 0 (and at least one of them is a write).
But it's still UB to call this the way GCC does, that much I agree with.
> Our memcpy is not written in asm but in C, and it has the restrict qualifier
> on src and dest.
The question is, does that qualifier help? If you remove it, does the generated
assembly change in any way, does the performance change? If not, it clearly
doesn't matter and can just be removed. If yes, then yeah compilers clearly
shouldn't call this with identical ranges.
Basically, compiler devs are claiming that libc can support the src==dest case
"for free", without any noticeable cost to other uses of the function. libc
devs are claiming that compilers can insert a branch that tests for equality,
without any noticeable cost. Both of these are testable hypotheses. I'm not a
compiler dev nor a libc dev, I just want to make sure that my compiler and my
libc use the same contract when talking to each other -- but I hope someone who
is a compiler dev or a libc dev can go and actually test these hypotheses,
rather than just speculating about it as has been happening so far.
[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666 --- Comment #4 from Francisco Paisana --- One last thing, I might have misread this as well. > "Zero-initialization is performed in the following situations: > ... > 2) As part of value-initialization sequence [...] for members of > value-initialized class types that have no constructors." I was interpreting it as "members that have no ctors of classes are zero-init". However, this could be also read as "members of classes, where the classes have no ctor, are zero-init."
[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666 --- Comment #5 from Jonathan Wakely --- (In reply to Francisco Paisana from comment #4) > One last thing, I might have misread this as well. > > > "Zero-initialization is performed in the following situations: > > ... > > 2) As part of value-initialization sequence [...] for members of > > value-initialized class types that have no constructors." > > I was interpreting it as "members that have no ctors of classes are > zero-init". I don't even know what that would mean. > However, this could be also read as "members of classes, where > the classes have no ctor, are zero-init." This is the correct reading. N.B. cppreference is not the standard. It's usually an accurate paraphrasing of the standard, but it's not gospel.
[Bug middle-end/112679] ICE in expand_float, at optabs.cc:5724 with bitint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112679 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-11-23 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 56674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56674&action=edit gcc14-pr112679.patch Untested fix.
[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666 Sam James changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug libstdc++/112541] FAIL: 19_diagnostics/stacktrace/current.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112541 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 111641 ***
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Jonathan Wakely --- *** Bug 112541 has been marked as a duplicate of this bug. ***
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 Jonathan Wakely changed: What|Removed |Added Host|hppa*-*-linux*, | |*-*-solaris2.11 | Ever confirmed|0 |1 Build|hppa*-*-linux*, | |*-*-solaris2.11 | Target|hppa*-*-linux*, | |*-*-solaris2.11 | Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-23 --- Comment #4 from Jonathan Wakely --- Also seen on cris-elf and m68k-linux so not specific to armv8l-unknown-linux-gnueabihf It appears that __stacktrace_impl::_S_current returns an empty sequence of frames. It's possible that all the lambda frames are inlined, or skip+2 in stacktrace.cc causes us to skip real frames that we should keep, or maybe libbacktrace just doesn't work on this target.
[Bug tree-optimization/112673] [14 Regression] ICE verify_gimple failed since r14-5557-g6dd4c703be17fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at redhat dot com|jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I think this is a match.pd problem.
First vectorizer vectorizes the
_18 = VIEW_CONVERT_EXPR(x)[_16];
bitint.2[_16] = _18;
...
copying loop, before forwprop4 we have
vect__18.6_34 = VIEW_CONVERT_EXPR(x_35(D));
_8 = BIT_FIELD_REF ;
...
_18 = BIT_FIELD_REF ;
...
etc., which I think is valid, but during forwprop4 the
(simplify
(BIT_FIELD_REF (view_convert @0) @1 @2)
(BIT_FIELD_REF @0 @1 @2))
simplification kicks in and we create invalid
_18 = BIT_FIELD_REF ;
out of it, because x has _BitInt(256) type and so doesn't have mode precision.
tree-cfg.cc checking for BIT_FIELD_REF diagnoses:
if (INTEGRAL_TYPE_P (TREE_TYPE (op))
&& !type_has_mode_precision_p (TREE_TYPE (op)))
{
error ("%qs of non-mode-precision operand", code_name);
return true;
}
so maybe
--- gcc/match.pd.jj 2023-11-17 15:10:43.306043972 +0100
+++ gcc/match.pd2023-11-23 18:09:22.538414897 +0100
@@ -8285,7 +8285,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(simplify
(BIT_FIELD_REF (view_convert @0) @1 @2)
- (BIT_FIELD_REF @0 @1 @2))
+ (if (! INTEGRAL_TYPE_P (TREE_TYPE (@0))
+ || type_has_mode_precision_p (TREE_TYPE (@0)))
+ (BIT_FIELD_REF @0 @1 @2)))
(simplify
(BIT_FIELD_REF @0 @1 integer_zerop)
[Bug tree-optimization/112673] [14 Regression] ICE verify_gimple failed since r14-5557-g6dd4c703be17fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-23 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 56675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56675&action=edit gcc14-pr112673.patch Full untested patch.
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7a6a29c455e7755b501c0006e39beb4e56ec2729 commit r14-5794-g7a6a29c455e7755b501c0006e39beb4e56ec2729 Author: Jonathan Wakely Date: Tue Sep 19 13:23:13 2023 +0100 libstdc++: Define std::ranges::to for C++23 (P1206R7) [PR111055] This adds the std::ranges::to functions for C++23. The rest of P1206R7 is not yet implemented, i.e. the new constructors taking the std::from_range tag, and the new insert_range, assign_range, etc. member functions. std::ranges::to works with the standard containers even without the new constructors, so this is useful immediately. The __cpp_lib_ranges_to_container feature test macro can be defined now, because that only indicates support for the changes in , which are implemented by this patch. The __cpp_lib_containers_ranges macro will be defined once all containers support the new member functions. libstdc++-v3/ChangeLog: PR libstdc++/111055 * include/bits/ranges_base.h (from_range_t): Define new tag type. (from_range): Define new tag object. * include/bits/version.def (ranges_to_container): Define. * include/bits/version.h: Regenerate. * include/std/ranges (ranges::to): Define. * testsuite/std/ranges/conv/1.cc: New test. * testsuite/std/ranges/conv/2_neg.cc: New test. * testsuite/std/ranges/conv/version.cc: New test.
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #4 from Jonathan Wakely --- As the commit log says, I've added the std::ranges::to functions, but not the new members of the standard containers. I don't have immediate plans to add those new members, so I'm unassigning myself from this bug for now.
[Bug target/86776] Avr port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776 --- Comment #2 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:9a3c40af7f7dd218cc2ebaa3a70f3317f7316ceb commit r14-5796-g9a3c40af7f7dd218cc2ebaa3a70f3317f7316ceb Author: Georg-Johann Lay Date: Thu Nov 23 19:02:47 2023 +0100 AVR: PR target/86776: Implement CVE-2017-5753. gcc/ PR target/86776 * config/avr/avr.cc (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed.
[Bug target/86776] Avr port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Georg-Johann Lay --- Fixed.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86776, which changed state. Bug 86776 Summary: Avr port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/112609] [F2023] Restrictions on integer arguments to SYSTEM_CLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112609 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0c2ecfd4a29161d6c2bd3a83335387f42ff38ffe commit r14-5797-g0c2ecfd4a29161d6c2bd3a83335387f42ff38ffe Author: Harald Anlauf Date: Wed Nov 22 20:57:59 2023 +0100 Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609] Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK to have a decimal exponent range at least as large as a default integer, and that all integer arguments have the same kind type parameter. gcc/fortran/ChangeLog: PR fortran/112609 * check.cc (gfc_check_system_clock): Add checks on integer arguments to SYSTEM_CLOCK specific to F2023. * error.cc (notify_std_msg): Adjust to handle new features added in F2023. * gfortran.texi (_gfortran_set_options): Document GFC_STD_F2023_DEL, remove obsolete option GFC_STD_F2008_TS and fix enumeration values. * libgfortran.h (GFC_STD_F2023_DEL): Add and use in GFC_STD_OPT_F23. * options.cc (set_default_std_flags): Add GFC_STD_F2023_DEL. gcc/testsuite/ChangeLog: PR fortran/112609 * gfortran.dg/system_clock_1.f90: Add option -std=f2003. * gfortran.dg/system_clock_3.f08: Add option -std=f2008. * gfortran.dg/system_clock_4.f90: New test.
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #8 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7646b5d88056cf269ff555afe95bc361dcf5e5c0 commit r14-5798-g7646b5d88056cf269ff555afe95bc361dcf5e5c0 Author: Harald Anlauf Date: Wed Nov 22 21:45:46 2023 +0100 testsuite: fortran: fix invalid testcases (missing MOLD argument to NULL) The Fortran standard requires that NULL() passed to an assumed-rank dummy argument has a MOLD argument. gcc/testsuite/ChangeLog: PR fortran/104819 * gfortran.dg/assumed_rank_10.f90: Add MOLD argument to NULL(). * gfortran.dg/assumed_rank_8.f90: Likewise.
[Bug target/112643] [14 regression] including x86intrin.h is broken for -march=native (which adds -mno-avx10.1-256 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643 --- Comment #26 from anlauf at gcc dot gnu.org --- (In reply to Urs Janßen from comment #25) > (In reply to Haochen Jiang from comment #24) > > Patch aims to fix that: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html > > Yes, that solved the issue for me. Thanks. Works for me, too. Thanks.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #42 from Rich Felker --- > I'm not saying that such an implementation will be a good idea, but just a > remark: You could, in fact, keep restrict for the arguments in this case, > because the object pointed to by src and dest is not accessed at all when > src==dest. So this is correct code according to the standard. (The exact > semantics of restrict are a bit involved...) Nope, UB is invoked as soon as you evaluate src==dest, even with no dereferencing. The semantics of restrict are such that the behavior of the code must be unchanged if the pointer were replaced to a pointer to a relocated copy of the pointed-to object. Since this would alter the result of the == operator, that constraint is not satisfied and thereby the behavior is undefined.
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #43 from post+gcc at ralfj dot de --- That is not my reading of the standard, but absent a proper (formal, mathematical) spec I guess it is hard to tell. With your reading, "if ((uintptr_t)src == 0x400400)" is UB, since changing the "src" argument to a different copy located at that address would change the execution. I strongly doubt that is the intent of the standard.
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Summary|[14 Regression] ICE: in |[14 Regression] ICE: in |extract_insn, at|extract_insn, at |recog.cc:2804 |recog.cc:2804 |(unrecognizable insn) with |(unrecognizable insn) with |-O2 -mfma -mno-sse4.2 and |-O2 -mfma -mno-sse4.2 and |memcmp()|memcmp() since r14-5747 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-23 --- Comment #1 from Jakub Jelinek --- Started with r14-5747-g2e51fff7ce02a6105aa1acff57cbbdd8a767a33f
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #2 from Jakub Jelinek ---
Doesn't need the virtual method nor C++:
struct S { void *c; char d[16]; } a, b;
int
foo (void)
{
return __builtin_memcmp (a.d, b.d, sizeof (a.d)) != 0;
}
[Bug target/112676] [14 regression] ICE in extract_insn, at recog.cc:2804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676 --- Comment #2 from Manuel Lauss --- I think PR112681 is the same issue.
[Bug target/112676] [14 regression] ICE in extract_insn, at recog.cc:2804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 112681. *** This bug has been marked as a duplicate of bug 112681 ***
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 Andrew Pinski changed: What|Removed |Added CC||manuel.lauss at googlemail dot com --- Comment #3 from Andrew Pinski --- *** Bug 112676 has been marked as a duplicate of this bug. ***
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 --- Comment #4 from Jakub Jelinek --- Flags can be just -O2 -msse4.1 -mno-sse4.2 as well or even -O2 -msse4.2 -mno-avx. --- gcc/config/i386/i386-expand.cc.jj 2023-11-21 09:31:35.792395304 +0100 +++ gcc/config/i386/i386-expand.cc 2023-11-23 20:43:51.675586034 +0100 @@ -2453,6 +2453,8 @@ ix86_expand_branch (enum rtx_code code, /* Generate XOR since we can't check that one operand is zero vector. */ tmp = gen_reg_rtx (mode); + if (!vector_operand (op1, mode)) + op1 = force_reg (mode, op1); emit_insn (gen_rtx_SET (tmp, gen_rtx_XOR (mode, op0, op1))); tmp = gen_lowpart (p_mode, tmp); emit_insn (gen_rtx_SET (gen_rtx_REG (CCZmode, FLAGS_REG), seems to fix it.
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #5 from Jakub Jelinek ---
Or maybe better
--- gcc/config/i386/i386-expand.cc.jj 2023-11-21 09:31:35.792395304 +0100
+++ gcc/config/i386/i386-expand.cc 2023-11-23 20:57:57.128721762 +0100
@@ -2453,7 +2453,8 @@ ix86_expand_branch (enum rtx_code code,
/* Generate XOR since we can't check that one operand is zero
vector. */
tmp = gen_reg_rtx (mode);
- emit_insn (gen_rtx_SET (tmp, gen_rtx_XOR (mode, op0, op1)));
+ rtx ops[3] = { tmp, op0, op1 };
+ ix86_expand_vector_logical_operator (XOR, mode, ops);
tmp = gen_lowpart (p_mode, tmp);
emit_insn (gen_rtx_SET (gen_rtx_REG (CCZmode, FLAGS_REG),
gen_rtx_UNSPEC (CCZmode,
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 56676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56676&action=edit gcc14-pr112681.patch Full untested patch.
[Bug target/112672] [14 Regression] wrong code with __builtin_parityl() at -O and above on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:d035b57d51167af805ccc91ee0492c8b27e22184 commit r13-8092-gd035b57d51167af805ccc91ee0492c8b27e22184 Author: Uros Bizjak Date: Thu Nov 23 16:17:57 2023 +0100 i386: Wrong code with __builtin_parityl [PR112672] gen_parityhi2_cmp instruction clobbers its input operand, so use a temporary register in the call to gen_parityhi2_cmp. PR target/112672 gcc/ChangeLog: * config/i386/i386.md (parityhi2): Use temporary register in the call to gen_parityhi2_cmp. gcc/testsuite/ChangeLog: * gcc.target/i386/pr112672.c: New test. (cherry picked from commit b2d17bdd45b582b93e89c00b04763a45f97d7a34)
[Bug other/112684] New: ICE: in main, at toplev.cc:2327 with -ftarget-help -fdiagnostics-generate-patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112684 Bug ID: 112684 Summary: ICE: in main, at toplev.cc:2327 with -ftarget-help -fdiagnostics-generate-patch Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Compiler output: $ echo '' > testcase.c $ x86_64-pc-linux-gnu-gcc -ftarget-help -fdiagnostics-generate-patch testcase.c The following options are target specific: ... cc1: internal compiler error: in main, at toplev.cc:2327 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-5791-20231123115417-g24592abd68e-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-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231123 (experimental) (GCC)
[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #44 from Rich Felker --- My naive expectation is that "if ((uintptr_t)src == 0x400400)" is and should be UB, but I may be misremembering the details of the formalism by which the spec for restrict is implemented. If so, that's kinda a help, but I still think you would want to remove restrict from the arguments and apply it later, so that the fast-path head/tail copies can avoid any branch, and the check for equality can be deferred until it's known that there's a "body remainder" to copy. That's the part where you really want the benefits of restrict anyway -- without restrict it's not vectorizable because the compiler has to assume there might be nonexact overlap, in which case reordering the loads and stores in any way could change the result.
[Bug target/112681] [14 Regression] ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -O2 -mfma -mno-sse4.2 and memcmp() since r14-5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681 --- Comment #7 from Manuel Lauss --- (In reply to Jakub Jelinek from comment #6) > Created attachment 56676 [details] > gcc14-pr112681.patch > > Full untested patch. Fixes all ICEs I've seen today. Thank you!
[Bug fortran/112609] [F2023] Restrictions on integer arguments to SYSTEM_CLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112609 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed.
[Bug middle-end/112685] New: missed-optimization: division / modulo loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685
Bug ID: 112685
Summary: missed-optimization: division / modulo loops
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: goon.pri.low at gmail dot com
Target Milestone: ---
This code here:
unsigned ldiv(unsigned r) {
unsigned d = 0;
while (r >= 3) {
r -= 3;
d++;
}
return d;
}
Could be optimized to a single division and save decades of processing time.
This code here:
unsigned lmod(unsigned r) {
while (r >= 3) r -= 3;
return r;
}
Could be optimized to a single modulo.
Signed integers are a whole other problem, but maybe we could optimize loops
for them also.
[Bug middle-end/112685] missed-optimization: division / modulo loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/112685] missed-optimization: division / modulo loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685 --- Comment #1 from Andrew Pinski --- I thought I had saw this a while back. Note the Linux kernel does this kind of loop explicity to avoid the division though as the cases where it does is known to be only a few iterations (1 or 2) to get the division but the compiler does not have that information. Also I am not 100% sure this is always a win due to how slow the divide instruction is on many cores.
[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
Potential fix:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 81a14653a04..962274f5d25 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -986,8 +986,8 @@ resolve_common_vars (gfc_common_head *common_block, bool
named_common)
/* gfc_add_in_common may have been called before, but the reported
errors
have been ignored to continue parsing.
-We do the checks again here. */
- if (!csym->attr.use_assoc)
+We do the checks again here, unless the symbol is USE associated. */
+ if (!csym->attr.use_assoc && !csym->attr.used_in_submodule)
{
gfc_add_in_common (&csym->attr, csym->name, &common_block->where);
gfc_notify_std (GFC_STD_F2018_OBS, "COMMON block at %L",
[Bug middle-end/112683] Optimizing memcpy range by extending to word bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112683 Andrew Pinski changed: What|Removed |Added Component|target |middle-end --- Comment #1 from Andrew Pinski --- # RANGE [irange] long unsigned int [1, 16] MASK 0x1f VALUE 0x0 _2 = _1 + 1; # PT = nonlocal _3 = &__str_5(D)->_M_local_bufD.4676; # .MEM_7 = VDEF <.MEM_6> memcpyD.1403 (&._M_local_bufD.4676, _3, _2); The range information is there already for _2. Note the hugely expanded out instructions is a target issue though.
[Bug middle-end/112685] missed-optimization: division / modulo loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685
--- Comment #2 from gooncreeper ---
(In reply to Andrew Pinski from comment #1)
> I thought I had saw this a while back.
>
> Note the Linux kernel does this kind of loop explicity to avoid the division
> though as the cases where it does is known to be only a few iterations (1 or
> 2) to get the division but the compiler does not have that information.
>
>
> Also I am not 100% sure this is always a win due to how slow the divide
> instruction is on many cores.
This optimization should at least be applied for constant division / modulo.
If the user knows it will only be done for a certain amount of iterations they
could do something like this:
unsigned div(unsigned a) {
if (a > 9) return 3;
if (a > 6) return 2;
if (a > 3) return 1;
return 0;
}
unsigned mod(unsigned a) {
if (a > 9) return a - 9;
if (a > 6) return a - 6;
if (a > 3) return a - 3;
return a;
}
In most cases they probably won't intend on it only being a few iterations.
[Bug target/112686] New: [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -fsplit-stack -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Bug ID: 112686
Summary: [14 Regression] ICE: in gen_reg_rtx, at
emit-rtl.cc:1176 with -fsplit-stack -mcmodel=large
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 56677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56677&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -fsplit-stack -mcmodel=large testcase.c
during RTL pass: pro_and_epilogue
testcase.c: In function 'foo':
testcase.c:1:17: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1176
1 | void foo(void) {}
| ^
0x74c298 gen_reg_rtx(machine_mode)
/repo/gcc-trunk/gcc/emit-rtl.cc:1176
0x107cfae copy_to_mode_reg(machine_mode, rtx_def*)
/repo/gcc-trunk/gcc/explow.cc:650
0x19b175d ix86_expand_call(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
bool)
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:9710
0x18b70da ix86_expand_split_stack_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.cc:10565
0x1dec81a gen_split_stack_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.md:18458
0x1897c75 target_gen_split_stack_prologue
/repo/gcc-trunk/gcc/config/i386/i386.md:18213
0x111a64a make_split_prologue_seq
/repo/gcc-trunk/gcc/function.cc:5795
0x111a64a make_split_prologue_seq
/repo/gcc-trunk/gcc/function.cc:5788
0x111a83a thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6049
0x111b1b2 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6553
0x111b1b2 execute
/repo/gcc-trunk/gcc/function.cc:6634
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-5791-20231123115417-g24592abd68e-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-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)
[Bug tree-optimization/112645] missed-optimization: cswitch optimization missed in nested if-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112645 --- Comment #2 from gooncreeper --- I am going to move the second problem to it's own bug since I realize it actually quite a different problem, and deserves it's own thread of discussion.
