[Bug rtl-optimization/109351] RA uses lowest cost for the mode of different reg_classes w/o considering hard_regno_mode_ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109351 --- Comment #3 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:727be65ec40e119a7c864bfaa5d6a73547863c06 commit r14-57-g727be65ec40e119a7c864bfaa5d6a73547863c06 Author: liuhongt Date: Mon Apr 3 10:54:55 2023 +0800 Check hard_regno_mode_ok before setting lowest memory move cost for the mode with different reg classes. There's a potential performance issue when backend returns some unreasonable value for the mode which can be never be allocate with reg class. gcc/ChangeLog: PR rtl-optimization/109351 * ira.cc (setup_class_subset_and_memory_move_costs): Check hard_regno_mode_ok before setting lowest memory move cost for the mode with different reg classes.
[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602 --- Comment #29 from CVS Commits --- The releases/gcc-13 branch has been updated by Palmer Dabbelt : https://gcc.gnu.org/g:a252c73b1f2b920d8a2ff2e8ca59989e06652fbb commit r13-7220-ga252c73b1f2b920d8a2ff2e8ca59989e06652fbb Author: Palmer Dabbelt Date: Mon Apr 17 11:20:42 2023 -0700 RISC-V: Clean up the pr106602.c testcase The test case that was added is rv64i-specific, as there's better ways to generate this code on rv32i (where the long/int cast is a NOP) and on rv64i_zba (where we have word shifts). This renames the original test case and adds two more for those targets. gcc/testsuite/ChangeLog: PR target/106602 * gcc.target/riscv/pr106602.c: Moved to... * gcc.target/riscv/pr106602-rv64i.c: ...here. * gcc.target/riscv/pr106602-rv32i.c: New test. * gcc.target/riscv/pr106602-rv64i_zba.c: New test. (cherry picked from commit 8c010f6fe5ebe80d2e054b31e04ae0e9f12ae368)
[Bug target/109547] RISC-V: Multiple vsetvli for load/store loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547 --- Comment #2 from JuzheZhong --- It has been fixed by one of GCC-14 queue patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615352.html Since GCC-13 doesn't allow any optimizations, I can't make it in the GCC 13. Besides, there are a bunch of patches waiting to be merged: https://github.com/zhongjuzhe/gcc-14-queue-patches/edit/main/gcc-14-queue-patchs
[Bug target/109547] RISC-V: Multiple vsetvli for load/store loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-19 --- Comment #1 from Kito Cheng --- Confirmed.
[Bug c++/109548] Detect c_str() dangling problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/109548] New: Detect c_str() dangling problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
Bug ID: 109548
Summary: Detect c_str() dangling problems
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.f.fee at gmail dot com
Target Milestone: ---
Thanks to bug 106393, G++ 13 can now catch simple dangling references, such as:
const int& f(const int& i) { return i; }
const int& i = f(10);
However, more complex examples do not trigger warnings:
#include
std::string foo();
auto ptr = foo().c_str();
ASAN can detect stack-use-after-scope at runtime. Clang can catch the issue at
build time.
$ clang++ -c small.cpp
small.cpp:3:12: warning: object backing the pointer will be destroyed at the
end of the full-expression [-Wdangling-gsl]
auto ptr = foo().c_str();
^
1 warning generated.
Another example:
std::stringstream ss;
ss << "foo";
auto ptr = ss.str().c_str();
We're warned against this in the notes on cppreference.com, however it would be
better if GCC could detect such issues and warn during compilation.
https://en.cppreference.com/w/cpp/io/basic_stringstream/str
[Bug target/109547] New: RISC-V: Multiple vsetvli for load/store loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109547
Bug ID: 109547
Summary: RISC-V: Multiple vsetvli for load/store loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: palmer at gcc dot gnu.org
Target Milestone: ---
I was just poking around with a simple loop using the vector intrinsics and
found some odd generated code. This is on the gcc-13 branch, but that's pretty
close to trunk so I'm filing it for 14. I'm probably not going to have time to
look for a bit, as it seems to just be a performance issue.
$ cat test.c
#include
void func(unsigned char *out, unsigned char *in, unsigned long len) {
unsigned long i = 0;
while (i < len) {
unsigned long vl = __riscv_vsetvl_e8m1(len - i);
vuint8m1_t r = __riscv_vle8_v_u8m1(in + i, vl);
__riscv_vse8_v_u8m1(out + i, r, vl);
i += vl;
}
}
$ ../toolchain/install/bin/riscv64-unknown-linux-gnu-gcc test.c -O3 -c -S -o-
-march=rv64gcv -fdump-rtl-all
.file "test.c"
.option nopic
.attribute arch,
"rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align 1
.globl func
.type func, @function
func:
.LFB2:
.cfi_startproc
beq a2,zero,.L1
li a5,0
.L3:
sub a4,a2,a5
add a6,a1,a5
add a3,a0,a5
vsetvli a4,a4,e8,m1,ta,mu
vsetvli zero,a4,e8,m1,ta,ma
add a5,a5,a4
vle8.v v24,0(a6)
vse8.v v24,0(a3)
bgtua2,a5,.L3
.L1:
ret
.cfi_endproc
.LFE2:
.size func, .-func
.ident "GCC: (g85b95ea729c) 13.0.1 20230417 (prerelease)"
.section.note.GNU-stack,"",@progbits
[Bug c++/105406] [11 Regression] coroutines: since 11.3 co_await attempts to copy a move-only value when await_transform(T &) exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105406 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/107310] [12 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional since r12-5638-ga3e75c1491cd2d50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed for 12.3/13.
[Bug c++/107163] [10/11/12 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:dcfa9615062c46f3c45c70654ea8fa6719a5f40c commit r12-9444-gdcfa9615062c46f3c45c70654ea8fa6719a5f40c Author: Jason Merrill Date: Thu Mar 23 15:57:39 2023 -0400 c-family: -Wsequence-point and COMPONENT_REF [PR107163] The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual evaluation, and in this testcase handling COMPONENT_REF as sequenced blows up fast in a deep inheritance tree. Instead, look through it. PR c++/107163 gcc/c-family/ChangeLog: * c-common.cc (verify_tree): Don't use sequenced handling for COMPONENT_REF. gcc/testsuite/ChangeLog: * g++.dg/warn/Wsequence-point-5.C: New test.
[Bug c++/109357] [12 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:618b90f5688fa7c0923a3e07a0741c6ede0e6e4e commit r12-9445-g618b90f5688fa7c0923a3e07a0741c6ede0e6e4e Author: Jason Merrill Date: Fri Apr 14 22:40:43 2023 -0400 c++: constexpr aggregate destruction [PR109357] We were assuming that the result of evaluation of TARGET_EXPR_INITIAL would always be the new value of the temporary, but that's not necessarily true when the initializer is complex (i.e. target_expr_needs_replace). In that case evaluating the initializer initializes the temporary as a side-effect. PR c++/109357 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression) [TARGET_EXPR]: Check for complex initializer. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constexpr-dtor15.C: New test.
[Bug c++/105996] [10/11/12 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:12d7fb7e5810cc5e394d3cbea43d1b19ea7f9348 commit r12-9442-g12d7fb7e5810cc5e394d3cbea43d1b19ea7f9348 Author: Jason Merrill Date: Thu Mar 23 16:50:09 2023 -0400 c++: constexpr PMF conversion [PR105996] Here, we were calling build_reinterpret_cast regardless of whether there was actually a cast, and that now sets REINTERPRET_CAST_P. But that optimization seems dodgy anyway, as it involves NOP_EXPR from one RECORD_TYPE to another and we try to reserve NOP_EXPR for fundamental types. And the generated code seems the same, so let's drop it. And also strip location wrappers. PR c++/105996 gcc/cp/ChangeLog: * typeck.cc (build_ptrmemfunc): Drop 0-offset optimization and location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-pmf3.C: New test.
[Bug c++/105481] [10/11/12 Regression] ICE: unexpected expression of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ab7c0a44ca9e913af654ae82963565d61d8bb39f commit r12-9443-gab7c0a44ca9e913af654ae82963565d61d8bb39f Author: Jason Merrill Date: Thu Mar 23 18:20:52 2023 -0400 c++: default template arg, partial ordering [PR105481] The default argument code in type_unification_real was assuming that all targs we've deduced by that point are non-dependent, but that's not the case for partial ordering. PR c++/105481 gcc/cp/ChangeLog: * pt.cc (type_unification_real): Adjust for partial ordering. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.
[Bug c++/106890] [10/11/12 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106890 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:94569d91bd4c604da755b4aae84256e7fe21196a commit r12-9441-g94569d91bd4c604da755b4aae84256e7fe21196a Author: Jason Merrill Date: Sat Mar 18 08:27:26 2023 -0400 c++: DMI in template with virtual base [PR106890] When parsing a default member init we just build a CONVERT_EXPR for converting to a virtual base, and then expand that into the more complex form when we actually use the DMI in a constructor. But that wasn't working for the template case where we are considering the conversion at the point that the constructor needs the DMI instantiation, so it seemed like we were in a constructor already. And then when the other constructor tries to reuse the instantiation, it sees uses of the first constructor's parameters, and dies. So ensure that we get the CONVERT_EXPR in this case, too. PR c++/106890 gcc/cp/ChangeLog: * init.cc (maybe_instantiate_nsdmi_init): Don't leave current_function_decl set to a constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template25.C: New test.
[Bug debug/107154] [12 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 12.3/13.
[Bug c++/69410] [10/11/12 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:615c48b317397c2dc3d6769954d5c399ea882f7a commit r12-9439-g615c48b317397c2dc3d6769954d5c399ea882f7a Author: Jason Merrill Date: Fri Mar 17 09:43:48 2023 -0400 c++: namespace-scoped friend in local class [PR69410] do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.cc (do_friend): Handle namespace as scope argument. * decl.cc (grokdeclarator): Pass down in_namespace. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend24.C: New test.
[Bug c++/109357] [12 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Fixed for 12.3/13.
[Bug c++/108242] [10/11/12 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:890d711a2477119a34cf435f6159b6253b124374 commit r12-9437-g890d711a2477119a34cf435f6159b6253b124374 Author: Jason Merrill Date: Thu Mar 16 15:11:25 2023 -0400 c++: generic lambda, local class, __func__ [PR108242] Here we are trying to do name lookup in a deferred instantiation of t() and failing to find __func__. tsubst_expr already tries to instantiate members of local classes, but was failing with the partial instantiation of generic lambdas. PR c++/108242 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) [TAG_DEFN]: Handle partial instantiation. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-func2.C: New test.
[Bug c++/105406] [11/12 Regression] coroutines: since 11.3 co_await attempts to copy a move-only value when await_transform(T &) exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105406 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6fd32842404ac1a3cd98189f61d93c5bc9c8680c commit r12-9435-g6fd32842404ac1a3cd98189f61d93c5bc9c8680c Author: Jason Merrill Date: Wed Mar 15 17:02:15 2023 -0400 c++: co_await and move-only type [PR105406] Here we were building a temporary MoveOnlyAwaitable to hold the result of evaluating 'o', but since 'o' is an lvalue we should build a reference instead. PR c++/105406 gcc/cp/ChangeLog: * coroutines.cc (build_co_await): Handle lvalue 'o'. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-moveonly1.C: New test.
[Bug c++/105809] [10/11/12 Regression] __PRETTY_FUNCTION__ in constexpr in function vs NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:dbd8af5d8f4568ed5683ae8aa15ccb330bbf74c0 commit r12-9438-gdbd8af5d8f4568ed5683ae8aa15ccb330bbf74c0 Author: Jason Merrill Date: Thu Mar 16 15:35:15 2023 -0400 c++: __func__ and local class DMI [PR105809] As in 108242, we need to instantiate in the context of the enclosing function, not after it's gone. PR c++/105809 gcc/cp/ChangeLog: * init.cc (get_nsdmi): Split out... (maybe_instantiate_nsdmi_init): ...this function. * cp-tree.h: Declare it. * pt.cc (tsubst_expr): Use it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-__func__3.C: New test.
[Bug c++/108975] [10/11/12 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:55ab4606ab1084a55d53184c5cf4543740a7f65d commit r12-9440-g55ab4606ab1084a55d53184c5cf4543740a7f65d Author: Jason Merrill Date: Fri Mar 17 17:26:40 2023 -0400 c++: constant, array, lambda, template [PR108975] When a lambda refers to a constant local variable in the enclosing scope, we tentatively capture it, but if we end up pulling out its constant value, we go back at the end of the lambda and prune any unneeded captures. Here while parsing the template we decided that the dim capture was unneeded, because we folded it away, but then we brought back the use in the template trees that try to preserve the source representation with added type info. So then when we tried to instantiate that use, we couldn't find what it was trying to use, and crashed. Fixed by not trying to prune when parsing a template; we'll prune at instantiation time. PR c++/108975 gcc/cp/ChangeLog: * lambda.cc (prune_lambda_captures): Don't bother in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11.C: New test.
[Bug c++/101869] [10/11/12 Regression] ::enumvalue is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2f9bb63c5e82512ba9e53f4d5e67949c100d8830 commit r12-9436-g2f9bb63c5e82512ba9e53f4d5e67949c100d8830 Author: Jason Merrill Date: Thu Mar 16 13:11:32 2023 -0400 c++: ::enumerator [PR101869] We don't want to call build_offset_ref with an enum. PR c++/101869 gcc/cp/ChangeLog: * semantics.cc (finish_qualified_id_expr): Don't try to build a pointer-to-member if the scope is an enumeration. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/enum43.C: New test.
[Bug c++/103871] [11/12 Regression] coroutines: co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1da2d99c632a90e5af55c8f8db1c11af587bb0a0 commit r12-9434-g1da2d99c632a90e5af55c8f8db1c11af587bb0a0 Author: Jason Merrill Date: Wed Mar 15 16:33:37 2023 -0400 c++: co_await and initializer_list [PR103871] When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056 gcc/cp/ChangeLog: * typeck.cc (cp_build_modify_expr): Allow array initialization of DECL_ARTIFICIAL variable. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-initlist1.C: New test.
[Bug c++/107310] [12 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional since r12-5638-ga3e75c1491cd2d50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0f6d443f0d0dd8a6bab99ab1957df3cd82541b27 commit r12-9432-g0f6d443f0d0dd8a6bab99ab1957df3cd82541b27 Author: Jason Merrill Date: Tue Mar 14 12:20:51 2023 -0400 c++: -Wreturn-type with if (true) throw [PR107310] I removed this folding in GCC 12 because it was interfering with an experiment of richi's, but that never went in and the change causes regressions, so let's put it back. This reverts commit r12-5638-ga3e75c1491cd2d. PR c++/107310 gcc/cp/ChangeLog: * cp-gimplify.cc (genericize_if_stmt): Restore folding of constant conditions. gcc/testsuite/ChangeLog: * c-c++-common/Wimplicit-fallthrough-39.c: Adjust warning. * g++.dg/warn/Wreturn-6.C: New test.
[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 --- Comment #23 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1da2d99c632a90e5af55c8f8db1c11af587bb0a0 commit r12-9434-g1da2d99c632a90e5af55c8f8db1c11af587bb0a0 Author: Jason Merrill Date: Wed Mar 15 16:33:37 2023 -0400 c++: co_await and initializer_list [PR103871] When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056 gcc/cp/ChangeLog: * typeck.cc (cp_build_modify_expr): Allow array initialization of DECL_ARTIFICIAL variable. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-initlist1.C: New test.
[Bug c++/108566] [11/12 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f483dc1367294d02581e2d98c5f84be4dd67f26b commit r12-9431-gf483dc1367294d02581e2d98c5f84be4dd67f26b Author: Jason Merrill Date: Thu Mar 9 23:33:43 2023 -0500 c++: class NTTP and nested anon union [PR108566] We were failing to come up with the name for the anonymous union. It seems like unfortunate redundancy, but the ABI does say that the name of an anonymous union is its first named member. PR c++/108566 gcc/cp/ChangeLog: * mangle.cc (anon_aggr_naming_decl): New. (write_unqualified_name): Use it. gcc/testsuite/ChangeLog: * g++.dg/abi/anon6.C: New test.
[Bug c++/108468] [11/12 Regression] ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b210f028ee9dd55bfd9f60ccfc2c015f73dbe930 commit r12-9433-gb210f028ee9dd55bfd9f60ccfc2c015f73dbe930 Author: Jason Merrill Date: Tue Mar 14 16:32:31 2023 -0400 c++: variable tmpl partial specialization [PR108468] Generally we expect TPARMS_PRIMARY_TEMPLATE to be set, but sometimes it isn't for partial instantiations. This ought to be improved, but it's trivial to work around it in this case. PR c++/108468 gcc/cp/ChangeLog: * pt.cc (unify_pack_expansion): Check that TPARMS_PRIMARY_TEMPLATE is non-null. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ78.C: New test.
[Bug debug/107154] [12 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2088358b658c44f69d37af0d7deec321f557741d commit r12-9430-g2088358b658c44f69d37af0d7deec321f557741d Author: Jason Merrill Date: Tue Oct 4 17:06:04 2022 -0400 c++: fix debug info for array temporary [PR107154] In the testcase the elaboration of the array init that happens at genericize time was getting the location info for the end of the function; fixed by doing the expansion at the location of the original expression. PR c++/107154 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_init_expr): Use iloc_sentinel. (cp_genericize_target_expr): Likewise. gcc/testsuite/ChangeLog: * g++.dg/debug/dwarf2/lineno-array1.C: New test.
[Bug c++/108099] [12 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:32955c1c2246aa336d3fd2423c32546c39a6ca30 commit r12-9429-g32955c1c2246aa336d3fd2423c32546c39a6ca30 Author: Jason Merrill Date: Thu Mar 9 17:35:24 2023 -0500 c++: signed __int128_t [PR108099] The code for handling signed + typedef was breaking on __int128_t, because it isn't a proper typedef: it doesn't have DECL_ORIGINAL_TYPE. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Handle non-typedef typedef_decl. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-7.C: New test.
[Bug target/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 --- Comment #12 from Uroš Bizjak --- Implemented also for x86.
[Bug target/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
--- Comment #11 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:95b99e47f4f2df2d0c5680f45e3ec0a3170218ad
commit r14-47-g95b99e47f4f2df2d0c5680f45e3ec0a3170218ad
Author: Uros Bizjak
Date: Tue Apr 18 17:50:37 2023 +0200
i386: Improve permutations with INSERTPS instruction [PR94908]
INSERTPS can select any element from src and insert into any place
of the dest. For SSE4.1 targets, compiler can generate e.g.
insertps $64, %xmm0, %xmm1
to insert element 1 from %xmm1 to element 0 of %xmm0.
gcc/ChangeLog:
PR target/94908
* config/i386/i386-builtin.def (__builtin_ia32_insertps128):
Use CODE_FOR_sse4_1_insertps_v4sf.
* config/i386/i386-expand.cc (expand_vec_perm_insertps): New.
(expand_vec_perm_1): Call expand_vec_per_insertps.
* config/i386/i386.md ("unspec"): Declare UNSPEC_INSERTPS here.
* config/i386/mmx.md (mmxscalarmode): New mode attribute.
(@sse4_1_insertps_): New insn pattern.
* config/i386/sse.md (@sse4_1_insertps_): Macroize insn
pattern from sse4_1_insertps using VI4F_128 mode iterator.
gcc/testsuite/ChangeLog:
PR target/94908
* gcc.target/i386/pr94908.c: New test.
* gcc.target/i386/sse4_1-insertps-5.c: New test.
* gcc.target/i386/vperm-v4sf-2-sse4.c: New test.
[Bug fortran/82064] [10/11/12/13/14 Regression] [OOP] multiple incompatible definitions of extended derived type via module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Paul Thomas --- This seems to have been fixed in the dim and distant past but not closed. GNU Fortran (GCC) 8.3.1 20191027 through the current mainline all produce the two "OK"s and, yes, I did use the separate files. Closing. Paul
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #18 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6067ae4557a3a7e5b08359e78a29b8a9d5dfedce commit r14-46-g6067ae4557a3a7e5b08359e78a29b8a9d5dfedce Author: Jonathan Wakely Date: Tue Apr 18 17:22:40 2023 +0100 libstdc++: Fix preprocessor condition in linker script [PR108969] The linker script is preprocessed with $(top_builddir)/config.h not the include/$target/bits/c++config.h version, which means that configure macros do not have the _GLIBCXX_ prefix yet. The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant, because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the linker script is only used for the shared library. Remove those. libstdc++-v3/ChangeLog: PR libstdc++/108969 * config/abi/pre/gnu.ver: Fix preprocessor condition.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #19 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ed933888e680384e1e7af361b20dd484ad424f7d commit r13-7218-ged933888e680384e1e7af361b20dd484ad424f7d Author: Jonathan Wakely Date: Tue Apr 18 17:22:40 2023 +0100 libstdc++: Fix preprocessor condition in linker script [PR108969] The linker script is preprocessed with $(top_builddir)/config.h not the include/$target/bits/c++config.h version, which means that configure macros do not have the _GLIBCXX_ prefix yet. The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant, because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the linker script is only used for the shared library. Remove those. libstdc++-v3/ChangeLog: PR libstdc++/108969 * config/abi/pre/gnu.ver: Fix preprocessor condition. (cherry picked from commit 6067ae4557a3a7e5b08359e78a29b8a9d5dfedce)
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Jonathan Wakely --- Fixed for 13.1
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:762be0646bf96761ce68a9e06ab60c453e0963d0 commit r13-7217-g762be0646bf96761ce68a9e06ab60c453e0963d0 Author: Jonathan Wakely Date: Tue Apr 18 14:37:38 2023 +0100 libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969] Since GCC 13 the global iostream objects are only initialized once in libstdc++, and not by a std::ios::Init object in every translation unit that includes . To avoid using uninitialized streams defined in an older libstdc++.so, translation units using the global iostreams should depend on the GLIBCXX_3.4.31 symver. Define std::cin as std::__io::cin and then export it as std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new symver. Also export it as @GLIBCXX_3.4 for backwards compatibility libstdc++-v3/ChangeLog: PR libstdc++/108969 * src/Makefile.am: Move globals_io.cc to here. * src/Makefile.in: Regenerate. * src/c++98/Makefile.am: Remove globals_io.cc from here. * src/c++98/Makefile.in: Regenerate. * src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust symbol name and then export with GLIBCXX_3.4.31 symver. (cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise. * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Regenerate. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Add iostream objects to new symver.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7c54e3f48086c29179f7765a35c381de5109a0a commit r14-43-gb7c54e3f48086c29179f7765a35c381de5109a0a Author: Jonathan Wakely Date: Tue Apr 18 14:37:38 2023 +0100 libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969] Since GCC 13 the global iostream objects are only initialized once in libstdc++, and not by a std::ios::Init object in every translation unit that includes . To avoid using uninitialized streams defined in an older libstdc++.so, translation units using the global iostreams should depend on the GLIBCXX_3.4.31 symver. Define std::cin as std::__io::cin and then export it as std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new symver. Also export it as @GLIBCXX_3.4 for backwards compatibility libstdc++-v3/ChangeLog: PR libstdc++/108969 * src/Makefile.am: Move globals_io.cc to here. * src/Makefile.in: Regenerate. * src/c++98/Makefile.am: Remove globals_io.cc from here. * src/c++98/Makefile.in: Regenerate. * src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust symbol name and then export with GLIBCXX_3.4.31 symver. (cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise. * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Regenerate. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Add iostream objects to new symver.
[Bug fortran/93338] [10/11/12/13/14 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #12) > This is fixed on current 10- through 13-branches. > > I don't quite know why it hasn't been closed. It still fails for me at -O1 and higher for 10-branch and 11-branch: % gfc-11 pr93338.f90 -O1 during IPA pass: inline pr93338.f90:10:3: 10 | end | ^ internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:290 0xe0f0d5 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int) ../../gcc-11/gcc/tree-ssanames.c:287 0xc8dc8e make_ssa_name ../../gcc-11/gcc/tree-ssanames.h:115 0xc8dc8e remap_ssa_name ../../gcc-11/gcc/tree-inline.c:262 0xc90897 copy_tree_body_r(tree_node**, int*, void*) ../../gcc-11/gcc/tree-inline.c:1256 0xeb4505 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc-11/gcc/tree.c:12091 0xeb4b4e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc-11/gcc/tree.c:12439 0xc8cdec remap_type_1 ../../gcc-11/gcc/tree-inline.c:622 0xc8d0c8 remap_type(tree_node*, copy_body_data*) ../../gcc-11/gcc/tree-inline.c:740 0xc8cc87 remap_type_1 ../../gcc-11/gcc/tree-inline.c:452 0xc8d0c8 remap_type(tree_node*, copy_body_data*) ../../gcc-11/gcc/tree-inline.c:740 0xc8dc7b remap_ssa_name ../../gcc-11/gcc/tree-inline.c:262 0xc9117f remap_gimple_op_r ../../gcc-11/gcc/tree-inline.c:1058 0xeb4505 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc-11/gcc/tree.c:12091 0x9a5f9d walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc-11/gcc/gimple-walk.c:221 0xc8f2ff remap_gimple_stmt ../../gcc-11/gcc/tree-inline.c:1952 0xc916ed copy_bb ../../gcc-11/gcc/tree-inline.c:2022 0xc9319a copy_cfg_body ../../gcc-11/gcc/tree-inline.c:3054 0xc9319a copy_body ../../gcc-11/gcc/tree-inline.c:3309 0xc96164 expand_call_inline ../../gcc-11/gcc/tree-inline.c:5129 0xc977c9 gimple_expand_calls_inline ../../gcc-11/gcc/tree-inline.c:5319 Please submit a full bug report, with preprocessed source if appropriate. So adjust known-to-work/-fail?
[Bug middle-end/109545] first_stmt has strange semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109545 --- Comment #2 from Richard Biener --- Yep, but it will for label: # DEBUG ... _1 = xyz; return 'label'. It surely depends on what the users intend (and we have only very few). Likely the tree-vect-slp.cc case (I've only added recently ...) is wrong in this regard since. It wants first non-label non-debug.
[Bug fortran/93338] [10/11/12/13/14 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338 --- Comment #12 from Paul Thomas --- This is fixed on current 10- through 13-branches. I don't quite know why it hasn't been closed. Paul
[Bug middle-end/109545] first_stmt has strange semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109545 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why? DEBUG_STMTs should never appear before labels.
[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674 Stam Markianos-Wright changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Stam Markianos-Wright --- Thanks Richard! I believe this is now fixed. This is likely not applicable for backporting as Andre's changes included some mid-end additions and it's only a missed-optimization regression -- hence closing this ticket.
[Bug tree-optimization/109546] New: [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
Bug ID: 109546
Summary: [13 Regression] Missed Dead Code Elimination when
using __builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat input.c
void foo(void);
static int a, c;
static int *b =
static int **d =
void __assert_fail() __attribute__((__noreturn__));
int main() {
int *e = *d;
if (e == || e == );
else {
__assert_fail();
}
if (e == || e == );
else
foo();
}
both gcc 12 and trunk at -O3 generate the following code:
main:
movqb(%rip), %rax
cmpq$c, %rax
je .L2
cmpq$a, %rax
jne .L7
.L2:
xorl%eax, %eax
ret
.L7:
pushq %rax
xorl%eax, %eax
call__assert_fail
b:
.quad a
the call to foo is eliminated but the call to __assert_fail is missed, even
though
both if statement conditions are identical.
If add a __builtin_unreachable before the call to __assert_fail the opposite
happens:
void foo(void);
static int a, c;
static int *b =
static int **d =
void assert_fail() __attribute__((__noreturn__));
int main() {
int *e = *d;
if (e == || e == );
else {
__builtin_unreachable();
assert_fail();
}
if (e == || e == );
else
foo();
}
gcc-trunk -O3 generates:
main:
movqb(%rip), %rax
cmpq$c, %rax
je .L4
cmpq$a, %rax
je .L4
pushq %rax
callfoo
xorl%eax, %eax
popq%rdx
ret
.L4:
xorl%eax, %eax
ret
b:
.quad a
the call to __assert_fail is now properly eliminated but now the call to foo is
missed.
This is a regression as gcc-12 generates:
main:
xorl%eax, %eax
ret
[Bug middle-end/108786] bitmap_first_set_bit misses a bitmap_clear_first_bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108786 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed for GCC 14+
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359 Andrew Pinski changed: What|Removed |Added Known to work||12.1.0 Keywords||needs-bisection --- Comment #14 from Andrew Pinski --- Note the original testcase is fixed in GCC 12.1.0. The one in comment #2 is not but I think it is a seperate issue ...
[Bug middle-end/108786] bitmap_first_set_bit misses a bitmap_clear_first_bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108786 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f548ece7abc0a0c81dd049e9f8b480ff2c38e18b commit r14-41-gf548ece7abc0a0c81dd049e9f8b480ff2c38e18b Author: Richard Biener Date: Tue Feb 14 16:36:03 2023 +0100 middle-end/108786 - add bitmap_clear_first_set_bit This adds bitmap_clear_first_set_bit and uses it where previously bitmap_clear_bit followed bitmap_first_set_bit. The advantage is speeding up the search and avoiding to clobber ->current. PR middle-end/108786 * bitmap.h (bitmap_clear_first_set_bit): New. * bitmap.cc (bitmap_first_set_bit_worker): Rename from bitmap_first_set_bit and add optional clearing of the bit. (bitmap_first_set_bit): Wrap bitmap_first_set_bit_worker. (bitmap_clear_first_set_bit): Likewise. * df-core.cc (df_worklist_dataflow_doublequeue): Use bitmap_clear_first_set_bit. * graphite-scop-detection.cc (scop_detection::merge_sese): Likewise. * sanopt.cc (sanitize_asan_mark_unpoison): Likewise. (sanitize_asan_mark_poison): Likewise. * tree-cfgcleanup.cc (cleanup_tree_cfg_noloop): Likewise. * tree-into-ssa.cc (rewrite_blocks): Likewise. * tree-ssa-dce.cc (simple_dce_from_worklist): Likewise. * tree-ssa-sccvn.cc (do_rpo_vn_1): Likewise.
[Bug target/109544] implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 Mathieu Malaterre changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Mathieu Malaterre --- ok then. Closing as resolved/invalid then !
[Bug target/109544] implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 --- Comment #1 from JuzheZhong --- We don't support segment yet since segment load/store api will be changed. For example: The old api: __riscv_vsseg4e8_v_i8mf8(base, vint8mf8_t v0, vint8mf8_t v1, vint8mf8_t v2, vint8mf8_t v3, vl); will be changed into: __riscv_vsseg4e8_v_i8mf8(base, vint8mf8x4_t v0, vl); The latest segment load/store are not merged yet: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/198 but will be soon merged. GCC will not implement old api, instead we are implementing latest api recently and they are expected in GCC 14.
[Bug middle-end/109545] New: first_stmt has strange semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109545 Bug ID: 109545 Summary: first_stmt has strange semantics Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- tree-cfg.cc:first_stmt skips debug stmts but not labels which is quite odd and can lead to compare-debug issues. Users are ./tree-cfgcleanup.cc: stmt = first_stmt (dest); ./tree-cfgcleanup.cc: label = first_stmt (dest); ./omp-expand.cc: && first_stmt (store_bb) == store ./tree-vect-slp.cc: if (gcall *first = safe_dyn_cast (first_stmt (bb))) ./gimple-loop-versioning.cc: gimple *stmt = first_stmt (loop->header); ./cp/cp-gimplify.cc:return first_stmt (p->stmt); ./cp/cp-gimplify.cc: return first_stmt (BIND_EXPR_BODY (stmt)); ./cp/cp-gimplify.cc: tree ft = first_stmt (then_); ./cp/cp-gimplify.cc: tree fe = first_stmt (else_); ./tree-cfg.h:extern gimple *first_stmt (basic_block); ./tree-cfg.cc: then_stmt = first_stmt (then_bb); ./tree-cfg.cc: else_stmt = first_stmt (else_bb);
[Bug target/109544] New: implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 Bug ID: 109544 Summary: implicit declaration of function '__riscv_vsseg4e8_v_i8mf8' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- Seems like some intrinsics are missing: $ wget https://raw.githubusercontent.com/riscv-non-isa/rvv-intrinsic-doc/70b1a6ba0959505793bc8d2c3ccea0e2b5402e80/auto-generated/api-testing/vsseg4e8.c Gives: % clang-16 -v -march=rv64gcv1p0 -c vsseg4e8.c Debian clang version 16.0.0 (1~exp5) Target: riscv64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/riscv64-linux-gnu/12 Found candidate GCC installation: /usr/bin/../lib/gcc/riscv64-linux-gnu/13 Selected GCC installation: /usr/bin/../lib/gcc/riscv64-linux-gnu/13 (in-process) "/usr/lib/llvm-16/bin/clang" -cc1 -triple riscv64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name vsseg4e8.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic-rv64 -target-feature +m -target-feature +a -target-feature +f -target-feature +d -target-feature +c -target-feature +v -target-feature +zve32f -target-feature +zve32x -target-feature +zve64d -target-feature +zve64f -target-feature +zve64x -target-feature +zvl128b -target-feature +zvl32b -target-feature +zvl64b -target-feature -e -target-feature -h -target-feature -zihintpause -target-feature -zfhmin -target-feature -zfh -target-feature -zfinx -target-feature -zdinx -target-feature -zhinxmin -target-feature -zhinx -target-feature -zba -target-feature -zbb -target-feature -zbc -target-feature -zbs -target-feature -zbkb -target-feature -zbkc -target-feature -zbkx -target-feature -zknd -target-feature -zkne -target-feature -zknh -target-feature -zksed -target-feature -zksh -target-feature -zkr -target-feature -zkn -target-feature -zks -target-feature -zkt -target-feature -zk -target-feature -zmmul -target-feature -zvl256b -target-feature -zvl512b -target-feature -zvl1024b -target-feature -zvl2048b -target-feature -zvl4096b -target-feature -zvl8192b -target-feature -zvl16384b -target-feature -zvl32768b -target-feature -zvl65536b -target-feature -zicbom -target-feature -zicboz -target-feature -zicbop -target-feature -svnapot -target-feature -svpbmt -target-feature -svinval -target-feature -xventanacondops -target-feature -xtheadvdot -target-feature -experimental-zihintntl -target-feature -experimental-zca -target-feature -experimental-zcd -target-feature -experimental-zcf -target-feature -experimental-zvfh -target-feature -experimental-zawrs -target-feature -experimental-ztso -target-feature +relax -target-feature -save-restore -target-abi lp64d -msmall-data-limit 8 -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/malat/highway/bin -resource-dir /usr/lib/llvm-16/lib/clang/16 -internal-isystem /usr/lib/llvm-16/lib/clang/16/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include -internal-externc-isystem /usr/include/riscv64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/home/malat/highway/bin -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o vsseg4e8.o -x c vsseg4e8.c clang -cc1 version 16.0.0 based upon LLVM 16.0.0 default target riscv64-unknown-linux-gnu ignoring nonexistent directory "/usr/bin/../lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/llvm-16/lib/clang/16/include /usr/local/include /usr/include/riscv64-linux-gnu /usr/include End of search list. while: % gcc-13 -v -march=rv64gcv1p0 -c vsseg4e8.c Using built-in specs. COLLECT_GCC=gcc-13 Target: riscv64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 13-20230411-1' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie
[Bug target/105325] power10: Error: operand out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org Target Milestone|--- |13.0
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 --- Comment #7 from Dimitrij Mijoski --- I put a second version of the patch https://gcc.gnu.org/pipermail/libstdc++/2023-March/055667.html about a month ago.
[Bug c++/105351] [concepts] Constraint checking does correctly match static member attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105351 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Patrick Palka --- Fixed for GCC 13, probably not suitable for backporting. Thanks for the bug report.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #6 from Puneet B --- its not after refer the wiki, its observed on target where its clear that even after compiling application with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 its still calling ___pthread_cond_timedwait More over if i call pthread_cond_timedwait directly its calling __pthread_cond_timedwait64 directly as i already mentioned in this thread. And issue is resolved if i add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h it clears that weakref symbol is not working properly during linker stage. both __gthrw_(pthread_cond_timedwait) and pthread_cond_timedwait are expected to invoke same API. let me know if you need any more inputs
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fdbaab2dc886f78a1e755120faa17e77c862 commit r14-30-gfdbaab2dc886f78a1e755120faa17e77c862 Author: Richard Biener Date: Tue Apr 18 11:49:48 2023 +0200 tree-optimization/109539 - restrict PHI handling in access diagnostics Access diagnostics visits the SSA def-use chains to diagnose things like dangling pointer uses. When that runs into PHIs it tries to prove all incoming pointers of which one is the currently visited use are related to decide whether to keep looking for the PHI def uses. That turns out to be overly optimistic and thus costly. The following scraps the existing handling for simply requiring that we eventually visit all incoming pointers of the PHI during the def-use chain analysis and only then process uses of the PHI def. Note this handles backedges of natural loops optimistically, diagnosing the first iteration. There's gcc.dg/Wuse-after-free-2.c containing a testcase requiring this. PR tree-optimization/109539 * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Re-implement pointer relatedness for PHIs.
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:68aea7801848f978f8b5461807dfd3b7a504da1e commit r13-7215-g68aea7801848f978f8b5461807dfd3b7a504da1e Author: Richard Biener Date: Tue Apr 18 11:49:48 2023 +0200 tree-optimization/109539 - restrict PHI handling in access diagnostics Access diagnostics visits the SSA def-use chains to diagnose things like dangling pointer uses. When that runs into PHIs it tries to prove all incoming pointers of which one is the currently visited use are related to decide whether to keep looking for the PHI def uses. That turns out to be overly optimistic and thus costly. The following scraps the existing handling for simply requiring that we eventually visit all incoming pointers of the PHI during the def-use chain analysis and only then process uses of the PHI def. Note this handles backedges of natural loops optimistically, diagnosing the first iteration. There's gcc.dg/Wuse-after-free-2.c containing a testcase requiring this. PR tree-optimization/109539 * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Re-implement pointer relatedness for PHIs. (cherry picked from commit fdbaab2dc886f78a1e755120faa17e77c862)
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #4 from Patrick Palka --- Fixed for GCC 13, thanks!
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 --- Comment #5 from Jonathan Wakely --- You can either perform the arithmetic using intptr_t or uintptr_t, or use -fdelete-null-pointer-checks (as the documentation for that option explains). Also I would expect a volatile char* to be used for such accesses.
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 --- Comment #4 from Xi Ruoyao --- (In reply to Amos Maimon from comment #3) > 1. the same will occur if you will do : > p[0xe] = 0xfc; Yes, it's undefined behavior too as C defines a[b] as *(a+b). > 2. how do you explin the fact that if the null set in the function > (SIMPLE_WRITE case) gcc compile it without ud2a It's an undefined behavior, the compiler can do anything.
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 --- Comment #3 from Amos Maimon --- 1. the same will occur if you will do : p[0xe] = 0xfc; 2. how do you explin the fact that if the null set in the function (SIMPLE_WRITE case) gcc compile it without ud2a
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:769c324424500a3d20de7417f62a4e7bce345775 commit r13-7214-g769c324424500a3d20de7417f62a4e7bce345775 Author: Patrick Palka Date: Tue Apr 18 07:21:13 2023 -0400 libstdc++: Implement range_adaptor_closure from P2387R3 [PR108827] PR libstdc++/108827 libstdc++-v3/ChangeLog: * include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value for C++23. * include/std/ranges (range_adaptor_closure): Define for C++23. * include/std/version (__cpp_lib_ranges): Bump value for C++23. * testsuite/std/ranges/version_c++23.cc: Bump expected value of __cpp_lib_ranges. * testsuite/std/ranges/range_adaptor_closure.cc: New test. (cherry picked from commit cb5c71d16d0fb47638498365f5c857ce7c673eaf)
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Biener --- This works exactly as intended. In C when you offset a pointer you may not venture outside of a valid object and at NULL there isn't a valid object unless -fno-delete-null-pointer-checks.
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4dc8c0b62d91d239b88cc81bbb8f4fbde317fde6 commit r13-7212-g4dc8c0b62d91d239b88cc81bbb8f4fbde317fde6 Author: Patrick Palka Date: Tue Apr 18 07:21:07 2023 -0400 libstdc++: Fix typo in views::as_const's operator() [PR109525] PR libstdc++/109525 libstdc++-v3/ChangeLog: * include/std/ranges (views::_AsConst::operator()): Add missing const to constant_range test. * testsuite/std/ranges/adaptors/as_const/1.cc (test02): Improve formatting. Adjust expected type of v2. (test03): New test. (cherry picked from commit 4ec4ceafcc04ec7bafb1857cf6d491030440a765)
[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-18 CC||jamborm at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- A safe mode would have to be an integer mode supporting bitwise copying. Usually SRA is responsible for selecting "register-like" types for aggregates but it might in this case stay away because of the union. But it really looks like a classy example SRA should handle (for example by splitting TYPE into four DImode integers - it wouldn't currently chose vectors but of course it eventually could). Can you adjust the testcase to use GCC generic vectors?
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:cb5c71d16d0fb47638498365f5c857ce7c673eaf commit r14-29-gcb5c71d16d0fb47638498365f5c857ce7c673eaf Author: Patrick Palka Date: Tue Apr 18 07:21:13 2023 -0400 libstdc++: Implement range_adaptor_closure from P2387R3 [PR108827] PR libstdc++/108827 libstdc++-v3/ChangeLog: * include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value for C++23. * include/std/ranges (range_adaptor_closure): Define for C++23. * include/std/version (__cpp_lib_ranges): Bump value for C++23. * testsuite/std/ranges/version_c++23.cc: Bump expected value of __cpp_lib_ranges. * testsuite/std/ranges/range_adaptor_closure.cc: New test.
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4ec4ceafcc04ec7bafb1857cf6d491030440a765 commit r14-27-g4ec4ceafcc04ec7bafb1857cf6d491030440a765 Author: Patrick Palka Date: Tue Apr 18 07:21:07 2023 -0400 libstdc++: Fix typo in views::as_const's operator() [PR109525] PR libstdc++/109525 libstdc++-v3/ChangeLog: * include/std/ranges (views::_AsConst::operator()): Add missing const to constant_range test. * testsuite/std/ranges/adaptors/as_const/1.cc (test02): Improve formatting. Adjust expected type of v2. (test03): New test.
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Performing arithmetic on NULL pointer is an undefined behavior. The standard says you can only perform arithmetic on a pointer if it's a pointer to an array element (an object not in any array will be considered as the only element in an array with length 1), but NULL is not such a pointer.
[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536 --- Comment #3 from Jonathan Wakely --- Right - using std::vector in constant expressions isn't supported by debug mode. Somebody needs to work on that.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #5 from Jonathan Wakely ---
The description is a bit confusing, but the issue is that we define:
typedef struct timespec __gthread_time_t;
and then use that in several functions like this:
static inline int
__gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex,
const __gthread_time_t *__abs_timeout)
{
return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout);
}
If libc uses a 64-bit time_t in struct timespec then we need to use
__pthread_cond_timedwait64 instead of pthread_cond_timedwait, because the
latter expects a struct containing a 32-bit time_t instead of a 64-bit one.
The weak alias referenced by __gthrw_ is defined like so:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
Where the _TIME_BITS=64 declaration of pthread_cond_timedwait is:
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
The reported issue is that weakref("pthread_cond_timedwait") binds to a symbol
of that name, rather than to __pthread_cond_timedwait64, so we end up passing a
64-bit timespec to the 32-bit pthread_cond_timedwait.
However, that's not what I observe when I test it.
If I compile with 32-bit time_t for i686 using GCC 12 and
glibc-2.36-9.fc37.i686 then a call to __gthread_cond_timedwait will resolve to
glibc's pthread_cond_timedwait which expects a 32-bit timespec:
(gdb)
13__gthread_cond_timedwait(, , );
(gdb) step
__gthread_cond_timedwait (__cond=0x804c060 , __mutex=0x804c090 ,
__abs_timeout=0xc7e8)
at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872
872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex,
__abs_timeout);
(gdb)
___pthread_cond_timedwait (cond=0x804c060 , mutex=0x804c090 ,
abstime=0xc7e8) at pthread_cond_wait.c:655
655 {
(gdb) l
650 libc_hidden_def (__pthread_cond_timedwait64)
651
652 int
653 ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t
*mutex,
654 const struct timespec *abstime)
655 {
656 struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
657
658 return __pthread_cond_timedwait64 (cond, mutex, );
659 }
If I recompile the same code with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 then
the call to __gthread_cond_timedwait resolves to glibc's
__pthread_cond_timedwait64:
(gdb)
13__gthread_cond_timedwait(, , );
(gdb) step
__gthread_cond_timedwait (__cond=0x804c060 , __mutex=0x804c090 ,
__abs_timeout=0xc7e0)
at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872
872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex,
__abs_timeout);
(gdb)
___pthread_cond_timedwait64 (cond=0x804c060 , mutex=0x804c090 ,
abstime=0xc7e0) at pthread_cond_wait.c:632
632 {
(gdb) l
627
628 /* See __pthread_cond_wait_common. */
629 int
630 ___pthread_cond_timedwait64 (pthread_cond_t *cond, pthread_mutex_t
*mutex,
631 const struct __timespec64 *abstime)
632 {
633 /* Check parameter validity. This should also tell the compiler that
634 it can assume that abstime is not NULL. */
635 if (! valid_nanoseconds (abstime->tv_nsec))
636 return EINVAL;
So it seems to work fine. Do you actually observe a bug, or are you just
speculating from reading the wiki page and headers?
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #4 from Jonathan Wakely --- Yes, I know. I'm just pointing out that you're reporting a bug against an unsupported version.
[Bug tree-optimization/109543] New: Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
Bug ID: 109543
Summary: Avoid using BLKmode for unions with a non-BLKmode
member when possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
So with the following C-code:
$ cat t.c
#include
#ifdef GOOD
typedef float64x2x2_t TYPE;
#else
typedef union
{
float64x2x2_t v;
double d[4];
} TYPE;
#endif
void foo (TYPE *a, TYPE *b, TYPE *c, unsigned n)
{
TYPE X = a[0];
TYPE Y = b[0];
TYPE Z = c[0];
for (unsigned i = 0; i < n; ++n)
{
TYPE temp = X;
X = Y;
Y = Z;
Z = temp;
}
a[0] = X;
b[0] = Y;
c[0] = Z;
}
If compiled for aarch64 with -DGOOD the compiler will use vector register moves
in the loop, whereas without -DGOOD it will use the stack with memmoves.
The reason for this is because when picking the mode to address a UNION with
gcc will always choose BLKmode as soon as any member of a UNION is BLKmode. In
such cases I think it would be safe to go with not-BLKmode of members that have
the same size as the entire UNION?
[Bug c/109542] New: bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 Bug ID: 109542 Summary: bad detection of null dereferance cause ud2a in valid inline function code Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: amos.maimon at sap dot com Target Milestone: --- Created attachment 54881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54881=edit snip code that reproduce the issue that decribe above There is a bug in the detection of null dereferance - and user code change to UD2A. This happened when the function picked to be inline. How to reproduce: 1. download the attached code snip. 2. compile with the following params: gcc -Wall -Werror -Wno-packed-not-aligned -Wno-address-of-packed-member -Wno-multichar -Wno-unused -fno-strict-aliasing -fno-optimize-sibling-calls -mno-sse -fno-omit-frame-pointer -g -finline-limit=6000 -mcmodel=large -ffreestanding -mno-red-zone -O2 test.c 3. with objdump you can see that the line : *(p + 0xe) = 0xfc; compile to : 1044: c6 04 25 fe ff 0f 00movb $0x0,0xe 104b: 00 104c: 0f 0b ud2 While if instead p you will use local parameter (define SIMPLE_WRITE and recompile) it will keep user code as expected: 1044: c6 04 25 fe ff 0f 00movb $0xfc,0xe 104b: fc Note that the problam will not occur if -fno-delete-null-pointer-checks will be added to the compilation parameters.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #3 from Puneet B --- It can be reproduceable in gcc master branch or latest release..dont look at it as GCC particular version bug.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #2 from Jonathan Wakely --- N.B. GCC 9 is no longer supported, so any changes will not help that version.
[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Ah yes, this is a dup of bug 106212 which is caused by bug 85944 *** This bug has been marked as a duplicate of bug 85944 ***
[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944 Jonathan Wakely changed: What|Removed |Added CC||terra at gnome dot org --- Comment #9 from Jonathan Wakely --- *** Bug 109517 has been marked as a duplicate of this bug. ***
[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108617 --- Comment #1 from Jonathan Wakely --- I think this is a front end bug, not a library bug.
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #4 from Richard Biener --- So what we try to do is, when check_pointer_uses follows the use chain of 'ptr' through say ptr2 = ptr + 4; then it wants to visit ptr2 uses as well. For PHIs we get to ptr2 = PHI <..., ptr, ...>; and we want to consider uses of ptr2 only if all other PHI arguments are "related" to 'ptr'. To prove that we perform complicated gymnastics, in particular the only real check done is if (!ptr_derefs_may_alias_p (p, q)) return false; and that's of course incredibly weak. To disprove relatedness the pointers_related_p recurses, but only when either of both pointers are defined by a PHI. It uses pointer-query to skip chains of pointer adjustments up to such definition. So we basically do forward relatedness in check_pointer_uses and then backward relatedness in pointers_related_p. I think we should eschew that completely and only try to handle "forward" PHIs by the iteration in check_pointer_uses itself.
[Bug c++/109518] invalid constexpr code is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109518 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-18 Status|UNCONFIRMED |NEW
[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961 Paul Thomas changed: What|Removed |Added Blocks|87477 | Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Since this has nothing to do with the associate construct, I have removed the blocking of PR87477. That said, I am onto it :-) I cannot see anything untoward with the produced code at the moment and, since there is the dependence on whether or not the subroutine is in a module, I can only surmise that there is some subtle difference in memory usage. Paul Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 [Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #3 from Richard Biener --- The issue is almost certainly the cost of pointers_related_p Samples: 3M of event 'cycles', Event count (approx.): 3573086788171 Children Self Samples Command Shared Object Symbol - 93.15% 0.80% 25898 cc1plus cc1plus [.] (anonymous namespace)::pointers_related_p # - 92.35% (anonymous namespace)::pointers_related_p # - 92.30% (anonymous namespace)::pointers_related_p # - 92.21% (anonymous namespace)::pointers_related_p # - 92.12% (anonymous namespace)::pointers_related_p # - 92.02% (anonymous namespace)::pointers_related_p # - 91.93% (anonymous namespace)::pointers_related_p # - 91.84% (anonymous namespace)::pointers_related_p # - 91.75% (anonymous namespace)::pointers_related_p # - 91.66% (anonymous namespace)::pointers_related_p # - 91.57% (anonymous namespace)::pointers_related_p # - 91.48% (anonymous namespace)::pointers_related_p # - 91.39% (anonymous namespace)::pointers_related_p # - 87.34% (anonymous namespace)::pointers_related_p# - 62.30% (anonymous namespace)::pointers_related_p # - 44.52% pointer_query::get_ref # - 44.51% compute_objsize # + 15.03% access_ref::size_remaining # + 14.49% wide_int_to_tree # + 4.91% generic_wide_int >::operat# + 4.57% operator<
Re: About initialization of automatic variables
Ok, I see. 2023年4月18日(火) 17:27 Jonathan Wakely : > The gcc-bugs@gcc.gnu.org list is for automated email from our Bugzilla > database, please don't use it to report bugs or to ask questions about > how GCC works. > > For questions about using GCC send email to gcc-h...@gcc.gnu.org and > to report bugs please use bugzilla: https://gcc.gnu.org/bugs/ > > Thanks! > > >
[Bug tree-optimization/98856] [11/12/13/14 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #44 from Richard Biener --- The original description is for znver1 which we stopped benchmarking. https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=39959=171.721.1 is for znver2 still showing the regression and the following for znver3 which doesn't date back to the rev that regressed https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=39969=283.721.1 So the issue is still there but I am no longer actively working on it.
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Implemented for GCC 14.
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2349e69125335d4c8c5e43cf3643844519d154c3 commit r14-22-g2349e69125335d4c8c5e43cf3643844519d154c3 Author: Jakub Jelinek Date: Tue Apr 18 11:01:47 2023 +0200 match.pd: Improve fneg/fadd optimization [PR109240] match.pd has mostly for AArch64 an optimization in which it optimizes certain forms of __builtin_shuffle of x + y and x - y vectors into fneg using twice as wide element type so that every other sign is changed, followed by fadd. The following patch extends that optimization, so that it can handle other forms as well, using the same fneg but fsub instead of fadd. As the plus is commutative and minus is not and I want to handle vec_perm with plus minus and minus plus order preferrably in one pattern, I had to do the matching operand checks by hand. 2023-04-18 Jakub Jelinek PR tree-optimization/109240 * match.pd (fneg/fadd): Rewrite such that it handles both plus as first vec_perm operand and minus as second using fneg/fadd and minus as first vec_perm operand and plus as second using fneg/fsub. * gcc.target/aarch64/simd/addsub_2.c: New test. * gcc.target/aarch64/sve/addsub_2.c: New test.
[Bug target/109541] ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541 --- Comment #1 from Sam James --- Maybe a dupe of PR108703? Need to rebuild with debugging symbols as well now.
[Bug target/109541] New: ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
Bug ID: 109541
Summary: ICE in extract_constrain_insn on
sparc64-unknown-linux-gnu when building rhash-1.4.3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Host: sparc64-unknown-linux-gnu
Target: sparc64-unknown-linux-gnu
Build: sparc64-unknown-linux-gnu
Created attachment 54880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54880=edit
a-sha512.i
Hit this when building rhash-1.4.3
```
$ sparc64-unknown-linux-gnu-gcc -DUSE_OPENSSL -DNDEBUG -pipe
-ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -W
-Wstrict-prototypes -Wnested-externs -Winline -Wpointer-arith
-Wbad-function-cast -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -O2 -mcpu=niagara4 -pipe -fpic
-DRHASH_XVERSION=0x01040200 librhash/sha512.c
librhash/sha512.c: In function ‘rhash_sha512_process_block’:
librhash/sha512.c:179:1: error: insn does not satisfy its constraints:
179 | }
| ^
(insn 5 2048 675 2 (set (reg/f:DI 72 %f40 [2613])
(mem/u/c:DI (plus:DI (reg:DI 3 %g3 [109])
(symbol_ref:DI ("rhash_k512") [flags 0x2] )) [0 S8 A64])) "librhash/sha512.c":158:17 125
{*movdi_insn_sp64}
(expr_list:REG_EQUIV (symbol_ref:DI ("rhash_k512") [flags 0x2] )
(nil)))
during RTL pass: reload
librhash/sha512.c:179:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x18521f7 internal_error(char const*, ...)
???:0
0x2cbd17 fancy_abort(char const*, int, char const*)
???:0
0x2b2b27 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x2b2bdf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0xa3b7b7 extract_constrain_insn(rtx_insn*)
???:0
0x8c3687 lra(_IO_FILE*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I will have a look.
[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-18 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54879=edit gcc14-pr107041.patch Untested fix.
Re: About initialization of automatic variables
The gcc-bugs@gcc.gnu.org list is for automated email from our Bugzilla database, please don't use it to report bugs or to ask questions about how GCC works. For questions about using GCC send email to gcc-h...@gcc.gnu.org and to report bugs please use bugzilla: https://gcc.gnu.org/bugs/ Thanks!
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #1 from Martin Liška --- Created attachment 54877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54877=edit Reduced test-case Takes 1.77s after the mentioned revision and 0.15s before it.
Re: About initialization of automatic variables
Ok, thanks! 2023年4月18日(火) 16:06 Andreas Schwab : > On Apr 18 2023, naoki ueda via Gcc-bugs wrote: > > > The attached code says "int a = 100;", but it should normally be > > initialized with an "undefined value", but in the case of gcc-10, it is > > initialized with "0". Isn't this a bug in gcc-10? > > 0 is just one instance of "undefined value". > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #6 from Jonathan Wakely --- (In reply to Wilhelm M from comment #5) > So in general a scoped-enum inside a class (nested type) maybe always a bad > idea, because it prevents optimization. I don't know how you have drawn that conclusion or how it's related to this bug report. > And when specifying the underlying > type, the -fstrict-enums can't be applied because all values of the > underlying type are possible. Correct, with a fixed underlying type -fstrict-enums and -fshort-enums have no effect.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #1 from Puneet B --- Here issue is weakref symbol in gcc not using the __asm_ function pointed by pthread.h instead its calling directly ___pthread_cond_timedwait which is exposed by version_symbol in pthread_cond_wait.c of glibc
[Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Bug ID: 109540
Summary: Y2038: GCC gthr-posix.h weakref symbol invoking
function has impact on time values
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: punitb20 at gmail dot com
Target Milestone: ---
All
if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038
fix(where all timer related variable moved to 64 bit instead of 32 bit ),
pthread_cond_timedwait function from gthr_posix.h is calling different function
in pthrea_cond_wait.c of glibc(due to weakref of symbol
pthread_cond_timedwait()) which impacting the time value.
>From pthread.h
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
>From gthread_posix.h:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
__gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in
glibc instead of __pthread_cond_timedwait64 which is impacting time value as
__pthread_cond_timedwait is converting value from 32 bit to 64 bit.
normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly
and its working fine.
From: pthread_cond_wait.c
#if __TIMESIZE == 64
strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
#else
strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
libc_hidden_def (__pthread_cond_timedwait64)
int
___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
const struct timespec *abstime)
{
struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
return __pthread_cond_timedwait64 (cond, mutex, );
}
#endif /* __TIMESIZE == 64 */
versioned_symbol (libc, ___pthread_cond_timedwait,
pthread_cond_timedwait, GLIBC_2_3_2);
libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
#ifndef SHARED
strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
#endif
if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved
but that is not correct way as it disable weakref for all symbol, please let me
know what is correct way to fix this, this i observed with gcc-9.3.0 gcc and
glibc 2.34
Regards
Puneet
[Bug testsuite/106879] [13/14 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #5 from Jiu Fu Guo --- Like PR65484 and PR87306. On P7, option -mno-allow-movmisalign is added during testing, which prevents slp happen on the code.
[Bug tree-optimization/109176] [11 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] internal |[11 Regression] internal |compiler error: in |compiler error: in |to_constant, at |to_constant, at |poly-int.h:504 |poly-int.h:504 --- Comment #19 from Jakub Jelinek --- Fixed also for 12.3.
[Bug middle-end/106190] [10/11 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in expand_builtin_eh_common |expand_builtin_eh_common |with -fnon-call-exceptions |with -fnon-call-exceptions |-fsanitize=address,undefine |-fsanitize=address,undefine |d -fno-sanitize-recover=all |d -fno-sanitize-recover=all --- Comment #12 from Jakub Jelinek --- Fixed also for 12.3.
[Bug ipa/105685] [10/11 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] Bogus |[10/11 Regression] Bogus |`-Wsuggest-attribute=cold` |`-Wsuggest-attribute=cold` |on function already marked |on function already marked |as `__attribute__((cold))` |as `__attribute__((cold))` --- Comment #8 from Jakub Jelinek --- Fixed also for 12.3.
