[Bug libstdc++/113335] [C++23] Implement LWG3617 function/packaged_task deduction guides and deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113335 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- Done for 14
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 --- Comment #1 from Uroš Bizjak --- Created attachment 57292 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57292=edit Patch that introduces umul_highpart RTX Please try the attached (untested) patch.
[Bug libstdc++/113318] [C++26] Implement P1885R12, Naming text encodings to demystify them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 --- Comment #8 from Jonathan Wakely --- I have a patch to add partial std::text_encoding support on Windows, using GetACP() and _MSVC_EXECUTION_CHARACTER_SET to query the system codepage and the execution charset codepage, and then mapping from Windows codepage identifiers to IANA mib values.
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739 Rainer Orth changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-02 --- Comment #4 from Rainer Orth --- I wonder how to handle this: while DejaGnu has an ucn effective-target keyword, the gdc.test testsuite doesn't use those at all.
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 --- Comment #10 from Hans-Peter Nilsson --- Looks like this also fixed one of the remaining FAILs logged in PR112580, specifically "FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)".
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #6) > (In reply to Francois-Xavier Coudert from comment #5) > > Not entirely, xtreme-header_b.C is still failing, as indicated above. See > > recently: > > https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805380.html > > > > FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) > > FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) > > Confirmed for cris-elf @r14-7254-g4f141b051ef4, reopening. But those two are gone. While the "FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)" was logged as PR112737, the "FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)" was covered in this ticket. Both were fixed by r14-8705-g3ba5be16a2be (but which tagged just PR112737).
[Bug target/113615] internal compiler error: in extract_insn, at recog.cc:2812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615 Matthias Klose changed: What|Removed |Added Summary|[14 Regression] internal|internal compiler error: in |compiler error: in |extract_insn, at |extract_insn, at|recog.cc:2812 |recog.cc:2812 | --- Comment #8 from Matthias Klose --- filed PR113720 for the alpha-linux-gnu ICE
[Bug target/113720] New: [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 Bug ID: 113720 Summary: [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 57291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57291=edit preprocessed source [There is PR113615, but I was asked to file a separate issue] works with 20240129, fails with 20240201 on alpha-linux-gnu // gcc version 14.0.1 20240131 (experimental) [master r14-8680-g2f14c0dbb78] (Debian 14-20240201-3) // // ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc: In function 'std::to_chars_result std::__floating_to_chars_shortest(char*, char*, T, chars_format) [with T = double]': // ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc:1306:3: error: unrecognizable insn: // 1306 | } // | ^ // (insn 712 711 713 22 (set (reg:DI 686 [ highparttmp_857 ]) // (truncate:DI (lshiftrt:TI (mult:TI (zero_extend:TI (subreg:DI (reg:TI 223 [ _319 ]) 0)) // (subreg:DI (reg:TI 225 [ _321 ]) 0)) // (const_int 64 [0x40] "../../../../../src/libstdc++-v3/src/c++17/ryu/d2s_intrinsics.h":254:27 -1 // (nil)) // during RTL pass: vregs // ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc:1306:3: internal compiler error: in extract_insn, at recog.cc:2812 // 0x7b030c _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) // ../../src/gcc/rtl-error.cc:108 // 0x7b0328 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) // ../../src/gcc/rtl-error.cc:116 // 0x7aed6e extract_insn(rtx_insn*) // ../../src/gcc/recog.cc:2812 // 0xe44cd5 instantiate_virtual_regs_in_insn // ../../src/gcc/function.cc:1611 // 0xe44cd5 instantiate_virtual_regs // ../../src/gcc/function.cc:1994 // 0xe44cd5 execute // ../../src/gcc/function.cc:2041 // Please submit a full bug report, with preprocessed source (by using -freport-bug). // Please include the complete backtrace with any bug report.
[Bug target/113615] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- (In reply to Matthias Klose from comment #6) > Created attachment 57290 [details] > preprocessed source > > see with trunk 20240131 building a cross compiler targeting alpha-linux-gnu, > attaching the preprocessed source. this worked with trunk 20240129. How is this related to the gcn bug?
[Bug target/113615] internal compiler error: in extract_insn, at recog.cc:2812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #6 from Matthias Klose --- Created attachment 57290 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57290=edit preprocessed source see with trunk 20240131 building a cross compiler targeting alpha-linux-gnu, attaching the preprocessed source. this worked with trunk 20240129. // ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc: In function 'std::to_chars_result std::__floating_to_chars_shortest(char*, char*, T, chars_format) [with T = double]': // ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc:1306:3: error: unrecognizable insn: // 1306 | } // | ^ // (insn 712 711 713 22 (set (reg:DI 686 [ highparttmp_857 ]) // (truncate:DI (lshiftrt:TI (mult:TI (zero_extend:TI (subreg:DI (reg:TI 223 [ _319 ]) 0)) // (subreg:DI (reg:TI 225 [ _321 ]) 0)) // (const_int 64 [0x40] "../../../../../src/libstdc++-v3/src/c++17/ryu/d2s_intrinsics.h":254:27 -1 // (nil)) // during RTL pass: vregs // ../../../../../src/libstdc++-v3/src/c++17/floating_to_chars.cc:1306:3: internal compiler error: in extract_insn, at recog.cc:2812 // 0x7b030c _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) // ../../src/gcc/rtl-error.cc:108 // 0x7b0328 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) // ../../src/gcc/rtl-error.cc:116 // 0x7aed6e extract_insn(rtx_insn*) // ../../src/gcc/recog.cc:2812 // 0xe44cd5 instantiate_virtual_regs_in_insn // ../../src/gcc/function.cc:1611 // 0xe44cd5 instantiate_virtual_regs // ../../src/gcc/function.cc:1994 // 0xe44cd5 execute // ../../src/gcc/function.cc:2041 // Please submit a full bug report, with preprocessed source (by using -freport-bug).
[Bug c++/113719] g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 --- Comment #1 from Rainer Orth --- Created attachment 57289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57289=edit 32- bit i386-pc-solaris2.11 pr103696.C.265t.optimized
[Bug c++/113719] New: g++.target/i386/pr103696.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719 Bug ID: 113719 Summary: g++.target/i386/pr103696.C FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i?86-pc-solaris2.11, amd64-pc-solaris2.11 g++.target/i386/pr103696.C FAILs on Solaris/x86 (both 32 and 64-bit) since 20221124: FAIL: g++.target/i386/pr103696.C scan-tree-dump-not optimized "lambda" I'm attaching the dump.
[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711 --- Comment #2 from H.J. Lu --- Created attachment 57288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57288=edit Add BN constraint for APX NDD instructions Since the instruction length of APX NDD instructions: op imm, mem, reg may exceed the size limit of 15 byes, add BN constraint which is a memory operand when TARGET_APX_NDD is disabled. For all TARGET_APX_NDD patterns with op imm, mem, reg replace m with BN in operand 1 constraint for alternative with immediate operand 2. This patch isn't complete. We need to update all relevant TARGET_APX_NDD patterns.
[Bug tree-optimization/110422] asm goto vs SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:fda015646b9450a2147bd9f01e49e3836b724da4 commit r12-10128-gfda015646b9450a2147bd9f01e49e3836b724da4 Author: Martin Jambor Date: Fri Feb 2 13:27:50 2024 +0100 sra: Disqualify bases of operands of asm gotos PR 110422 shows that SRA can ICE assuming there is a single edge outgoing from a block terminated with an asm goto. We need that for BB-terminating statements so that any adjustments they make to the aggregates can be copied over to their replacements. Because we can't have that after ASM gotos, we need to punt. gcc/ChangeLog: 2024-01-17 Martin Jambor PR tree-optimization/110422 * tree-sra.cc (scan_function): Disqualify bases of operands of asm gotos. gcc/testsuite/ChangeLog: 2024-01-17 Martin Jambor PR tree-optimization/110422 * gcc.dg/torture/pr110422.c: New test. (cherry picked from commit 2b7204c52392c1c0da9c91a5feae0c44018a6f37)
[Bug tree-optimization/113718] New: std::bit_cast making the compiler generate unnecessary code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113718
Bug ID: 113718
Summary: std::bit_cast making the compiler generate unnecessary
code.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
Consider:
#include
void f();
auto const p1 =
auto const p2 = std::bit_cast();
bool a() {
return p1 == p2;
}
The code emitted for `a` should be the same as-if `return true;` but the usage
of a "no-op" `std::bit_cast` muddies the waters and the compiler generates:
a():
cmp QWORD PTR p2[rip], OFFSET FLAT:_Z1fv
sete al
ret
FWIW: The following changes make the compiler to generate more efficient code:
1. Move `p1` and `p2` inside the body of `a`.
2. Replace `std::bit_cast` with `static_cast`.
3. Remove the cast altogether.
Things get terribly worse if `p1` and `p2` are made `static` and moved inside
the body of `a`.
Given that the compiler can get confused by a "no-op" `std::bit_cast`, I wonder
if it would do the same for more interesting code than this toy example.
https://godbolt.org/z/daWe5Yod8
[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 --- Comment #14 from Tamar Christina --- Awesome! Feel free to reach out if you need any help. It’s likely easier to start with add and sub and get things pipe cleaned and expand incrementally than to try and do it all at once.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f5caef53e7808fef2baf8e6ffac230b9863 commit r14-8750-g9f5caef53e7808fef2baf8e6ffac230b9863 Author: Jakub Jelinek Date: Fri Feb 2 11:46:34 2024 +0100 libgcc: Export XF, TF, HF and BFmode specific _BitInt symbols from libgcc_s.so.1 [PR113700] Rainer pointed out that __PFX__ and __FIXPTPFX__ prefix replacement is done solely for libgcc-std.ver.in and not for the *.ver files in config. I've used the __PFX__ prefix even in config/i386/libgcc-glibc.ver because it was used for similar symbols in libgcc-std.ver.in, and that results in those symbols being STB_LOCAL in libgcc_s.so.1. Tests still work because gcc by default uses -static-libgcc when linking (unlike g++ etc.), but would have failed when using -shared-libgcc (but I see nothing in the testsuite actually testing with -shared-libgcc, so am not adding tests). With the patch, libgcc_s.so.1 now exports __fixtfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT __fixxfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitintbf@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitinthf@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitinttf@@GCC_14.0.0 FUNC GLOBAL DEFAULT __floatbitintxf@@GCC_14.0.0 FUNC GLOBAL DEFAULT on x86_64-linux which it wasn't before. 2024-02-02 Jakub Jelinek PR target/113700 * config/i386/libgcc-glibc.ver (GCC_14.0.0): Remove __PFX prefixes from symbol names.
[Bug libstdc++/108636] [10 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 --- Comment #12 from Jonathan Wakely --- That's now fixed for 12.4
[Bug middle-end/113699] during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) with _BitInt() used in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113699 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug libstdc++/108636] [10 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4b36925576d1097b20cddd29cf96c5b9ecfffc3d commit r12-10127-g4b36925576d1097b20cddd29cf96c5b9ecfffc3d Author: Jonathan Wakely Date: Thu Feb 1 18:37:34 2024 + libstdc++: Force-inline shared_ptr::operator bool() for C++20 [PR108636] This avoids a linker error with -fkeep-inline-functions when including . We can't backport the fix from trunk because it adds an export to the shared library. By marking the "missing" symbol always_inline for C++20 mode we don't need a definition in the library. libstdc++-v3/ChangeLog: PR libstdc++/108636 * include/bits/shared_ptr_base.h (__shared_ptr::operator bool): Add always_inline attribute for C++20 and later.
[Bug tree-optimization/113692] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119 --- Comment #7 from Jan Hubicka --- Local aliases are created by ipa-visibility pass. Most common case is that function is declared inline but ELF superposition rules say that the symbol can be overwritten by a different library. Since GCC knows that all implementaitons must be equivalent, it can force calls within DSO to be direct. I am not quite sure how this confuses stack unwinding on Solaris? For live patching, if you want to patch inline function, one definitely needs to look for places it has been inlined to. However in the situation the function got offlined, I think live patching should just work, since it will place jump in the beggining of function body. The logic for creating local aliases is in ipa-visibility.cc. Adding command line option to control it is not hard. There are other transformations we do there - like breaking up comdat groups and other things. part aliases are controlled by -fno-partial-inlining, isra by -fno-ipa-sra. There is also ipa-cp controlled by -fno-ipa-prop. We also do alises as part of openMP offlining and LTO partitioning that are kind of mandatory (there is no way to produce correct code without them).
[Bug middle-end/113705] [14 Regression] ICE in decompose, at wide-int.h:1049 on aarch64-linux-gnu since r14-8680-g2f14c0dbb78985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113705 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/113692] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692 --- Comment #6 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fb28d5cdae149f08f0d472c210a5143a64771410 commit r14-8747-gfb28d5cdae149f08f0d472c210a5143a64771410 Author: Jakub Jelinek Date: Fri Feb 2 11:28:31 2024 +0100 lower-bitint: Handle casts from large/huge _BitInt to pointer/reference types [PR113692] I thought one needs to cast first to pointer-sized integer before casting to pointer, but apparently that is not the case. So the following patch arranges for the large/huge _BitInt to pointer/reference conversions to use the same code as for conversions of them to small integral types. 2024-02-02 Jakub Jelinek PR tree-optimization/113692 * gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Handle casts from large/huge BITINT_TYPEs to POINTER_TYPE/REFERENCE_TYPE as final_cast_p. * gcc.dg/bitint-82.c: New test.
[Bug tree-optimization/113691] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 with function declaration with no parameter specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113691 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a049acabcb11d6ae9e54c81e5835e4f3372e80fb commit r14-8748-ga049acabcb11d6ae9e54c81e5835e4f3372e80fb Author: Jakub Jelinek Date: Fri Feb 2 11:29:25 2024 +0100 testsuite: Add another bitint testcase [PR113691] This is fixed by the PR113692 patch. 2024-02-02 Jakub Jelinek PR tree-optimization/113691 * gcc.dg/bitint-83.c: New test.
[Bug middle-end/113699] during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) with _BitInt() used in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113699 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:49e75666c592d23dfa17f062974e660edd01d5fb commit r14-8746-g49e75666c592d23dfa17f062974e660edd01d5fb Author: Jakub Jelinek Date: Fri Feb 2 11:27:37 2024 +0100 lower-bitint: Handle uninitialized large/huge SSA_NAMEs as inline asm inputs [PR113699] Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME arguments, var_to_partition will not work for those, but unlike calls where we just create a new uninitialized SSA_NAME here we need to change the inline asm input to be an uninitialized VAR_DECL. 2024-02-02 Jakub Jelinek PR middle-end/113699 * gimple-lower-bitint.cc (bitint_large_huge::lower_asm): Handle uninitialized large/huge _BitInt SSA_NAME inputs. * gcc.dg/bitint-81.c: New test.
[Bug libstdc++/90276] PSTL tests fail in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 --- Comment #11 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:723a7c1ad29523b9ddff53c7b147bffea56fbb63 commit r14-8743-g723a7c1ad29523b9ddff53c7b147bffea56fbb63 Author: Jonathan Wakely Date: Wed Jan 31 10:41:49 2024 + libstdc++: Avoid reusing moved-from iterators in PSTL tests [PR90276] The reverse_invoker utility for PSTL tests uses forwarding references for all parameters, but some of those parameters get forwarded to move constructors which then leave the objects in a moved-from state. When the parameters are forwarded a second time that results in making new copies of moved-from iterators. For libstdc++ debug mode iterators, the moved-from state is singular, which means copying them will abort at runtime. The fix is to make copies of iterator arguments instead of forwarding them. The callers of reverse_invoker::operator() also forward the iterators multiple times, but that's OK because reverse_invoker accepts them by forwarding reference but then breaks the chain of forwarding and copies them as lvalues. libstdc++-v3/ChangeLog: PR libstdc++/90276 * testsuite/util/pstl/test_utils.h (reverse_invoker): Do not use perfect forwarding for iterator arguments. --- Comment #12 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a6286584e5536d1853a851b8c2ac3196956e3068 commit r14-8744-ga6286584e5536d1853a851b8c2ac3196956e3068 Author: Jonathan Wakely Date: Thu Feb 1 10:06:15 2024 + libstdc++: Fix invalid order in PSTL inplace_merge test [PR90276] This looks like a typo in the upstream test that causes a failure in debug mode. It has been reported upstream. libstdc++-v3/ChangeLog: PR libstdc++/90276 * testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix comparison function to use less-than instead of equality.
[Bug middle-end/113705] [14 Regression] ICE in decompose, at wide-int.h:1049 on aarch64-linux-gnu since r14-8680-g2f14c0dbb78985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113705 --- Comment #10 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a8f335ccb61bf6105192a4197ef2d84900614dc1 commit r14-8742-ga8f335ccb61bf6105192a4197ef2d84900614dc1 Author: Jakub Jelinek Date: Fri Feb 2 11:25:13 2024 +0100 tree-ssa-math-opts: Fix is_widening_mult_rhs_p - unbreak bootstrap [PR113705] On Tue, Jan 30, 2024 at 07:33:10AM -, Roger Sayle wrote: + wide_int bits = wide_int::from (tree_nonzero_bits (rhs), + prec, + TYPE_SIGN (TREE_TYPE (rhs))); ... > + if (gimple_assign_rhs_code (stmt) == BIT_AND_EXPR > + && TREE_CODE (gimple_assign_rhs2 (stmt)) == INTEGER_CST > + && wi::to_wide (gimple_assign_rhs2 (stmt)) > + == wi::mask (hprec, false, prec)) This change broke bootstrap on aarch64-linux. The problem can be seen even on the reduced testcase. The IL on the unreduced testcase before widening_mul has: # val_583 = PHI ... pretmp_266 = MEM[(const struct wide_int_storage *)].len; _264 = pretmp_266 & 65535; ... _176 = (sizetype) val_583; _439 = (sizetype) _264; _284 = _439 * 8; _115 = _176 + _284; where 583/266/264 have unsigned int type and 176/439/284/115 have sizetype. widening_mul first turns that into: # val_583 = PHI ... pretmp_266 = MEM[(const struct wide_int_storage *)].len; _264 = pretmp_266 & 65535; ... _176 = (sizetype) val_583; _439 = (sizetype) _264; _284 = _264 w* 8; _115 = _176 + _284; and then is_widening_mult_rhs_p is called, with type sizetype (64-bit), rhs _264, hprec 32 and prec 64. Now tree_nonzero_bits (rhs) is 65535, so bits is 64-bit wide_int 65535, stmt is BIT_AND_EXPR, but we ICE on the wi::to_wide (gimple_assign_rhs2 (stmt)) == wi::mask (hprec, false, prec) comparison because wi::to_wide on gimple_assign_rhs2 (stmt) - unsigned int 65535 gives 32-bit wide_int 65535, while wi::mask (hprec, false, prec) gives 64-bit wide_int 0x and comparison between different precision wide_ints is forbidden. The following patch fixes it the same way how bits is computed earlier, by calling wide_int::from on the wi::to_wide (gimple_assign_rhs2 (stmt)), so we compare 64-bit 65535 with 64-bit 0x. 2024-02-02 Jakub Jelinek PR middle-end/113705 * tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use wide_int_from around wi::to_wide in order to compare value in prec precision. * g++.dg/opt/pr113705.C: New test.
[Bug libstdc++/90276] PSTL tests fail in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 --- Comment #11 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:723a7c1ad29523b9ddff53c7b147bffea56fbb63 commit r14-8743-g723a7c1ad29523b9ddff53c7b147bffea56fbb63 Author: Jonathan Wakely Date: Wed Jan 31 10:41:49 2024 + libstdc++: Avoid reusing moved-from iterators in PSTL tests [PR90276] The reverse_invoker utility for PSTL tests uses forwarding references for all parameters, but some of those parameters get forwarded to move constructors which then leave the objects in a moved-from state. When the parameters are forwarded a second time that results in making new copies of moved-from iterators. For libstdc++ debug mode iterators, the moved-from state is singular, which means copying them will abort at runtime. The fix is to make copies of iterator arguments instead of forwarding them. The callers of reverse_invoker::operator() also forward the iterators multiple times, but that's OK because reverse_invoker accepts them by forwarding reference but then breaks the chain of forwarding and copies them as lvalues. libstdc++-v3/ChangeLog: PR libstdc++/90276 * testsuite/util/pstl/test_utils.h (reverse_invoker): Do not use perfect forwarding for iterator arguments. --- Comment #12 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a6286584e5536d1853a851b8c2ac3196956e3068 commit r14-8744-ga6286584e5536d1853a851b8c2ac3196956e3068 Author: Jonathan Wakely Date: Thu Feb 1 10:06:15 2024 + libstdc++: Fix invalid order in PSTL inplace_merge test [PR90276] This looks like a typo in the upstream test that causes a failure in debug mode. It has been reported upstream. libstdc++-v3/ChangeLog: PR libstdc++/90276 * testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix comparison function to use less-than instead of equality.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #8 from Jakub Jelinek --- The reason tests work is that we default to -static-libgcc in C, which contains the symbols.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #7 from Jakub Jelinek --- I didn't know what it is. But seems you're right, on x86_64-linux 252: 0001c1c0 1974 FUNCLOCAL DEFAULT 13 __floatbitintbf 253: 0001b200 1972 FUNCLOCAL DEFAULT 13 __fixxfbitint 262: 0001b9c0 2046 FUNCLOCAL DEFAULT 13 __floatbitinthf 266: 0001c980 1934 FUNCLOCAL DEFAULT 13 __floatbitintxf 271: 00019220 2271 FUNCLOCAL DEFAULT 13 __fixtfbitint 276: 00019b00 2166 FUNCLOCAL DEFAULT 13 __floatbitinttf aren't exported even when they should be. Let me change it.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- When looking at the 64-bit libgcc_s.so.1 on both Solaris/x86 and Linux/i686, I noticed that all the new GCC_14.0.0 symbols from libgcc-glibc.ver (and now libgcc-sol2.ver) have been demoted to local. IIUC, this happens because the __PFX__ handling (substitution by $(LIBGCC_VER_GNU_PREFIX) as needed) is only applied to libgcc-std.ver.in by Makefile.in. In the i386/libgcc-*.ver files, this substitution doesn't happen, the literal "__PFX__fixxfbitint" etc. symbols are not found in any object, so the unprefixed ones are turned local. >From what I could see in config.host, LIBGCC_VER_GNU_PREFIX only applies to non-x86 targets. Maybe we can just remove __PFX__ from i386/libgcc-*.ver? Jakub?
[Bug tree-optimization/113716] Missed optimization: (2/a)*b*(!b) => 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113716 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Maybe ranger could figure out that at least one of the multiplication operands is zero in this case, because the second one is non-zero only if the first one is zero?
[Bug middle-end/113705] [14 Regression] ICE in decompose, at wide-int.h:1049 on aarch64-linux-gnu since r14-8680-g2f14c0dbb78985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113705 Matthias Klose changed: What|Removed |Added Target|aarch64-linux-gnu, |aarch64-linux-gnu, |loongarch64-linux-gnu |loongarch64-linux-gnu, ||mips64el-linux-gnu --- Comment #9 from Matthias Klose --- also works on aarch64-linux-gnu and mips64el-linux-gnu
[Bug tree-optimization/113716] Missed optimization: (2/a)*b*(!b) => 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113716 --- Comment #2 from Andrew Pinski --- Or what we could get in reassociation: _2 = b_6(D) == 0; _3 = (int) _2; _4 = _3 * b_6(D); WHich is just: (simplify (mult:c @0 (convert (eq:c@2 @0 integer_zerop@1))) @0) We already handle the non-zero case later on ...
[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Gaius Mulley --- Thanks for re-testing - and as suggested I've opened up PR 113717 for the remaining m2date and testdate failures.
[Bug modula2/113717] New: m2date and testclock failures on all darwin platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113717 Bug ID: 113717 Summary: m2date and testclock failures on all darwin platforms Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- When running the m2 testsuite these failures are seen on all Darwin platforms: Running target unix FAIL: gm2/iso/run/pass/m2date.mod execution, -g FAIL: gm2/iso/run/pass/m2date.mod execution, -O FAIL: gm2/iso/run/pass/m2date.mod execution, -O -g FAIL: gm2/iso/run/pass/m2date.mod execution, -Os FAIL: gm2/iso/run/pass/m2date.mod execution, -O3 -fomit-frame-pointer FAIL: gm2/iso/run/pass/m2date.mod execution, -O3 -fomit-frame-pointer -finline-functions FAIL: gm2/iso/run/pass/testclock.mod execution, -g FAIL: gm2/iso/run/pass/testclock.mod execution, -O FAIL: gm2/iso/run/pass/testclock.mod execution, -O -g FAIL: gm2/iso/run/pass/testclock.mod execution, -Os FAIL: gm2/iso/run/pass/testclock.mod execution, -O3 -fomit-frame-pointer FAIL: gm2/iso/run/pass/testclock.mod execution, -O3 -fomit-frame-pointer -finline-functions === gm2 Summary === # of expected passes13016 # of unexpected failures12
[Bug tree-optimization/113716] Missed optimization: (2/a)*b*(!b) => 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113716 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-02-02 Status|UNCONFIRMED |NEW Keywords||missed-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed. The IR we get is: _2 = b_6(D) == 0; _10 = _2 ? _1 : 0; _4 = b_6(D) * _10; I wonder if we could do something like: (simplify (mult:c (cond:s @0 @1 integer_zerop@2) @3) (cond @0 (mult @1 @3) @2)) But that won't solve it. Maybe something like: (simplify (mult:c @0 (cond (eq:c @0 integer_zerop@1) @2 integer_zerop)) @1) But both of those seems very specific patterns. Maybe something more generic is needed though.
[Bug tree-optimization/113716] New: Missed optimization: (2/a)*b*(!b) => 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113716
Bug ID: 113716
Summary: Missed optimization: (2/a)*b*(!b) => 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
Target Milestone: ---
Hello, we noticed that the code below can be optimized as stated in the title
((2/a)*b*(!b) => 0), but gcc -O3 -fwrapv missed it.
https://godbolt.org/z/34Ejoxeqo
int m;
void func(int a, int b){
a=(2/a)*b;
m=a*(!b);
}
GCC -O3 -fwrapv:
func(int, int):
xor edx, edx
mov eax, 2
idivedi
xor edx, edx
testesi, esi
cmovne eax, edx
imuleax, esi
mov DWORD PTR m[rip], eax
ret
Expected code (Clang):
func(int, int): # @func(int, int)
mov dword ptr [rip + m], 0
ret
Thank you very much for your time and effort! We look forward to hearing from
you.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 Rainer Orth changed: What|Removed |Added CC||andreast at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target|x86_64-*-solaris* |x86_64-*-solaris*, ||i?86-*-solaris* Target Milestone|--- |14.0 --- Comment #5 from Rainer Orth --- The problem is even more widespread than Solaris/x86: beside i386/libgcc-sol2.ver, there are i386/libgcc-darwin.ver (where the versions end at GCC_12.0.0) and i386/libgcc-bsdver (stops at GCC_7.0.0, used by both t-freebsd and t-dragonfly; the latter has no listed maintainer). I wonder if we should add a prominent note to the end of i386/libgcc-glibc.ver to notify other affected maintainers about additions. Those are way too easy to overlook right now.
[Bug tree-optimization/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> On Solaris, when compiling this
>
> #include
>
> __attribute__ ((weak))
> int
> f (int a)
> {
>return memchr ("aE", a, 2) != NULL;
> }
>
> as C++ source, std::memchr is used and GCC doesn't treat std::memchr as
> BUILT_IN_MEMCHR.
I see. I'm testing a patch to directly define/declare NULL, size_t and
memchr instead of including . This should still test what the
testcase is supposed to test, I believe.
[Bug target/112864] [14 regression] Many libphobos tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864 --- Comment #3 from Iain Sandoe --- I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.
[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 --- Comment #8 from Iain Sandoe --- I suppose we are going to have to consider back porting this (and the fixes for data layout), if we want to avoid the same problems on open branches.
[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #14 from Iain Sandoe --- I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.
[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 --- Comment #5 from Iain Sandoe --- I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.
[Bug target/112864] [14 regression] Many libphobos tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864
--- Comment #2 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:f4aa644dbbbde8c97f41c8abfbb7925c2242e31f
commit r14-8734-gf4aa644dbbbde8c97f41c8abfbb7925c2242e31f
Author: Iain Sandoe
Date: Sat Jan 27 15:50:15 2024 +
testsuite, libphobos: Update link flags [PR112864].
The regressions here are primarily from duplicated '-B' additions.
We remove the duplicate on the link line.
We also make sure that platforms with extensions other than .so for
shared libs will have the correct paths.
PR target/112864
libphobos/ChangeLog:
* testsuite/lib/libphobos.exp: Use ${shlib_ext} instead of
hard-wiring '.so'.
* testsuite/testsuite_flags.in: Remove duplicate -B option
for spec file path.
[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 --- Comment #7 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:bec7100445f07259d5df69c9f442ea72a90fc37e commit r14-8733-gbec7100445f07259d5df69c9f442ea72a90fc37e Author: Iain Sandoe Date: Wed Jan 24 08:05:41 2024 + testsuite, Objective-C++: Update link flags [PR112863]. These regressions are caused by missing or duplicate runpaths which now fire linker warnings. We need to add options to locate libobjc (and on Darwin libobjc-gnu) along with libstdc++. Usually '-L' options are added to point to the relevant directories for the uninstalled libraries. In cases where libraries are available as both shared and convenience some additional checks are made. For some targets -static- options are handled by specs substitution and need a '-B' option rather than '-L'. For Darwin, when embedded runpaths are in use (the default for all versions after macOS 10.11), '-B' is also needed to provide the runpath. When '-B' is used, this results in a '-L' for each path that exists (so that appending a '-L' as well is a needless duplicate). There are also cases where tools warn for duplicates, leading to spurious fails. PR target/112863 gcc/testsuite/ChangeLog: * lib/obj-c++.exp: Decide on whether to present -B or -L to reference the paths to uninstalled libobjc/libobjc-gnu and libstdc++ and use that to generate the link flags.
[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #13 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:e439c7827f5c5723fdd7df9c5fac55319db204af commit r14-8732-ge439c7827f5c5723fdd7df9c5fac55319db204af Author: Iain Sandoe Date: Wed Jan 24 08:05:30 2024 + testsuite, gfortran: Update link flags [PR112862]. The regressions here are caused by two issues: 1. In some cases there is no generated runpath for libatomic 2. In other cases there are duplicate paths. This patch simplifies the addition of the options in the main gfortran exp and removes the duplicates elewhere. We need to add options to locate libgfortran and the dependent libs libquadmath (supporting REAL*16) and libatomic (supporting operations used by coarrays). Usually '-L' options are added to point to the relevant directories for the uninstalled libraries. In cases where libraries are available as both shared and convenience some additional checks are made. For some targets -static- options are handled by specs substitution and need a '-B' option rather than '-L'. For Darwin, when embedded runpaths are in use (the default for all versions after macOS 10.11), '-B' is also needed to provide the runpath. When '-B' is used, this results in a '-L' for each path that exists (so that appending a '-L' as well is a needless duplicate). There are also cases where tools warn for duplicates, leading to spurious fails. PR target/112862 gcc/testsuite/ChangeLog: * gfortran.dg/coarray/caf.exp: Remove duplicate additions of libatomic handling. * gfortran.dg/dg.exp: Likewise. * lib/gfortran.exp: Decide on whether to present -B or -L to reference the paths to uninstalled libgfortran, libqadmath and libatomic and use that to generate the link flags.
[Bug c/113715] New: RISC-V: If the Zcmp is enabled, the a0 register operates abnormally when the program returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715
Bug ID: 113715
Summary: RISC-V: If the Zcmp is enabled, the a0 register
operates abnormally when the program returns
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mumuxi_ll at outlook dot com
Target Milestone: ---
When compiling the following test.c code with the options
-march=rv32ima_zca_zcb_zcmp_zcmt -mabi=ilp32 -Os, a bug appears when gcc
enables zcmp. In the disassembly dump.txt, it can be observed that when
executing the bne instruction in test_err, a0 is not set to 0 as the function
return value.
Source code:
void test_1(int onoff)
{
for (volatile int i = 0; i < 100; i ++) {
}
}
int test_err(void *param, int mode, int *saveAddr)
{
if (mode == 2) {
test_1(1);
}
return 0;
}
int main()
{
int ret = test_err((void *)0x123456, 3, (int *)0x123456);
for (volatile int i = ret; i < 100; i ++) {
ret = i * i;
}
return ret;
}
GCC ASM:
test_1:
addisp,sp,-16
sw zero,12(sp)
li a4,99
.L2:
lw a5,12(sp)
ble a5,a4,.L3
addisp,sp,16
jr ra
.L3:
lw a5,12(sp)
addia5,a5,1
sw a5,12(sp)
j .L2
test_err:
li a5,2
bne a1,a5,.L8
li a0,1
cm.push {ra}, -16
calltest_1
cm.popretz {ra}, 16
.L8:
ret
main:
addisp,sp,-16
sw zero,12(sp)
li a0,0
li a3,99
.L12:
lw a5,12(sp)
ble a5,a3,.L13
addisp,sp,16
jr ra
.L13:
lw a0,12(sp)
lw a4,12(sp)
mul a0,a0,a4
lw a4,12(sp)
addia4,a4,1
sw a4,12(sp)
j .L12
[Bug tree-optimization/113134] gcc does not version loops with early break conditions that don't have side-effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #22 from JuzheZhong ---
I have done this following experiment.
diff --git a/gcc/tree-ssa-loop-ivcanon.cc b/gcc/tree-ssa-loop-ivcanon.cc
index bf017137260..8c36cc63d3b 100644
--- a/gcc/tree-ssa-loop-ivcanon.cc
+++ b/gcc/tree-ssa-loop-ivcanon.cc
@@ -1260,6 +1260,39 @@ canonicalize_loop_induction_variables (class loop *loop,
may_be_zero = false;
}
+ if (!exit)
+ {
+ auto_vec exits = get_loop_exit_edges (loop);
+ exit = exits[0];
+ class tree_niter_desc desc1;
+ class tree_niter_desc desc2;
+ if (number_of_iterations_exit (loop, exits[0], , false)
+ && number_of_iterations_exit (loop, exits[1], , false))
+ {
+ niter = fold_build2 (MIN_EXPR, unsigned_type_node, desc1.niter,
+ desc2.niter);
+ create_canonical_iv (loop, exit, niter);
+ gcond *cond_stmt;
+ class nb_iter_bound *elt;
+ for (elt = loop->bounds; elt; elt = elt->next)
+ {
+ if (elt->is_exit
+ && !wi::ltu_p (loop->nb_iterations_upper_bound,
+elt->bound))
+ {
+ cond_stmt = as_a (elt->stmt);
+ break;
+ }
+ }
+ if (exits[1]->flags & EDGE_TRUE_VALUE)
+ gimple_cond_make_false (cond_stmt);
+ else
+ gimple_cond_make_true (cond_stmt);
+ update_stmt (cond_stmt);
+ return false;
+ }
+ }
+
I know the check is wrong just for experiment, Then:
[local count: 69202658]:
_21 = (unsigned int) N_13(D);
_22 = MIN_EXPR <_21, 1001>; > Use MIN_EXPR as the check.
_23 = _22 + 1;
goto ; [100.00%]
[local count: 1014686025]:
_1 = (long unsigned int) i_9;
_2 = _1 * 4;
_3 = a_14(D) + _2;
_4 = *_3;
_5 = b_15(D) + _2;
_6 = *_5;
_7 = c_16(D) + _2;
_8 = _4 + _6;
*_7 = _8;
if (0 != 0)
goto ; [1.00%]
else
goto ; [99.00%]
[local count: 1004539166]:
i_18 = i_9 + 1;
[local count: 1073741824]:
# i_9 = PHI <0(2), i_18(4)>
# ivtmp_19 = PHI <_23(2), ivtmp_20(4)>
ivtmp_20 = ivtmp_19 - 1;
if (ivtmp_20 != 0)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 69202658]:
return;
Then it can vectorize.
I am not sure whether it is the right place to put the codes.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #13 from Andrew Pinski --- (In reply to Bruno Haible from comment #12) > For reference: The Gnulib unit tests for posix_spawn* pass on > sparc-linux-gnu (both in 32-bit mode and in 64-bit mode). But the issue sounds very intermittent which makes it sound like memset might not always work. Even if the GNUlib unit test works, it might be different alignment of the variables on the stack or something like that is causing the failures there ...
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #12 from Bruno Haible --- For reference: The Gnulib unit tests for posix_spawn* pass on sparc-linux-gnu (both in 32-bit mode and in 64-bit mode).
[Bug c++/113713] constexpr function values (incorrectly?) depend on optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113713 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2016-April/446612.html might be related to the whole caching situtation but I could be wrong.
[Bug tree-optimization/113714] New: [11/12/13/14 Regression] Missed optimization for redundancy computation elimination: -(w+d-x)-x => -(w+d)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113714
Bug ID: 113714
Summary: [11/12/13/14 Regression] Missed optimization for
redundancy computation elimination: -(w+d-x)-x =>
-(w+d)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
Target Milestone: ---
Hello, we noticed that x can be eliminated from the calculation of z in the
following code:
c-x => -(w+d-x)-x => -(w+d)
https://godbolt.org/z/MYhGTc4Pv
int x,y,z,w;
void func(int a, int b, int c, int d){
x=a/b - y;
c=-(w+d-x);
z=c-x;
}
But GCC -O3 -fwrapv:
_1 = a_7(D) / b_8(D);
y.0_2 = y;
_3 = _1 - y.0_2;
x = _3;
#Here is the part related to the calculation of z:
w.2_4 = w;
_20 = y.0_2 - w.2_4;
_21 = _20 - d_11(D);
_22 = _3 + _21;
_6 = _22 - _1;
z = _6;
return;
Expected code:
GCC-10.5 -O3 -fwrapv
_1 = a_7(D) / b_8(D);
y.0_2 = y;
_3 = _1 - y.0_2;
x = _3;
#Here is the part related to the calculation of z:
w.2_4 = w;
_5 = w.2_4 + d_11(D);
_6 = -_5;
z = _6;
return;
Thank you very much for your time and effort! We look forward to hearing from
you.
[Bug c++/113713] static_assert result depends on optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113713
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-02-02
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Confirmed, this is a constexpr issue in both clang and GCC (unless there is
some unspecified behavior I don't know of).
Take:
```
#if defined(CE)
#define CONSTEXPR constexpr
#else
#define CONSTEXPR
#endif
struct A{};
template
CONSTEXPR
bool p(T) { return false; }
template
CONSTEXPR
bool f(T v) { return p(v); }
CONSTEXPR
bool g() { return f(A()); }
CONSTEXPR
bool p(A) { return true; }
int main()
{
A a;
if (!f(a))
__builtin_abort();
}
```
Without CE being defined, this works at all optimizations level. With CE being
defined this works at -O0 only (like there is some [incorrect?] caching going
on at -O1 and above and clang is doing the caching at all levels).
[Bug c++/113713] static_assert result depends on optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113713
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Andrew Pinski ---
C++11 testcase so it is easier to test against older versions of GCC:
```
struct A{};
template
constexpr bool p(T) { return false; }
template
constexpr bool f(T v) { return p(v); }
constexpr bool g() { return f(A()); }
constexpr bool p(A) { return true; }
void ff() {
static_assert( f(A{}) , "");
}
```
GCC 6 and before causes the static_assert to always to fail at all
optimizations level. GCC 7 and afterwards has the current behavior of true for
-O0 and false for -O1 and above.
[Bug c++/113713] New: static_assert result depends on optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113713
Bug ID: 113713
Summary: static_assert result depends on optimization settings
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
struct A{};
constexpr bool p(auto) { return false; }
constexpr bool f(auto v) { return p(v); }
constexpr bool g() { return f(A()); }
constexpr bool p(A) { return true; }
static_assert( f(A{}) );
The static_assert passes in GCC only with -O0 command line option, and it fails
with -O1 and higher optimization options, which looks wrong. Online demo:
https://godbolt.org/z/vWq8G7rn4
Related discussion: https://stackoverflow.com/q/77923182/7325599
