[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #18 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:2d6874ac667e215604ad1521e25eed9d12c98956 commit r15-1199-g2d6874ac667e215604ad1521e25eed9d12c98956 Author: Gerald Pfeifer Date: Wed Jun 12 09:00:40 2024 +0200 doc: Update Cygwin web link gcc: PR target/69374 * doc/install.texi (Specific) <*-*-cygwin>: Update web link.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #17 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:919e88f7915b57ae3a2152a1947dbfac3fccfe88 commit r15-1197-g919e88f7915b57ae3a2152a1947dbfac3fccfe88 Author: Gerald Pfeifer Date: Wed Jun 12 08:46:20 2024 +0200 doc: Simplify *-*-linux-gnu dependencies Glibc 2.1 was released in 1999, binutils 2.12 in 2002; no need to explicitly list them as dependencies any longer. gcc: PR target/69374 * doc/install.texi (Specific) <*-*-linux-gnu>: Do not list glibc 2.1 and binutils 2.12 as minimum dependencies.
[Bug tree-optimization/113681] [14/15 Regression] ICE in tree_profiling, at tree-profile.cc:803 since r14-6201-gf0a90c7d7333fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113681 --- Comment #2 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:66f48557e11a530646e5562c50a75b4b9839f171 commit r15-1196-g66f48557e11a530646e5562c50a75b4b9839f171 Author: Alexandre Oliva Date: Wed Jun 12 00:16:27 2024 -0300 [tree-prof] skip if errors were seen [PR113681] ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we don't reach that state and ICE if e.g. ipa-strub passes report errors. Skip this pass if errors were seen. for gcc/ChangeLog PR tree-optimization/113681 * tree-profile.cc (pass_ipa_tree_profile::gate): Skip if seen_errors. for gcc/testsuite/ChangeLog PR tree-optimization/113681 * c-c++-common/strub-pr113681.c: New.
[Bug rtl-optimization/115384] [15 Regression] ICE: RTL check: expected code 'const_int', have 'const_wide_int' in simplify_binary_operation_1, at simplify-rtx.cc:4088 since r15-1047-g7876cde25cbd2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115384 --- Comment #4 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1d496d2cd1d5d8751a1637abca89339d6f9ddd3b commit r15-1191-g1d496d2cd1d5d8751a1637abca89339d6f9ddd3b Author: liuhongt Date: Tue Jun 11 10:23:27 2024 +0800 Fix ICE in rtl check due to CONST_WIDE_INT in CONST_VECTOR_DUPLICATE_P The patch add extra check to make sure the component of CONST_VECTOR is CONST_INT_P. gcc/ChangeLog: PR target/115384 * simplify-rtx.cc (simplify_context::simplify_binary_operation_1): Only do the simplification of (AND (ASHIFTRT A imm) mask) to (LSHIFTRT A imm) when the component of const_vector is CONST_INT_P. gcc/testsuite/ChangeLog: * gcc.target/i386/pr115384.c: New test.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #16 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:6bc26cceb243c6f359f65a1afa5515f911f3327d commit r15-1189-g6bc26cceb243c6f359f65a1afa5515f911f3327d Author: Gerald Pfeifer Date: Wed Jun 12 00:04:09 2024 +0200 doc: Remove redundant introduction of x86-64 The same sentence as in the x86_64-*-solaris2* section is in the x86_64-*-* section directly above. gcc: PR target/69374 * doc/install.texi (Specific) : Remove redundant introduction of x86-64.
[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115442 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6eb0e931097a8fec01591051c9ef582d52fe7f0c commit r13-8842-g6eb0e931097a8fec01591051c9ef582d52fe7f0c Author: Andrew Pinski Date: Tue Jun 11 12:30:01 2024 -0700 Fix building JIT with musl libc [PR115442] Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc. Pushed as obvious after a quick build to make sure jit still builds. gcc/jit/ChangeLog: PR jit/115442 * jit-recording.cc: Define INCLUDE_SSTREAM before including system.h and don't directly incldue sstream. Signed-off-by: Andrew Pinski (cherry picked from commit e4244b88d75124f6957bfa080c8ad34017364e53)
[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115442 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e6b1c0820590a1f330099ed7560982b5c6da4e91 commit r14-10304-ge6b1c0820590a1f330099ed7560982b5c6da4e91 Author: Andrew Pinski Date: Tue Jun 11 12:30:01 2024 -0700 Fix building JIT with musl libc [PR115442] Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc. Pushed as obvious after a quick build to make sure jit still builds. gcc/jit/ChangeLog: PR jit/115442 * jit-recording.cc: Define INCLUDE_SSTREAM before including system.h and don't directly incldue sstream. Signed-off-by: Andrew Pinski (cherry picked from commit e4244b88d75124f6957bfa080c8ad34017364e53)
[Bug jit/115442] gcc/jit/jit-recording.cc fails to build against musl: attempt to use poisoned "calloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115442 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e4244b88d75124f6957bfa080c8ad34017364e53 commit r15-1188-ge4244b88d75124f6957bfa080c8ad34017364e53 Author: Andrew Pinski Date: Tue Jun 11 12:30:01 2024 -0700 Fix building JIT with musl libc [PR115442] Just like r13-6662-g0e6f87835ccabf but this time for jit/jit-recording.cc. Pushed as obvious after a quick build to make sure jit still builds. gcc/jit/ChangeLog: PR jit/115442 * jit-recording.cc: Define INCLUDE_SSTREAM before including system.h and don't directly incldue sstream. Signed-off-by: Andrew Pinski
[Bug tree-optimization/115382] Wrong code with in-order conditional reduction and masked loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115382 --- Comment #5 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:2b438a0d2aa80f051a09b245a58f643540d4004b commit r15-1187-g2b438a0d2aa80f051a09b245a58f643540d4004b Author: Robin Dapp Date: Fri Jun 7 14:36:41 2024 +0200 vect: Merge loop mask and cond_op mask in fold-left reduction [PR115382]. Currently we discard the cond-op mask when the loop is fully masked which causes wrong code in gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c when compiled with -O3 -march=cascadelake --param vect-partial-vector-usage=2. This patch ANDs both masks. gcc/ChangeLog: PR tree-optimization/115382 * tree-vect-loop.cc (vectorize_fold_left_reduction): Use prepare_vec_mask. * tree-vect-stmts.cc (check_load_store_for_partial_vectors): Remove static of prepare_vec_mask. * tree-vectorizer.h (prepare_vec_mask): Export.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #35 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a995fded34fe488153b06bb41e026277f01efded commit r12-10548-ga995fded34fe488153b06bb41e026277f01efded Author: Francois-Xavier Coudert Date: Thu Mar 7 14:36:03 2024 +0100 Include safe-ctype.h after C++ standard headers, to avoid over-poisoning When building gcc's C++ sources against recent libc++, the poisoning of the ctype macros due to including safe-ctype.h before including C++ standard headers such as , , etc, causes many compilation errors, similar to: In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: In file included from /home/dim/src/gcc/master/gcc/system.h:233: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces 546 | _LIBCPP_INLINE_VISIBILITY | ^ /usr/include/c++/v1/__config:813:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY' 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI | ^ /usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI' 792 | __attribute__((__abi_tag__(_LIBCPP_TOSTRING( _LIBCPP_VERSIONED_IDENTIFIER | ^ In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: In file included from /home/dim/src/gcc/master/gcc/system.h:233: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of declaration list 547 | char_type toupper(char_type __c) const | ^ /usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation 553 | const char_type* toupper(char_type* __low, const char_type* __high) const |^ /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype | ^ This is because libc++ uses different transitive includes than libstdc++, and some of those transitive includes pull in various ctype declarations (typically via ). There was already a special case for including before safe-ctype.h, so move the rest of the C++ standard header includes to the same location, to fix the problem. PR middle-end/111632 gcc/ChangeLog: * system.h: Include safe-ctype.h after C++ standard headers. Signed-off-by: Dimitry Andric (cherry picked from commit 9970b576b7e4ae337af1268395ff221348c4b34a)
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #34 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:8f11ed1c58e14421ba4be1652764fc47fdce8dc7 commit r12-10547-g8f11ed1c58e14421ba4be1652764fc47fdce8dc7 Author: Francois-Xavier Coudert Date: Sat Mar 16 09:50:00 2024 +0100 libcc1: fix include Use INCLUDE_VECTOR before including system.h, instead of directly including , to avoid running into poisoned identifiers. Signed-off-by: Dimitry Andric PR middle-end/111632 libcc1/ChangeLog: * libcc1plugin.cc: Fix include. * libcp1plugin.cc: Fix include. (cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)
[Bug tree-optimization/115143] [11/12 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 --- Comment #17 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d30afaae6764379a63c22459b40aaecfa82b0fc4 commit r12-10546-gd30afaae6764379a63c22459b40aaecfa82b0fc4 Author: Andrew Pinski Date: Sat May 18 11:55:58 2024 -0700 PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143] The problem here is even if last_and_only_stmt returns a statement, the bb might still contain a phi node which defines a ssa name which is used in that statement so we need to add a check to make sure that the phi nodes are empty for the middle bbs in both the `CMP?MINMAX:MINMAX` case and the `CMP?MINMAX:B` cases. Bootstrapped and tested on x86_64_linux-gnu with no regressions. PR tree-optimization/115143 gcc/ChangeLog: * tree-ssa-phiopt.cc (minmax_replacement): Check for empty phi nodes for middle bbs for the case where middle bb is not empty. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr115143-1.c: New test. * gcc.c-torture/compile/pr115143-2.c: New test. * gcc.c-torture/compile/pr115143-3.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 9ff8f041331ef8b56007fb3c4d41d76f9850010d)
[Bug libstdc++/110542] use of allocated storage after deallocation in a constant expression: std::array of std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110542 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:874896659df65b4bdf85b3dbca0ab527bb4c920e commit r12-10540-g874896659df65b4bdf85b3dbca0ab527bb4c920e Author: Jonathan Wakely Date: Tue Jul 4 16:03:45 2023 +0100 libstdc++: Fix std::__uninitialized_default_n for constant evaluation [PR110542] libstdc++-v3/ChangeLog: PR libstdc++/110542 * include/bits/stl_uninitialized.h (__uninitialized_default_n): Do not use std::fill_n during constant evaluation. (cherry picked from commit 83cae6c4b788544635a71748e1881c150f42efef)
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bd31ecc1c7aef5b4ae7ddb04926a2f4105957df4 commit r12-10538-gbd31ecc1c7aef5b4ae7ddb04926a2f4105957df4 Author: Jonathan Wakely Date: Mon Mar 18 13:22:17 2024 + libstdc++: Fix infinite loop in std::binomial_distribution [PR114359] The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is unsigned and 4 * _M_t wraps to zero. The third operand has type double, so do the second multiplication first, so that we aren't multiplying integers. libstdc++-v3/ChangeLog: PR libstdc++/114359 * include/bits/random.tcc (binomial_distribution::param_type): Ensure arithmetic is done as type double. * testsuite/26_numerics/random/binomial_distribution/114359.cc: New test. (cherry picked from commit 07e03761a7fc1626a6a74ed957e117f56981558c)
[Bug libstdc++/104606] [11/12 Regression] comparison operator resolution with std::optional and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606 --- Comment #17 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:80d0f82e6961ff8991897454e2bac126488ea6b9 commit r12-10536-g80d0f82e6961ff8991897454e2bac126488ea6b9 Author: Jonathan Wakely Date: Wed Mar 27 21:51:13 2024 + libstdc++: Reverse arguments in constraint for std::optional's <=> [PR104606] This is a workaround for a possible compiler bug that causes constraint recursion in the operator<=>(const optional&, const U&) overload. libstdc++-v3/ChangeLog: PR libstdc++/104606 * include/std/optional (operator<=>(const optional&, const U&)): Reverse order of three_way_comparable_with template arguments. * testsuite/20_util/optional/relops/104606.cc: New test. (cherry picked from commit 7f65d8267fbfd19cf21a3dc71d27e989e75044a3)
[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 --- Comment #18 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3494bc7b03997f96e84e84f6904917854466d5ea commit r12-10541-g3494bc7b03997f96e84e84f6904917854466d5ea Author: Jonathan Wakely Date: Fri Jun 9 12:15:21 2023 +0100 libstdc++: Add preprocessor checks to [PR100285] We can't define endpoints and resolvers without the relevant OS support. If IPPROTO_TCP and IPPROTO_UDP are both undefined then we won't need basic_endpoint and basic_resolver anyway, so make them depend on those macros. libstdc++-v3/ChangeLog: PR libstdc++/100285 * include/experimental/internet [IPPROTO_TCP || IPPROTO_UDP] (basic_endpoint, basic_resolver_entry, resolver_base) (basic_resolver_results, basic_resolver): Only define if the tcp or udp protocols will be defined. (cherry picked from commit 793ed718b522b15e2d758eca953feeec1979fe2c)
[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5c2c5805304da2436f4a749d357eee34eae9d792 commit r12-10537-g5c2c5805304da2436f4a749d357eee34eae9d792 Author: Jonathan Wakely Date: Mon Mar 18 13:00:17 2024 + libstdc++: Begin lifetime of storage in std::vector [PR114367] This doesn't cause a problem with GCC, but Clang correctly diagnoses a bug in the code. The objects in the allocated storage need to begin their lifetime before we start using them. This change uses the allocator's construct function instead of using std::construct_at directly, in order to support fancy pointers. libstdc++-v3/ChangeLog: PR libstdc++/114367 * include/bits/stl_bvector.h (_M_allocate): Use allocator's construct function to begin lifetime of words. (cherry picked from commit 16afbd9c9c4282d56062cef95e6eccfdcf3efe03)
[Bug libstdc++/114401] libstdc++ allocator destructor omitted when reinserting node_handle into tree- and hashtable-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114401 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c394e299491ce6dc7e1a51b89165078e11cf75be commit r12-10535-gc394e299491ce6dc7e1a51b89165078e11cf75be Author: Jonathan Wakely Date: Thu Mar 21 13:25:15 2024 + libstdc++: Destroy allocators in re-inserted container nodes [PR114401] The allocator objects in container node handles were not being destroyed after the node was re-inserted into a container. They are stored in a union and so need to be explicitly destroyed when the node becomes empty. The containers were zeroing the node handle's pointer, which makes it empty, causing the handle's destructor to think there's nothing to clean up. Add a new member function to the node handle which destroys the allocator and zeros the pointer. Change the containers to call that instead of just changing the pointer manually. We can also remove the _M_empty member of the union which is not necessary. libstdc++-v3/ChangeLog: PR libstdc++/114401 * include/bits/hashtable.h (_Hashtable::_M_reinsert_node): Call release() on node handle instead of just zeroing its pointer. (_Hashtable::_M_reinsert_node_multi): Likewise. (_Hashtable::_M_merge_unique): Likewise. (_Hashtable::_M_merge_multi): Likewise. * include/bits/node_handle.h (_Node_handle_common::release()): New member function. (_Node_handle_common::_Optional_alloc::_M_empty): Remove unnecessary union member. (_Node_handle_common): Declare _Hashtable as a friend. * include/bits/stl_tree.h (_Rb_tree::_M_reinsert_node_unique): Call release() on node handle instead of just zeroing its pointer. (_Rb_tree::_M_reinsert_node_equal): Likewise. (_Rb_tree::_M_reinsert_node_hint_unique): Likewise. (_Rb_tree::_M_reinsert_node_hint_equal): Likewise. * testsuite/23_containers/multiset/modifiers/114401.cc: New test. * testsuite/23_containers/set/modifiers/114401.cc: New test. * testsuite/23_containers/unordered_multiset/modifiers/114401.cc: New test. * testsuite/23_containers/unordered_set/modifiers/114401.cc: New test. (cherry picked from commit c2e28df90a1640cebadef6c6c8ab5ea964071bb1)
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #15 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:05b95238be648c9cf8af2516930af6a7b637a2b8
commit r15-1183-g05b95238be648c9cf8af2516930af6a7b637a2b8
Author: Uros Bizjak
Date: Tue Jun 11 16:00:31 2024 +0200
i386: Use CMOV in .SAT_{ADD|SUB} expansion for TARGET_CMOV [PR112600]
For TARGET_CMOV targets emit insn sequence involving conditonal move.
.SAT_ADD:
addl%esi, %edi
movl$-1, %eax
cmovnc %edi, %eax
ret
.SAT_SUB:
subl%esi, %edi
movl$0, %eax
cmovnc %edi, %eax
ret
PR target/112600
gcc/ChangeLog:
* config/i386/i386.md (usadd3): Emit insn sequence
involving conditional move for TARGET_CMOVE targets.
(ussub3): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112600-a.c: Also scan for cmov.
* gcc.target/i386/pr112600-b.c: Ditto.
[Bug c/114493] [11/12/13 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #15 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d4126b329b2ae4f2b60efa1c7ad51b576de168bd commit r12-10534-gd4126b329b2ae4f2b60efa1c7ad51b576de168bd Author: Jakub Jelinek Date: Thu Jun 6 22:12:11 2024 +0200 c: Fix up pointer types to may_alias structures [PR114493] The following testcase ICEs in ipa-free-lang, because the fld_incomplete_type_of gcc_assert (TYPE_CANONICAL (t2) != t2 && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); assertion doesn't hold. This is because t is a struct S * type which was created while struct S was still incomplete and without the may_alias attribute (and TYPE_CANONICAL of a pointer type is a type created with can_alias_all = false argument), while later on on the struct definition may_alias attribute was used. fld_incomplete_type_of then creates an incomplete distinct copy of the structure (but with the original attributes) but pointers created for it are because of the "may_alias" attribute TYPE_REF_CAN_ALIAS_ALL, including their TYPE_CANONICAL, because while that is created with !can_alias_all argument, we later set it because of the "may_alias" attribute on the to_type. This doesn't ICE with C++ since PR70512 fix because the C++ FE sets TYPE_REF_CAN_ALIAS_ALL on all pointer types to the class type (and its variants) when the may_alias is added. The following patch does that in the C FE as well. 2024-06-06 Jakub Jelinek PR c/114493 * c-decl.cc (c_fixup_may_alias): New function. (finish_struct): Call it if "may_alias" attribute is specified. * gcc.dg/pr114493-1.c: New test. * gcc.dg/pr114493-2.c: New test. (cherry picked from commit d5a3c6d43acb8b2211d9fb59d59482d74c010f01)
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #15 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b065824e30e9168d33b56039e436c4b09078e260 commit r12-10533-gb065824e30e9168d33b56039e436c4b09078e260 Author: Jakub Jelinek Date: Tue Jun 4 15:49:41 2024 +0200 fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337] The function currently incorrectly assumes all the __builtin_clz* and .CLZ calls have non-negative result. That is the case of the former which is UB on zero and has [0, prec-1] return value otherwise, and is the case of the single argument .CLZ as well (again, UB on zero), but for two argument .CLZ is the case only if the second argument is also nonnegative (or if we know the argument can't be zero, but let's do that just in the ranger IMHO). The following patch does that. 2024-06-04 Jakub Jelinek PR tree-optimization/115337 * fold-const.cc (tree_call_nonnegative_warnv_p) : If fn is CFN_CLZ, use CLZ_DEFINED_VALUE_AT. (cherry picked from commit b82a816000791e7a286c7836b3a473ec0e2a577b)
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789
--- Comment #10 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:91a371254494934e191e3060ae2a86905eb4b2b2
commit r12-10532-g91a371254494934e191e3060ae2a86905eb4b2b2
Author: Jakub Jelinek
Date: Tue Jun 4 12:28:01 2024 +0200
builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow [PR108789]
The following testcase is miscompiled, because we use save_expr
on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first
two operands are not INTEGER_CSTs (in that case we just fold it right away)
but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually
create a SAVE_EXPR at all and so we lower it to
*arg2 = REALPART_EXPR (.ADD_OVERFLOW (arg0, arg1)), \
IMAGPART_EXPR (.ADD_OVERFLOW (arg0, arg1))
which evaluates the ifn twice and just hope it will be CSEd back.
As *arg2 aliases *arg0, that is not the case.
The builtins are really never const/pure as they store into what
the third arguments points to, so after handling the
INTEGER_CST+INTEGER_CST
case, I think we should just always use SAVE_EXPR. Just building SAVE_EXPR
by hand and setting TREE_SIDE_EFFECTS on it doesn't work, because
c_fully_fold optimizes it away again, so the following patch marks the
ifn calls as TREE_SIDE_EFFECTS (but doesn't do it for the
__builtin_{add,sub,mul}_overflow_p case which were designed for use
especially in constant expressions and don't really evaluate the
realpart side, so we don't really need a SAVE_EXPR in that case).
2024-06-04 Jakub Jelinek
PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr.
* gcc.c-torture/execute/pr108789.c: New test.
(cherry picked from commit b8e28381cb5c0cddfe5201faf799d8b27f5d7d6c)
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 --- Comment #15 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:840bc6741680a9c4b58fa1005f19a5d2e7d4be1f commit r12-10530-g840bc6741680a9c4b58fa1005f19a5d2e7d4be1f Author: Jakub Jelinek Date: Wed May 15 18:37:17 2024 +0200 combine: Fix up simplify_compare_const [PR115092] The following testcases are miscompiled (with tons of GIMPLE optimization disabled) because combine sees GE comparison of 1-bit sign_extract (i.e. something with [-1, 0] value range) with (const_int -1) (which is always true) and optimizes it into NE comparison of 1-bit zero_extract ([0, 1] value range) against (const_int 0). The reason is that simplify_compare_const first (correctly) simplifies the comparison to GE (ashift:SI something (const_int 31)) (const_int -2147483648) and then an optimization for when the second operand is power of 2 triggers. That optimization is fine for power of 2s which aren't the signed minimum of the mode, or if it is NE, EQ, GEU or LTU against the signed minimum of the mode, but for GE or LT optimizing it into NE (or EQ) against const0_rtx is wrong, those cases are always true or always false (but the function doesn't have a standardized way to tell callers the comparison is now unconditional). The following patch just disables the optimization in that case. 2024-05-15 Jakub Jelinek PR rtl-optimization/114902 PR rtl-optimization/115092 * combine.cc (simplify_compare_const): Don't optimize GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or EQ op0 const0_rtx. * gcc.dg/pr114902.c: New test. * gcc.dg/pr115092.c: New test. (cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)
[Bug sanitizer/114956] [11/12 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:25bd98dfd99e92c57ff393d393f54d028d7f86f4 commit r12-10529-g25bd98dfd99e92c57ff393d393f54d028d7f86f4 Author: Jakub Jelinek Date: Tue May 7 21:29:14 2024 +0200 tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956] In r9-5742 we've started allowing to inline always_inline functions into functions which have disabled e.g. address sanitization even when the always_inline function is implicitly from command line options sanitized. This mostly works fine because most of the asan instrumentation is done only late after ipa, but as the following testcase the .ASAN_MARK ifn calls gimplifier adds can result in ICEs. Fixed by dropping those during inlining, similarly to how we drop .TSAN_FUNC_EXIT calls. 2024-05-07 Jakub Jelinek PR sanitizer/114956 * tree-inline.cc: Include asan.h. (copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has asan/hwasan sanitization disabled. * gcc.dg/asan/pr114956.c: New test. (cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)
[Bug rtl-optimization/114902] [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #18 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:840bc6741680a9c4b58fa1005f19a5d2e7d4be1f commit r12-10530-g840bc6741680a9c4b58fa1005f19a5d2e7d4be1f Author: Jakub Jelinek Date: Wed May 15 18:37:17 2024 +0200 combine: Fix up simplify_compare_const [PR115092] The following testcases are miscompiled (with tons of GIMPLE optimization disabled) because combine sees GE comparison of 1-bit sign_extract (i.e. something with [-1, 0] value range) with (const_int -1) (which is always true) and optimizes it into NE comparison of 1-bit zero_extract ([0, 1] value range) against (const_int 0). The reason is that simplify_compare_const first (correctly) simplifies the comparison to GE (ashift:SI something (const_int 31)) (const_int -2147483648) and then an optimization for when the second operand is power of 2 triggers. That optimization is fine for power of 2s which aren't the signed minimum of the mode, or if it is NE, EQ, GEU or LTU against the signed minimum of the mode, but for GE or LT optimizing it into NE (or EQ) against const0_rtx is wrong, those cases are always true or always false (but the function doesn't have a standardized way to tell callers the comparison is now unconditional). The following patch just disables the optimization in that case. 2024-05-15 Jakub Jelinek PR rtl-optimization/114902 PR rtl-optimization/115092 * combine.cc (simplify_compare_const): Don't optimize GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or EQ op0 const0_rtx. * gcc.dg/pr114902.c: New test. * gcc.dg/pr115092.c: New test. (cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)
[Bug fortran/114825] [11/12 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cc96dc569f74b7410a97b4beee16435fc2abcfdd commit r12-10527-gcc96dc569f74b7410a97b4beee16435fc2abcfdd Author: Jakub Jelinek Date: Thu Apr 25 20:09:35 2024 +0200 openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825] tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used both for debug info and OpenMP/OpenACC lowering purposes, the other solely for OpenMP/OpenACC lowering purposes. When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly Fortran, C just a little and C++ doesn't have nested functions) then inspect the flags on the vars and based on that decide how to lower the corresponding clauses. Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so the langhooks made decisions on the default flags on those instead. As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL, using copy_node wouldn't work properly, so this patch just copies those flags in addition to other flags it was copying already. And I've removed code duplication by introducing a helper function which does copying common to both uses. 2024-04-25 Jakub Jelinek PR fortran/114825 * tree-nested.cc (get_debug_decl): New function. (get_nonlocal_debug_decl): Use it. (get_local_debug_decl): Likewise. * gfortran.dg/gomp/pr114825.f90: New test. (cherry picked from commit 14d48516e588ad2b35e2007b3970bdcb1b3f145c)
[Bug tree-optimization/114876] [11/12 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
--- Comment #11 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bf134407b494bf79f66fc5048ff0ca409275089c
commit r12-10528-gbf134407b494bf79f66fc5048ff0ca409275089c
Author: Jakub Jelinek
Date: Tue Apr 30 11:22:32 2024 +0200
gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument
[PR114876]
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max ==
0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7d0673575aba5dfb41022897a882b9c386c332f4 commit r12-10526-g7d0673575aba5dfb41022897a882b9c386c332f4 Author: Jakub Jelinek Date: Fri Apr 19 08:47:53 2024 +0200 rtlanal: Fix set_noop_p for volatile loads or stores [PR114768] On the following testcase, combine propagates the mem/v load into mem store with the same address and then removes it, because noop_move_p says it is a no-op move. If it was the other way around, i.e. mem/v store and mem load, or both would be mem/v, it would be kept. The problem is that rtx_equal_p never checks any kind of flags on the rtxes (and I think it would be quite dangerous to change it at this point), and set_noop_p checks side_effects_p on just one of the operands, not both. In the MEM <- MEM set, it only checks it on the destination, in store to ZERO_EXTRACT only checks it on the source. The following patch adds the missing side_effects_p checks. 2024-04-19 Jakub Jelinek PR rtl-optimization/114768 * rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM sets if src has side-effects or for stores into ZERO_EXTRACT if ZERO_EXTRACT operand has side-effects. * gcc.dg/pr114768.c: New test. (cherry picked from commit 9f295847a9c32081bdd0fe908ffba58e830a24fb)
[Bug target/115324] [12/13 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bda8c28e6fcdbe0b486b54616877eec32c86d322
commit r12-10531-gbda8c28e6fcdbe0b486b54616877eec32c86d322
Author: Jakub Jelinek
Date: Mon Jun 3 23:11:06 2024 +0200
rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or _instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them
back
in full. While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.
So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.
Size-wise in .data sections it is (in bytes):
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.
Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.
When I applied
void
rs6000_init_generated_builtins ()
{
+ bifdata *rs6000_builtin_info_p;
+ tree *rs6000_builtin_info_fntype_p;
+ ovlddata *rs6000_instance_info_p;
+ tree *rs6000_instance_info_fntype_p;
+ ovldrecord *rs6000_overload_info_p;
+ __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+ __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+ __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+ __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+ __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+ #define rs6000_builtin_info rs6000_builtin_info_p
+ #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+ #define rs6000_instance_info rs6000_instance_info_p
+ #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+ #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
2024-06-03 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members. Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *. Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_info_fntype and rs6000_instance_info_fntype
[Bug c++/114634] [11/12 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bb21a7de31183108bdb2489f987deaf94e4985b6 commit r12-10524-gbb21a7de31183108bdb2489f987deaf94e4985b6 Author: Jakub Jelinek Date: Mon Apr 15 10:25:22 2024 +0200 attribs: Don't crash on NULL TREE_TYPE in diag_attr_exclusions [PR114634] The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions assumes that all decls must have types. I think it is better in something as unimportant as diag_attr_exclusions to be more robust, if there is no type, it can just diagnose exclusions on the DECL_ATTRIBUTES, like for types it only diagnoses it on TYPE_ATTRIBUTES. 2024-04-15 Jakub Jelinek PR c++/114634 * attribs.cc (diag_attr_exclusions): Set attrs[1] to NULL_TREE for decls with NULL TREE_TYPE. * g++.dg/ext/attrib68.C: New test. (cherry picked from commit 7ec54f5fdfec298812a749699874db4d6a7246bb)
[Bug c++/114691] [11/12 Regression] Bogus ignoring loop annotation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e9b960edb01449786a29a8d196c476bfefc4f243 commit r12-10523-ge9b960edb01449786a29a8d196c476bfefc4f243 Author: Jakub Jelinek Date: Fri Apr 12 20:53:10 2024 +0200 c++: Fix bogus warnings about ignored annotations [PR114691] The middle-end warns about the ANNOTATE_EXPR added for while/for loops if they declare a var inside of the loop condition. This is because the assumption is that ANNOTATE_EXPR argument is used immediately in a COND_EXPR (later GIMPLE_COND), but simplify_loop_decl_cond wraps the ANNOTATE_EXPR inside of a TRUTH_NOT_EXPR, so it no longer holds. The following patch fixes that by adding the TRUTH_NOT_EXPR inside of the ANNOTATE_EXPR argument if any. 2024-04-12 Jakub Jelinek PR c++/114691 * semantics.cc (simplify_loop_decl_cond): Use cp_build_unary_op with TRUTH_NOT_EXPR on ANNOTATE_EXPR argument (if any) rather than ANNOTATE_EXPR itself. * g++.dg/ext/pr114691.C: New test. (cherry picked from commit 91146346f57cc54dfeb2669347edd0eb3d13af7f)
[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:b3ef00f8b8d577d7b62cea36c13cf087a3b13d0c
commit r12-10525-gb3ef00f8b8d577d7b62cea36c13cf087a3b13d0c
Author: Jakub Jelinek
Date: Thu Apr 18 09:45:14 2024 +0200
internal-fn: Temporarily disable flag_trapv during .{ADD,SUB,MUL}_OVERFLOW
etc. expansion [PR114753]
__builtin_{add,sub,mul}_overflow{,_p} builtins are well defined
for all inputs even for -ftrapv, and the -fsanitize=signed-integer-overflow
ifns shouldn't abort in libgcc but emit the desired ubsan diagnostics
or abort depending on -fsanitize* setting regardless of -ftrapv.
The expansion of these internal functions uses expand_expr* in various
places (e.g. MULT_EXPR at least in 2 spots), so temporarily disabling
flag_trapv in all those spots would be hard.
The following patch disables it around the bodies of 3 functions
which can do the expand_expr calls.
If it was in the C++ FE, I'd use some RAII sentinel, but I don't think
we have one in the middle-end.
2024-04-18 Jakub Jelinek
PR middle-end/114753
* internal-fn.cc (expand_mul_overflow): Save flag_trapv and
temporarily clear it for the duration of the function, then
restore previous value.
(expand_vector_ubsan_overflow): Likewise.
(expand_arith_overflow): Likewise.
* gcc.dg/pr114753.c: New test.
(cherry picked from commit 6c152c9db3b5b9d43e12846fb7a44977c0b65fc2)
[Bug middle-end/110027] [11/12 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 --- Comment #27 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:082fe43efd241caf8f757c056b98e1ae8b55c300 commit r12-10522-g082fe43efd241caf8f757c056b98e1ae8b55c300 Author: Jakub Jelinek Date: Thu Apr 11 11:12:11 2024 +0200 asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027] On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote: > > > So, try to add some other variable with larger size and smaller alignment > > > to the frame (and make sure it isn't optimized away). > > > > > > alignb above is the alignment of the first partition's var, if > > > align_frame_offset really needs to depend on the var alignment, it probably > > > should be the maximum alignment of all the vars with alignment > > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT > > > > > In asan_emit_stack_protection, when it allocated fake stack, it assume > bottom of stack is also aligned to alignb. And the place violated this > is the first var partition. which is 32 bytes offsets, it should be > BIGGEST_ALIGNMENT / BITS_PER_UNIT. > So I think we need to use MAX (BIGGEST_ALIGNMENT / > BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition. Your first patch aligned offsets[0] to maximum of alignb and ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb there is the alignment of just a single variable which is the first one to appear in the sorted list and is placed in the highest spot in the stack frame. That is not necessarily the largest alignment, the sorting ensures that it is a variable with the largest size in the frame (and only if several of them have equal size, largest alignment from the same sized ones). Your second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using -mno-avx512f - offsets[0] is still just 32-byte aligned in that case relative to top of frame, just changes the -mavx512f case to be 64-byte aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of either 0 or -32). That will not help if any variable in the frame needs 128-byte, 256-byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in the spot you've touched, you'd need to walk all the stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those where the loop would do anything (i.e. stack_vars[i2].representative == i2 && TREE_CODE (decl2) == SSA_NAME ? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX : DECL_RTL (decl2) == pc_rtx and the pred applies (but that means also walking the earlier ones! because with -fstack-protector* the vars can be processed in several calls) and alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT and compute maximum of those alignments. That maximum is already computed, data->asan_alignb = MAX (data->asan_alignb, alignb); computes that, but you get the final result only after you do all the expand_stack_vars calls. You'd need to compute it before. Though, that change would be still in the wrong place. The thing is, it would be a waste of the precious stack space when it isn't needed at all (e.g. when asan will not at compile time do the use after return checking, or if it won't do it at runtime, or even if it will do at runtime it will waste the space on the stack). The following patch fixes it solely for the __asan_stack_malloc_N allocations, doesn't enlarge unnecessarily further the actual stack frame. Because asan is only supported on FRAME_GROWS_DOWNWARD architectures (mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1, otherwise 0, others supporting asan always just use 1), the assumption for the dynamic stack realignment is that the top of the stack frame (aka offset 0) is aligned to alignb passed to the function (which is the maximum of alignb of all the vars in the frame). As checked by the assertion in the patch, offsets[0] is 0 most of the time and so that assumption is correct, the only case when it is not 0 is if -fstack-protector* is on together with -fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack guard. That is the only variable which is allocated in the stack frame right away, for all others with -fsanitize=address defer_stack_allocation (or -fstack-protector*) returns true and so they aren't allocated immediately but handled during the frame layout phases. So, the original frame_offset of 0 is changed because of the stack guard to -pointer_size_in_bytes and later
[Bug tree-optimization/114566] [11/12 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #20 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f8a327930b82e89ae1466cfacb9e8ac9f5c44e77 commit r12-10520-gf8a327930b82e89ae1466cfacb9e8ac9f5c44e77 Author: Jakub Jelinek Date: Fri Apr 5 14:56:14 2024 +0200 vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566] The following testcase is miscompiled, because in the vectorized epilogue the vectorizer assumes it can use aligned loads/stores (if the base decl gets alignment increased), but it actually doesn't increase that. This is because r10-4203-g97c1460367 added the hunk following patch removes. The explanation feels reasonable, but actually it is not true as the testcase proves. The thing is, we vectorize the main loop with 64-byte vectors and the corresponding data refs have base_alignment 16 (the a array has DECL_ALIGN 128) and offset_alignment 32. Now, because of the offset_alignment 32 rather than 64, we need to use unaligned loads/stores in the main loop (and ditto in the first load/store in vectorized epilogue). But the second load/store in the vectorized epilogue uses only 32-byte vectors and because it is a multiple of offset_alignment, it checks if we could increase alignment of the a VAR_DECL, the function returns true, sets base_misaligned = true and says the access is then aligned. But when update_epilogue_loop_vinfo clears base_misaligned with the assumption that the var had to have the alignment increased already, the update of DECL_ALIGN doesn't happen anymore. Now, I'd think this base_alignment = false was needed before r10-4030-gd2db7f7901 change was committed where it incorrectly overwrote DECL_ALIGN even if it was already larger, rather than just always increasing it. But with that change in, it doesn't make sense to me anymore. Note, the testcase is latent on the trunk, but reproduces on the 13 branch. 2024-04-05 Jakub Jelinek PR tree-optimization/114566 * tree-vect-loop.cc (update_epilogue_loop_vinfo): Don't clear base_misaligned. * gcc.target/i386/avx512f-pr114566.c: New test. (cherry picked from commit a844095e17c1a5aada1364c6f6eaade87ead463c)
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #15 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9987fe67cf6211515d8ebf6528cc83c77dfb5bf3
commit r12-10517-g9987fe67cf6211515d8ebf6528cc83c77dfb5bf3
Author: Jakub Jelinek
Date: Wed Apr 3 10:02:35 2024 +0200
libquadmath: Don't assume the storage for __float128 arguments is aligned
[PR114533]
With the
register_printf_type/register_printf_modifier/register_printf_specifier
APIs the C library is just told the size of the argument and is provided
with
a callback to fetch the argument from va_list using va_arg into C library
provided
memory. The C library isn't told what alignment requirement it has, but we
were
using direct load of a __float128 value from that memory which assumes
__alignof (__float128) alignment.
The following patch fixes that by using memcpy instead.
I haven't been able to reproduce an actual crash, tried
#include
#include
#include
int main ()
{
__float128 r;
int prec = 20;
int width = 46;
char buf[128];
r = 2.0q;
r = sqrtq (r);
int n = quadmath_snprintf (buf, sizeof buf, "%+-#*.20Qe", width, r);
if ((size_t) n < sizeof buf)
printf ("%s\n", buf);
/* Prints: +1.41421356237309504880e+00 */
quadmath_snprintf (buf, sizeof buf, "%Qa", r);
if ((size_t) n < sizeof buf)
printf ("%s\n", buf);
/* Prints: 0x1.6a09e667f3bcc908b2fb1366ea96p+0 */
n = quadmath_snprintf (NULL, 0, "%+-#46.*Qe", prec, r);
if (n > -1)
{
char *str = malloc (n + 1);
if (str)
{
quadmath_snprintf (str, n + 1, "%+-#46.*Qe", prec, r);
printf ("%s\n", str);
/* Prints: +1.41421356237309504880e+00 */
}
free (str);
}
printf ("%+-#*.20Qe\n", width, r);
printf ("%Qa\n", r);
printf ("%+-#46.*Qe\n", prec, r);
printf ("%d %Qe %d %Qe %d %Qe\n", 1, r, 2, r, 3, r);
return 0;
}
In any case, I think memcpy for loading from it is right.
2024-04-03 Simon Chopin
Jakub Jelinek
PR libquadmath/114533
* printf/printf_fp.c (__quadmath_printf_fp): Use memcpy to copy
__float128 out of args.
* printf/printf_fphex.c (__quadmath_printf_fphex): Likewise.
Signed-off-by: Simon Chopin
(cherry picked from commit 8455d6f6cd43b7b143ab9ee19437452fceba9cc9)
[Bug c++/114580] Bogus warning on if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b3b7176d5857f116a4a42d885df70f8847e4cd2a commit r12-10521-gb3b7176d5857f116a4a42d885df70f8847e4cd2a Author: Jakub Jelinek Date: Tue Apr 9 09:31:42 2024 +0200 c++: Fix up maybe_warn_for_constant_evaluated calls [PR114580] When looking at maybe_warn_for_constant_evaluated for the trivial infinite loops patch, I've noticed that it can emit weird diagnostics for if constexpr in templates, first warn that std::is_constant_evaluted() always evaluates to false (because the function template is not constexpr) and then during instantiation warn that std::is_constant_evaluted() always evaluates to true (because it is used in if constexpr condition). Now, only the latter is actually true, even when the if constexpr is in a non-constexpr function, it will still always evaluate to true. So, the following patch fixes it to call maybe_warn_for_constant_evaluated always with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument rather than true if it is if constexpr with non-dependent condition etc. 2024-04-09 Jakub Jelinek PR c++/114580 * semantics.cc (finish_if_stmt_cond): Call maybe_warn_for_constant_evaluated with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument, rather than true/false depending on if it is if constexpr with non-dependent constant expression with bool type. * g++.dg/cpp2a/is-constant-evaluated15.C: New test. (cherry picked from commit cfed80b9e4f562c99679739548df9369117dd791)
[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f33e8ee4cb44e7a6326a894a9c153557238bde03 commit r12-10519-gf33e8ee4cb44e7a6326a894a9c153557238bde03 Author: Jakub Jelinek Date: Fri Apr 5 09:31:28 2024 +0200 c++: Fix ICE with weird copy assignment operator [PR114572] While ctors/dtors don't return anything (undeclared void or this pointer on arm) and copy assignment operators normally return a reference to *this, it isn't invalid to return uselessly some class object which might need destructing, but the OpenMP clause handling code wasn't expecting that. The following patch fixes that. 2024-04-05 Jakub Jelinek PR c++/114572 * cp-gimplify.cc (cxx_omp_clause_apply_fn): Call build_cplus_new on build_call_a result if it has class type. * testsuite/libgomp.c++/pr114572.C: New test. (cherry picked from commit 592536eb3c0a97a55b1019ff0216ef77e6ca847e)
[Bug c++/114537] bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:42afabb838d511f5feb150bfa4e68b5880aae1fa commit r12-10518-g42afabb838d511f5feb150bfa4e68b5880aae1fa Author: Jakub Jelinek Date: Thu Apr 4 10:47:52 2024 +0200 fold-const: Handle NON_LVALUE_EXPR in native_encode_initializer [PR114537] The following testcase is incorrectly rejected. The problem is that for bit-fields native_encode_initializer expects the corresponding CONSTRUCTOR elt value must be INTEGER_CST, but that isn't the case here, it is wrapped into NON_LVALUE_EXPR by maybe_wrap_with_location. We could STRIP_ANY_LOCATION_WRAPPER as well, but as all we are looking for is INTEGER_CST inside, just looking through NON_LVALUE_EXPR seems easier. 2024-04-04 Jakub Jelinek PR c++/114537 * fold-const.cc (native_encode_initializer): Look through NON_LVALUE_EXPR if val is INTEGER_CST. * g++.dg/cpp2a/bit-cast16.C: New test. (cherry picked from commit 1baec8deb014b8a7da58879a407a4c00cdeb5a09)
[Bug rtl-optimization/110079] [11/12 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079
--- Comment #9 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:b294d461e2efd6894ba6570ca003701c20fc3cd8
commit r12-10514-gb294d461e2efd6894ba6570ca003701c20fc3cd8
Author: Jakub Jelinek
Date: Thu Mar 7 10:02:49 2024 +0100
bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm
goto [PR110079]
The following testcase ICEs, because fix_crossing_unconditional_branches
thinks that asm goto is an unconditional jump and removes it, replacing it
with unconditional jump to one of the labels.
This doesn't happen on x86 because the function in question isn't invoked
there at all:
/* If the architecture does not have unconditional branches that
can span all of memory, convert crossing unconditional branches
into indirect jumps. Since adding an indirect jump also adds
a new register usage, update the register usage information as
well. */
if (!HAS_LONG_UNCOND_BRANCH)
fix_crossing_unconditional_branches ();
I think for the asm goto case, for the non-fallthru edge if any we should
handle it like any other fallthru (and fix_crossing_unconditional_branches
doesn't really deal with those, it only looks at explicit branches at the
end of bbs and we are in cfglayout mode at that point) and for the labels
we just pass the labels as immediates to the assembly and it is up to the
user to figure out how to store them/branch to them or whatever they want
to
do.
So, the following patch fixes this by not treating asm goto as a simple
unconditional jump.
I really think that on the !HAS_LONG_UNCOND_BRANCH targets we have a bug
somewhere else, where outofcfglayout or whatever should actually create
those indirect jumps on the crossing edges instead of adding normal
unconditional jumps, I see e.g. in
__attribute__((cold)) int bar (char *);
__attribute__((hot)) int baz (char *);
void qux (int x) { if (__builtin_expect (!x, 1)) goto l1; bar (""); goto
l1; l1: baz (""); }
void corge (int x) { if (__builtin_expect (!x, 0)) goto l1; baz (""); l2:
return; l1: bar (""); goto l2; }
with -O2 -freorder-blocks-and-partition on aarch64 before/after this patch
just b .L? jumps which I believe are +-32MB, so if .text is larger than
32MB, it could fail to link, but this patch doesn't address that.
2024-03-07 Jakub Jelinek
PR rtl-optimization/110079
* bb-reorder.cc (fix_crossing_unconditional_branches): Don't adjust
asm goto.
* gcc.dg/pr110079.c: New test.
(cherry picked from commit b209d905f5ce1fa9d76ce634fd54245ff340960b)
[Bug target/114310] [11/12 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f484597028f2b2862bf22003dbae25c24ce5930 commit r12-10515-g9f484597028f2b2862bf22003dbae25c24ce5930 Author: Jakub Jelinek Date: Thu Mar 14 14:09:20 2024 +0100 aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310] The following testcase ICEs with LSE atomics. The problem is that the @atomic_compare_and_swap expander uses aarch64_reg_or_zero predicate for the desired operand, which is fine, given that for most of the modes and even for TImode in some cases it can handle zero immediate just fine, but the TImode @aarch64_compare_and_swap_lse just uses register_operand for that operand instead, again intentionally so, because the casp, caspa, caspl and caspal instructions need to use a pair of consecutive registers for the operand and xzr is just one register and we can't just store zero into the link register to emulate pair of zeros. So, the following patch fixes that by forcing the newval operand into a register for the TImode LSE case. 2024-03-14 Jakub Jelinek PR target/114310 * config/aarch64/aarch64.cc (aarch64_expand_compare_and_swap): For TImode force newval into a register. * gcc.dg/pr114310.c: New test. (cherry picked from commit 9349aefa1df7ae36714b7b9f426ad46e314892d1)
[Bug ipa/113907] [11/12/13/14/15 regression] ICU miscompiled on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #80 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:81c300bf6836505ef1df1c4430972863c732fc14
commit r12-10516-g81c300bf6836505ef1df1c4430972863c732fc14
Author: Jakub Jelinek
Date: Thu Mar 14 17:48:30 2024 +0100
icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions
[PR113907]
AFAIK we have no code in LTO streaming to stream out or in
SSA_NAME_{RANGE,PTR}_INFO, so LTO effectively throws it all away
and let vrp1 and alias analysis after IPA recompute that. There is
just one spot, for IPA VRP and IPA bit CCP we save/restore ranges
and set SSA_NAME_{PTR,RANGE}_INFO e.g. on parameters depending on what
we saved and propagated, but that is after streaming in bodies for the
post IPA optimizations.
Now, without LTO SSA_NAME_{RANGE,PTR}_INFO is already computed from
earlier in many cases (er.g. evrp and early alias analysis but other spots
too), but IPA ICF is ignoring the ranges and points-to details when
comparing the bodies. I think ignoring that is just fine, that is
effectively what we do for LTO where we throw that information away
before the analysis, and not ignoring it could lead to fewer ICF merging
possibilities.
So, the following patch instead verifies that for LTO
SSA_NAME_{PTR,RANGE}_INFO
just isn't there on SSA_NAMEs in functions into which other functions have
been ICFed, and for non-LTO throws that information away (which matches the
LTO behavior).
Another possibility would be to remember the SSA_NAME <-> SSA_NAME mapping
vector (just one of the 2) on successful sem_function::equals on the
sem_function which is not the chosen leader (e.g. how SSA_NAMEs in the
leader map to SSA_NAMEs in the other function) and use that vector
to union the ranges in sem_function::merge. I can implement that for
comparison, but wanted to post this first if there is an agreement on
doing that or if Honza thinks we should take SSA_NAME_{RANGE,PTR}_INFO
into account. I think we can compare SSA_NAME_RANGE_INFO, but have
no idea how to try to compare points to info. And I think it will result
in less effective ICF for non-LTO vs. LTO unnecessarily.
2024-03-12 Jakub Jelinek
PR middle-end/113907
* ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF
merged
functions.
* gcc.dg/pr113907-1.c: New test.
(cherry picked from commit 7580e39452b65ab5fb5a06f3f1ad7d59720269b5)
[Bug target/114184] [12 Regression] ICE: in extract_insn, at recog.cc:2812 (unrecognizable insn ) with _Complex long double and vector VCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114184 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:929972273e858a9a913b0d74e69ac2f8d7255c28 commit r12-10513-g929972273e858a9a913b0d74e69ac2f8d7255c28 Author: Jakub Jelinek Date: Mon Mar 4 10:04:19 2024 +0100 i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184] The Intel extended format has the various weird number categories, pseudo denormals, pseudo infinities, pseudo NaNs and unnormals. Those are not representable in the GCC real_value and so neither GIMPLE nor RTX VIEW_CONVERT_EXPR/SUBREG folding folds those into constants. As can be seen on the following testcase, because it isn't folded (since GCC 12, before that we were folding it) we can end up with a SUBREG of a CONST_VECTOR or similar constant, which isn't valid general_operand, so we ICE during vregs pass trying to recognize the move instruction. Initially I thought it is a middle-end bug, the movxf instruction has general_operand predicate, but the middle-end certainly never tests that predicate, seems moves are special optabs. And looking at other mov optabs, e.g. for vector modes the i386 patterns use nonimmediate_operand predicate on the input, yet ix86_expand_vector_move deals with CONSTANT_P and SUBREG of CONSTANT_P arguments which if the predicate was checked couldn't ever make it through. The following patch handles this case similarly to the ix86_expand_vector_move's SUBREG of CONSTANT_P case, does it just for XFmode because I believe that is the only mode that needs it from the scalar ones, others should just be folded. 2024-03-04 Jakub Jelinek PR target/114184 * config/i386/i386-expand.cc (ix86_expand_move): If XFmode op1 is SUBREG of CONSTANT_P, force the SUBREG_REG into memory or register. * gcc.target/i386/pr114184.c: New test. (cherry picked from commit ea1c16f95b8fbaba4a7f3663ff9933ebedfb92a5)
[Bug target/113122] Assembler messages: Error: operand type mismatch for `movabs' / bad expression / invalid use of register with -fprofile -mcmodel=large -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113122
--- Comment #5 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bc51280bea76a382875da36e45ebb265b8c0
commit r12-10507-gbc51280bea76a382875da36e45ebb265b8c0
Author: Jakub Jelinek
Date: Thu Jan 18 10:21:12 2024 +0100
i386: Add -masm=intel profiling support [PR113122]
x86_function_profiler emits assembly directly into file and only emits
AT syntax. The following patch adjusts it to emit MASM syntax
if -masm=intel.
As it doesn't use asm_fprintf, I can't use {|} syntax for the dialects.
I've tested using
for i in -mcmodel=large "-mcmodel=large -fpic" "" -fpic "-m32 -fpic"
"-m32"; do
./xgcc -B ./ -c -O2 -fprofile $i -masm=att pr113122.c -o pr113122.o1;
./xgcc -B ./ -c -O2 -fprofile $i -masm=intel pr113122.c -o pr113122.o2;
objdump -dr pr113122.o1 > /tmp/1; objdump -dr pr113122.o2 > /tmp/2;
diff -up /tmp/1 /tmp/2; done
that the emitted sequences are identical after assembly.
2024-01-18 Jakub Jelinek
PR target/113122
* config/i386/i386.cc (x86_function_profiler): Add -masm=intel
support. Add missing space after , in emitted assembly in some
cases. Formatting fixes.
* gcc.target/i386/pr113122-1.c: New test.
* gcc.target/i386/pr113122-2.c: New test.
* gcc.target/i386/pr113122-3.c: New test.
* gcc.target/i386/pr113122-4.c: New test.
(cherry picked from commit d4a2d91b46b2cf758b249a4545e34287e90da23b)
[Bug tree-optimization/113603] [12 Regression] ICE Segfault during GIMPLE pass: strlen at -O3 since r12-145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113603
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f5758e8142d8926f9a3e3500ba3c9956054dfaf8
commit r12-10509-gf5758e8142d8926f9a3e3500ba3c9956054dfaf8
Author: Jakub Jelinek
Date: Tue Jan 30 09:58:05 2024 +0100
tree-ssa-strlen: Fix up handle_store [PR113603]
Since r10-2101-gb631bdb3c16e85f35d3 handle_store uses
count_nonzero_bytes{,_addr} which (more recently limited to statements
with the same vuse) can walk earlier statements feeding the rhs
of the store and call get_stridx on it.
Unlike most of the other functions where get_stridx is called first on
rhs and only later on lhs, handle_store calls get_stridx on the lhs before
the count_nonzero_bytes* call and does some si->nonzero_bytes comparison
on it.
Now, strinfo structures are refcounted and it is important not to screw
it up.
What happens on the following testcase is that we call get_strinfo on the
destination idx's base (g), which returns a strinfo at that moment
with refcount of 2, one copy referenced in bb 2 final strinfos, one in bb 3
(the vector of strinfos was unshared from the dominator there because some
other strinfo was added) and finally we process a store in bb 6.
Now, count_nonzero_bytes is called and that sees [1] in a PHI and
calls get_stridx on it, which in turn calls get_stridx_plus_constant
because + 1 address doesn't have stridx yet. This creates a new
strinfo for it:
si = new_strinfo (ptr, idx, build_int_cst (size_type_node,
nonzero_chars),
basesi->full_string_p);
set_strinfo (idx, si);
and the latter call, because it is the first one in bb 6 that needs it,
unshares the stridx_to_strinfo vector (so refcount of the g strinfo becomes
3).
Now, get_stridx_plus_constant needs to chain the new strinfo of [1] in
between the related strinfos, so after the g record. Because the strinfo
is now shared between the current bb and 2 other bbs, it needs to
unshare_strinfo it (creating a new strinfo which can be modified as a copy
of the old one, decrementing refcount of the old shared one and setting
refcount of the new one to 1):
if (strinfo *nextsi = get_strinfo (chainsi->next))
{
nextsi = unshare_strinfo (nextsi);
si->next = nextsi->idx;
nextsi->prev = idx;
}
chainsi = unshare_strinfo (chainsi);
if (chainsi->first == 0)
chainsi->first = chainsi->idx;
chainsi->next = idx;
Now, the bug is that the caller of this a couple of frames above,
handle_store, holds on a pointer to this g strinfo (but doesn't know
about the unsharing, so the pointer is to the old strinfo with refcount
of 2), and later needs to update it, so it
si = unshare_strinfo (si);
and modifies some fields in it.
This creates a new strinfo (with refcount of 1 which is stored into
the vector of the current bb) based on the old strinfo for g and
decrements refcount of the old one to 1. So, now we are in inconsistent
state, because the old strinfo for g is referenced in bb 2 and bb 3
vectors, but has just refcount of 1, and then have one strinfo (the one
created by unshare_strinfo (chainsi) in get_stridx_plus_constant) which
has refcount of 1 but isn't referenced from anywhere anymore.
Later on when we free one of the bb 2 or bb 3 vectors (forgot which)
that decrements refcount from 1 to 0 and poisons the strinfo/returns it to
the pool, but then maybe_invalidate when looking at the other bb's pointer
to it ICEs.
The following patch fixes it by calling get_strinfo again, it is guaranteed
to return non-NULL, but could be an unshared copy instead of the originally
fetched shared one.
I believe we only need to do this refetching for the case where get_strinfo
is called on the lhs before get_stridx is called on other operands, because
we should be always modifying (apart from the chaining changes) the strinfo
for the destination of the statements, not other strinfos just consumed in
there.
2024-01-30 Jakub Jelinek
PR tree-optimization/113603
* tree-ssa-strlen.cc (strlen_pass::handle_store): After
count_nonzero_bytes call refetch si using get_strinfo in case it
has been unshared in the meantime.
* gcc.c-torture/compile/pr113603.c: New test.
(cherry picked from commit d7250c1e02478586a0cd6d5cb67bf4d17249a7e7)
[Bug c++/113674] [11/12 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fda7a897d037ff1c59630f0a741eb20e68f45848 commit r12-10511-gfda7a897d037ff1c59630f0a741eb20e68f45848 Author: Jakub Jelinek Date: Mon Feb 12 20:45:01 2024 +0100 attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674] The C and C++ FEs when parsing attributes already canonicalize them (i.e. if they start with __ and end with __ substrings, we remove those). lookup_attribute already verifies in gcc_assert that the first character of name is not an underscore, and even lookup_scoped_attribute_spec doesn't attempt to canonicalize the namespace it is passed. But for some historic reason it was canonicalizing the name argument, which misbehaves when an attribute starts with and ends with . I believe it is just wrong to try to canonicalize lookup_scope_attribute_spec name attribute, it should have been canonicalized already, in other spots where it is called it is already canonicalized before. 2024-02-12 Jakub Jelinek PR c++/113674 * attribs.cc (extract_attribute_substring): Remove. (lookup_scoped_attribute_spec): Don't call it. * c-c++-common/Wattributes-3.c: New test. (cherry picked from commit b42e978f29b33071addff6d7bb8bcdb11d176606)
[Bug middle-end/111422] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111422
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
commit r12-10506-g170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
Author: Jakub Jelinek
Date: Tue Jan 16 11:49:34 2024 +0100
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) [(void *)
+ 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) [(void
*) + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
(cherry picked from commit 1251d3957de04dc9b023a23c09400217e13deadb)
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #31 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c2cd5eefccf54074ea9f8dc677a9a05b8a880ae4 commit r12-10512-gc2cd5eefccf54074ea9f8dc677a9a05b8a880ae4 Author: Jakub Jelinek Date: Thu Feb 22 19:32:02 2024 +0100 c: Handle scoped attributes in __has*attribute and scoped attribute parsing changes in -std=c11 etc. modes [PR114007] We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23) there are is just a pair of CPP_COLON tokens. The c-lex.cc hunk adds support for that, but always returns 0 in that case unlike the GCC 14+ version. 2024-02-22 Jakub Jelinek PR c/114007 gcc/c-family/ * c-lex.cc (c_common_has_attribute): Parse 2 CPP_COLONs with the first one with COLON_SCOPE flag the same as CPP_SCOPE but ensure 0 is returned then. gcc/testsuite/ * gcc.dg/c23-attr-syntax-8.c: New test. libcpp/ * include/cpplib.h (COLON_SCOPE): Define to PURE_ZERO. * lex.cc (_cpp_lex_direct): When lexing CPP_COLON with another colon after it, if !CPP_OPTION (pfile, scope) set COLON_SCOPE flag on the first CPP_COLON token. (cherry picked from commit 37127ed975e09813eaa2d1cf1062055fce45dd16)
[Bug middle-end/90348] [11/12 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #34 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
commit r12-10506-g170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
Author: Jakub Jelinek
Date: Tue Jan 16 11:49:34 2024 +0100
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) [(void *)
+ 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) [(void
*) + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
(cherry picked from commit 1251d3957de04dc9b023a23c09400217e13deadb)
[Bug middle-end/110115] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
--- Comment #10 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
commit r12-10506-g170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
Author: Jakub Jelinek
Date: Tue Jan 16 11:49:34 2024 +0100
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) [(void *)
+ 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) [(void
*) + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
(cherry picked from commit 1251d3957de04dc9b023a23c09400217e13deadb)
[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #23 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
commit r12-10506-g170c2bba7cb85b3ac9380a7d5a1c6d82b3c6aa63
Author: Jakub Jelinek
Date: Tue Jan 16 11:49:34 2024 +0100
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) [(void *)
+ 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) [(void
*) + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
(cherry picked from commit 1251d3957de04dc9b023a23c09400217e13deadb)
[Bug libgomp/113192] [11/12 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3f0d1e53892348d4df79d822a9910583378674d7 commit r12-10505-g3f0d1e53892348d4df79d822a9910583378674d7 Author: Jakub Jelinek Date: Wed Jan 10 13:29:47 2024 +0100 libgomp: Fix up FLOCK fallback handling [PR113192] My earlier change broke Solaris testing, because @FLOCK@ isn't substituted just into libgomp/Makefile where it worked, but also the testsuite/libgomp-site-extra.exp file where Make variables aren't present and can't be substituted. The following patch instead computes the absolute srcdir path and uses it for FLOCK. 2024-01-10 Jakub Jelinek PR libgomp/113192 * configure.ac (FLOCK): Use $libgomp_abs_srcdir/testsuite/flock instead of \$(abs_top_srcdir)/testsuite/flock. * configure: Regenerated. (cherry picked from commit 2fb3ee3ee82874e160309344bc3e52afeed8f26a)
[Bug c/113262] [11/12 Regression] ICE when using [[gnu::copy("")]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ca8ad807cf33ca9d74a2aecdd78b59af9834b882 commit r12-10504-gca8ad807cf33ca9d74a2aecdd78b59af9834b882 Author: Jakub Jelinek Date: Tue Jan 9 15:37:04 2024 +0100 c-family: copy attribute diagnostic fixes [PR113262] The copy attributes is allowed on decls as well as types and even has checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works if it applies to a decl. 2024-01-09 Jakub Jelinek PR c/113262 * c-attribs.cc (handle_copy_attribute): Don't use DECL_SOURCE_LOCATION (decl) if decl is not DECL_P, use input_location instead. Formatting fixes. * gcc.dg/pr113262.c: New test. (cherry picked from commit c9fc7f398e8b330ff12ec8a29bfa058b6daf6624)
[Bug libstdc++/115308] std::experimental::simd is not convertible to NEON intrinsic type with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115308 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:ef2169090d0868e4718c2ebf25365aaa52c22139 commit r13-8841-gef2169090d0868e4718c2ebf25365aaa52c22139 Author: Matthias Kretz Date: Mon Jun 3 12:02:07 2024 +0200 libstdc++: Fix simd conversion for -fno-signed-char for Clang The special case for Clang in the trait producing a signed integer type lead to the trait returning 'char' where it should have been 'signed char'. This workaround was introduced because on Clang the return type of vector compares was not convertible to '_SimdWrapper< __int_for_sizeof_t<...' unless '__int_for_sizeof_t' was an alias for 'char'. In order to not rewrite the complete mask type code (there is code scattered around the implementation assuming signed integers), this needs to be 'signed char'; so the special case for Clang needs to be removed. The conversion issue is now solved in _SimdWrapper, which now additionally allows conversion from vector types with compatible integral type. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/115308 * include/experimental/bits/simd.h (__int_for_sizeof): Remove special cases for __clang__. (_SimdWrapper): Change constructor overload set to allow conversion from vector types with integral conversions via bit reinterpretation. (cherry picked from commit 8e36cf4c5c9140915d001db132a900b48037)
[Bug libstdc++/115247] experimental/simd/pr109261_constexpr_simd.cc FAILs on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115247 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:0efc27068e59cac6bd80ff962e92618a037bbfe8 commit r13-8840-g0efc27068e59cac6bd80ff962e92618a037bbfe8 Author: Matthias Kretz Date: Wed May 15 11:02:22 2024 +0200 libstdc++: Avoid MMX return types from __builtin_shufflevector This resolves a regression on i686 that was introduced with r15-429-gfb1649f8b4ad50. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/115247 * include/experimental/bits/simd.h (__as_vector): Don't use vector_size(8) on __i386__. (__vec_shuffle): Never return MMX vectors, widen to 16 bytes instead. (concat): Fix padding calculation to pick up widening logic from __as_vector. (cherry picked from commit 241a6cc88d866fb36bd35ddb3edb659453d6322e)
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:26113c278069e7e58f5e4149ef86a30c043b262f commit r13-8839-g26113c278069e7e58f5e4149ef86a30c043b262f Author: Matthias Kretz Date: Mon May 6 12:13:55 2024 +0200 libstdc++: Use __builtin_shufflevector for simd split and concat Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114958 * include/experimental/bits/simd.h (__as_vector): Return scalar simd as one-element vector. Return vector from single-vector fixed_size simd. (__vec_shuffle): New. (__extract_part): Adjust return type signature. (split): Use __extract_part for any split into non-fixed_size simds. (concat): If the return type stores a single vector, use __vec_shuffle (which calls __builtin_shufflevector) to produce the return value. * include/experimental/bits/simd_builtin.h (__shift_elements_right): Removed. (__extract_part): Return single elements directly. Use __vec_shuffle (which calls __builtin_shufflevector) to for all non-trivial cases. * include/experimental/bits/simd_fixed_size.h (__extract_part): Return single elements directly. * testsuite/experimental/simd/pr114958.cc: New test. (cherry picked from commit fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9)
[Bug modula2/114529] profiledbootstrap fails to build and m2 causes odr violations during build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114529 --- Comment #7 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a0004feb87efbe41fb1e9cd77f1c9af06e98ccb5 commit r15-1176-ga0004feb87efbe41fb1e9cd77f1c9af06e98ccb5 Author: Gaius Mulley Date: Tue Jun 11 10:01:12 2024 +0100 PR modula2/114529 Avoid ODR violations in bootstrap translated sources This patch changes the bootstrap tool mc to avoid redefining any data types and therefore preventing ODR violations. All exported opaque type usages are implemented as void *. Local opaque type usages (static functions containing opaque type parameters) use the full declaration. mc casts usages between void * and full opaque type as necessary. The --extended-opaque option in mc has been disabled, as this generated ODR violations. The extended-opaque option inlined all declarations in the translated implementation module. As this is no longer used there is now a .h file for each .def file and a .cc file for every .mod file. This results in more Makefile rules for the ppg tool in Make-maintainer.in. gcc/m2/ChangeLog: PR modula2/114529 * Make-lang.in (MC_EXTENDED_OPAQUE): Assign to nothing. * Make-maintainer.in (mc-basetest): New rule. (mc-devel-basetest): New rule. (mc-clean): Remove mc. (m2/mc-boot-gen/$(SRC_PREFIX)decl.cc): Replace --extended-opaque with $(EXTENDED_OPAQUE). (PG-SRC): Move define before generic rules. (PGE-DEF): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)%.h): New rule. (m2/gm2-ppg-boot/$(SRC_PREFIX)libc.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)mcrts.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)UnixArgs.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)Selective.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)termios.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)SysExceptions.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)ldtoa.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)wrapc.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)SYSTEM.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)errno.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)M2RTS.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)SymbolKey.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)SymbolKey.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)NameKey.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)NameKey.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)Lists.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)Lists.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)Output.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)bnflex.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)bnflex.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)RTco.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)RTentity.h): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)RTco.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)RTentity.o): Ditto. (m2/gm2-ppg-boot/$(SRC_PREFIX)%.o): Ditto. (m2/ppg$(exeext)): Ditto. (m2/gm2-ppg-boot/main.o): Ditto. (m2/gm2-auto): Ditto. (c-family/m2pp.o): Ditto. (BUILD-BOOT-PG-H): Correct macro definition. (m2/gm2-pg-boot/$(SRC_PREFIX)%.h): New rule. (m2/gm2-pg-boot/$(SRC_PREFIX)NameKey.h): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)NameKey.o): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)Lists.h): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)Lists.o): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)Output.h): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)Output.o): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)bnflex.h): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)bnflex.o): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)RTco.h): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)RTentity.h): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)RTco.o): Ditto. (m2/gm2-pg-boot/$(SRC_PREFIX)RTentity.o): Ditto. (BUILD-BOOT-PGE-H): Correct macro definition. (m2/gm2-pge-boot/$(SRC_PREFIX)SymbolKey.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)SymbolKey.o): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)NameKey.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)NameKey.o): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)Lists.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)Lists.o): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)Output.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)Output.o): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)bnflex.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)bnflex.o): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)RTco.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)RTentity.h): Ditto. (m2/gm2-pge-boot/$(SRC_PREFIX)RTco.o): Ditto.
[Bug rtl-optimization/115281] [14 Regression] aarch64 ICE in go_through_subreg after r14-5129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115281 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:7d64bc0990381221c480ba15cb9cc950e51e2cef commit r14-10303-g7d64bc0990381221c480ba15cb9cc950e51e2cef Author: Richard Sandiford Date: Tue Jun 11 09:58:48 2024 +0100 ira: Fix go_through_subreg offset calculation [PR115281] go_through_subreg used: else if (!can_div_trunc_p (SUBREG_BYTE (x), REGMODE_NATURAL_SIZE (GET_MODE (x)), offset)) to calculate the register offset for a pseudo subreg x. In the blessed days before poly-int, this was: *offset = (SUBREG_BYTE (x) / REGMODE_NATURAL_SIZE (GET_MODE (x))); But I think this is testing the wrong natural size. If we exclude paradoxical subregs (which will get an offset of zero regardless), it's the inner register that is being split, so it should be the inner register's natural size that we use. This matters in the testcase because we have an SFmode lowpart subreg into the last of three variable-sized vectors. The SUBREG_BYTE is therefore equal to the size of two variable-sized vectors. Dividing by the vector size gives a register offset of 2, as expected, but dividing by the size of a scalar FPR would give a variable offset. I think something similar could happen for fixed-size targets if REGMODE_NATURAL_SIZE is different for vectors and integers (say), although that case would trade an ICE for an incorrect offset. gcc/ PR rtl-optimization/115281 * ira-conflicts.cc (go_through_subreg): Use the natural size of the inner mode rather than the outer mode. gcc/testsuite/ PR rtl-optimization/115281 * gfortran.dg/pr115281.f90: New test. (cherry picked from commit 46d931b3dd31cbba7c3355ada63f155aa24a4e2b)
[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115397 --- Comment #7 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:a797398cfbc75899fdb7d97436c0c89c02b133c0 commit r15-1175-ga797398cfbc75899fdb7d97436c0c89c02b133c0 Author: Roger Sayle Date: Tue Jun 11 09:31:34 2024 +0100 i386: PR target/115397: AVX512 ternlog vs. -m32 -fPIC constant pool. This patch fixes PR target/115397, a recent regression caused by my ternlog patch that results in an ICE (building numpy) with -m32 -fPIC. The problem is that ix86_broadcast_from_constant, which calls get_pool_constant, doesn't handle the UNSPEC_GOTOFF that's created by calling validize_mem when using -fPIC on i686. The logic here is a bit convoluted (and my future patches will clean some of this up), but the simplest fix is to call ix86_broadcast_from_constant between the calls to force_const_mem and the call to validize_mem. Perhaps a better solution might be to call targetm.delegitimize_address from the middle-end's get_pool_constant, but ultimately the best approach would be to not place things in the constant pool if we don't need to. My plans to move (broadcast) constant handling from expand to split1 should simplify this. 2024-06-11 Roger Sayle gcc/ChangeLog PR target/115397 * config/i386/i386-expand.cc (ix86_expand_ternlog): Move call to ix86_broadcast_from_constant before call to validize_mem, but after call to force_const_mem. gcc/testsuite/ChangeLog PR target/115397 * gcc.target/i386/pr115397.c: New test case.
[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:d73137ab352d654f50b703925bd92e021dce1cab commit r12-10503-gd73137ab352d654f50b703925bd92e021dce1cab Author: Richard Biener Date: Mon Aug 21 09:01:00 2023 +0200 tree-optimization/111070 - fix ICE with recent ifcombine fix We now got test coverage for non-SSA name bits so the following amends the SSA_NAME_OCCURS_IN_ABNORMAL_PHI checks. PR tree-optimization/111070 * tree-ssa-ifcombine.cc (ifcombine_ifandif): Check we have an SSA name before checking SSA_NAME_OCCURS_IN_ABNORMAL_PHI. * gcc.dg/pr111070.c: New testcase. (cherry picked from commit 966b0a96523fb7adbf498ac71df5e033c70dc546)
[Bug c/114493] [11/12/13 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7813d94393f60ac641265cb3fc3a446f9f3aea7e commit r13-8838-g7813d94393f60ac641265cb3fc3a446f9f3aea7e Author: Jakub Jelinek Date: Thu Jun 6 22:12:11 2024 +0200 c: Fix up pointer types to may_alias structures [PR114493] The following testcase ICEs in ipa-free-lang, because the fld_incomplete_type_of gcc_assert (TYPE_CANONICAL (t2) != t2 && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); assertion doesn't hold. This is because t is a struct S * type which was created while struct S was still incomplete and without the may_alias attribute (and TYPE_CANONICAL of a pointer type is a type created with can_alias_all = false argument), while later on on the struct definition may_alias attribute was used. fld_incomplete_type_of then creates an incomplete distinct copy of the structure (but with the original attributes) but pointers created for it are because of the "may_alias" attribute TYPE_REF_CAN_ALIAS_ALL, including their TYPE_CANONICAL, because while that is created with !can_alias_all argument, we later set it because of the "may_alias" attribute on the to_type. This doesn't ICE with C++ since PR70512 fix because the C++ FE sets TYPE_REF_CAN_ALIAS_ALL on all pointer types to the class type (and its variants) when the may_alias is added. The following patch does that in the C FE as well. 2024-06-06 Jakub Jelinek PR c/114493 * c-decl.cc (c_fixup_may_alias): New function. (finish_struct): Call it if "may_alias" attribute is specified. * gcc.dg/pr114493-1.c: New test. * gcc.dg/pr114493-2.c: New test. (cherry picked from commit d5a3c6d43acb8b2211d9fb59d59482d74c010f01)
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f9db8b0571348adfcc98204ea7be787058af85cd
commit r13-8836-gf9db8b0571348adfcc98204ea7be787058af85cd
Author: Jakub Jelinek
Date: Tue Jun 4 12:28:01 2024 +0200
builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow [PR108789]
The following testcase is miscompiled, because we use save_expr
on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first
two operands are not INTEGER_CSTs (in that case we just fold it right away)
but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually
create a SAVE_EXPR at all and so we lower it to
*arg2 = REALPART_EXPR (.ADD_OVERFLOW (arg0, arg1)), \
IMAGPART_EXPR (.ADD_OVERFLOW (arg0, arg1))
which evaluates the ifn twice and just hope it will be CSEd back.
As *arg2 aliases *arg0, that is not the case.
The builtins are really never const/pure as they store into what
the third arguments points to, so after handling the
INTEGER_CST+INTEGER_CST
case, I think we should just always use SAVE_EXPR. Just building SAVE_EXPR
by hand and setting TREE_SIDE_EFFECTS on it doesn't work, because
c_fully_fold optimizes it away again, so the following patch marks the
ifn calls as TREE_SIDE_EFFECTS (but doesn't do it for the
__builtin_{add,sub,mul}_overflow_p case which were designed for use
especially in constant expressions and don't really evaluate the
realpart side, so we don't really need a SAVE_EXPR in that case).
2024-06-04 Jakub Jelinek
PR middle-end/108789
* builtins.cc (fold_builtin_arith_overflow): For ovf_only,
don't call save_expr and don't build REALPART_EXPR, otherwise
set TREE_SIDE_EFFECTS on call before calling save_expr.
* gcc.c-torture/execute/pr108789.c: New test.
(cherry picked from commit b8e28381cb5c0cddfe5201faf799d8b27f5d7d6c)
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:865d60ab4edbdb10d13000af81f9168fd3816a86 commit r13-8837-g865d60ab4edbdb10d13000af81f9168fd3816a86 Author: Jakub Jelinek Date: Tue Jun 4 15:49:41 2024 +0200 fold-const: Fix up CLZ handling in tree_call_nonnegative_warnv_p [PR115337] The function currently incorrectly assumes all the __builtin_clz* and .CLZ calls have non-negative result. That is the case of the former which is UB on zero and has [0, prec-1] return value otherwise, and is the case of the single argument .CLZ as well (again, UB on zero), but for two argument .CLZ is the case only if the second argument is also nonnegative (or if we know the argument can't be zero, but let's do that just in the ranger IMHO). The following patch does that. 2024-06-04 Jakub Jelinek PR tree-optimization/115337 * fold-const.cc (tree_call_nonnegative_warnv_p) : If fn is CFN_CLZ, use CLZ_DEFINED_VALUE_AT. (cherry picked from commit b82a816000791e7a286c7836b3a473ec0e2a577b)
[Bug target/115324] [12/13 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:50b5019fde97c20a377e004c9d73df62e4898773
commit r13-8834-g50b5019fde97c20a377e004c9d73df62e4898773
Author: Jakub Jelinek
Date: Mon Jun 3 23:11:06 2024 +0200
rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or _instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them
back
in full. While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.
So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.
Size-wise in .data sections it is (in bytes):
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.
Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.
When I applied
void
rs6000_init_generated_builtins ()
{
+ bifdata *rs6000_builtin_info_p;
+ tree *rs6000_builtin_info_fntype_p;
+ ovlddata *rs6000_instance_info_p;
+ tree *rs6000_instance_info_fntype_p;
+ ovldrecord *rs6000_overload_info_p;
+ __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+ __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+ __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+ __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+ __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+ #define rs6000_builtin_info rs6000_builtin_info_p
+ #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+ #define rs6000_instance_info rs6000_instance_info_p
+ #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+ #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
2024-06-03 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members. Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *. Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_info_fntype and rs6000_instance_info_fntype
[Bug rtl-optimization/114902] [14 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #17 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8deaab6f79768700e1bf05fe6af83b185f678b7f commit r13-8833-g8deaab6f79768700e1bf05fe6af83b185f678b7f Author: Jakub Jelinek Date: Wed May 15 18:37:17 2024 +0200 combine: Fix up simplify_compare_const [PR115092] The following testcases are miscompiled (with tons of GIMPLE optimization disabled) because combine sees GE comparison of 1-bit sign_extract (i.e. something with [-1, 0] value range) with (const_int -1) (which is always true) and optimizes it into NE comparison of 1-bit zero_extract ([0, 1] value range) against (const_int 0). The reason is that simplify_compare_const first (correctly) simplifies the comparison to GE (ashift:SI something (const_int 31)) (const_int -2147483648) and then an optimization for when the second operand is power of 2 triggers. That optimization is fine for power of 2s which aren't the signed minimum of the mode, or if it is NE, EQ, GEU or LTU against the signed minimum of the mode, but for GE or LT optimizing it into NE (or EQ) against const0_rtx is wrong, those cases are always true or always false (but the function doesn't have a standardized way to tell callers the comparison is now unconditional). The following patch just disables the optimization in that case. 2024-05-15 Jakub Jelinek PR rtl-optimization/114902 PR rtl-optimization/115092 * combine.cc (simplify_compare_const): Don't optimize GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or EQ op0 const0_rtx. * gcc.dg/pr114902.c: New test. * gcc.dg/pr115092.c: New test. (cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)
[Bug rtl-optimization/115092] [14/15 Regression] wrong code at -O1 with "-fgcse -ftree-pre -fno-tree-dominator-opts -fno-tree-fre -fno-guess-branch-probability" on x86_64-linux-gnu since r14-4810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8deaab6f79768700e1bf05fe6af83b185f678b7f commit r13-8833-g8deaab6f79768700e1bf05fe6af83b185f678b7f Author: Jakub Jelinek Date: Wed May 15 18:37:17 2024 +0200 combine: Fix up simplify_compare_const [PR115092] The following testcases are miscompiled (with tons of GIMPLE optimization disabled) because combine sees GE comparison of 1-bit sign_extract (i.e. something with [-1, 0] value range) with (const_int -1) (which is always true) and optimizes it into NE comparison of 1-bit zero_extract ([0, 1] value range) against (const_int 0). The reason is that simplify_compare_const first (correctly) simplifies the comparison to GE (ashift:SI something (const_int 31)) (const_int -2147483648) and then an optimization for when the second operand is power of 2 triggers. That optimization is fine for power of 2s which aren't the signed minimum of the mode, or if it is NE, EQ, GEU or LTU against the signed minimum of the mode, but for GE or LT optimizing it into NE (or EQ) against const0_rtx is wrong, those cases are always true or always false (but the function doesn't have a standardized way to tell callers the comparison is now unconditional). The following patch just disables the optimization in that case. 2024-05-15 Jakub Jelinek PR rtl-optimization/114902 PR rtl-optimization/115092 * combine.cc (simplify_compare_const): Don't optimize GE op0 SIGNED_MIN or LT op0 SIGNED_MIN into NE op0 const0_rtx or EQ op0 const0_rtx. * gcc.dg/pr114902.c: New test. * gcc.dg/pr115092.c: New test. (cherry picked from commit 0b93a0ae153ef70a82ff63e67926a01fdab9956b)
[Bug tree-optimization/115387] [15 regression] ICE in iovsprintf.c since r15-1081-ge14afbe2d1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115387 --- Comment #10 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:d03ff3fd3e2da1352a404e3c53fe61314569345c commit r15-1167-gd03ff3fd3e2da1352a404e3c53fe61314569345c Author: Pan Li Date: Mon Jun 10 14:13:38 2024 -0600 [PATCH v1] Widening-Mul: Fix one ICE of gcall insertion for PHI match When enabled the PHI handing for COND_EXPR, we need to insert the gcall to replace the PHI node. Unfortunately, I made a mistake that insert the gcall to before the last stmt of the bb. See below gimple, the PHI is located at no.1 but we insert the gcall (aka no.9) to the end of the bb. Then the use of _9 in no.2 will have no def and will trigger ICE when verify_ssa. 1. # _9 = PHI <_3(4), 18446744073709551615(3)> // The PHI node to be deleted. 2. prephitmp_36 = (char *) _9; 3. buf.write_base = string_13(D); 4. buf.write_ptr = string_13(D); 5. buf.write_end = prephitmp_36; 6. buf.written = 0; 7. buf.mode = 3; 8. _7 = buf.write_end; 9. _9 = .SAT_ADD (string.0_2, maxlen_15(D)); // Insert gcall to last bb by mistake This patch would like to insert the gcall to before the start of the bb stmt. To ensure the possible use of PHI_result will have a def exists. After this patch the above gimple will be: 0. _9 = .SAT_ADD (string.0_2, maxlen_15(D)); // Insert gcall to start bb by mistake 1. # _9 = PHI <_3(4), 18446744073709551615(3)> // The PHI node to be deleted. 2. prephitmp_36 = (char *) _9; 3. buf.write_base = string_13(D); 4. buf.write_ptr = string_13(D); 5. buf.write_end = prephitmp_36; 6. buf.written = 0; 7. buf.mode = 3; 8. _7 = buf.write_end; The below test suites are passed for this patch: * The rv64gcv fully regression test with newlib. * The rv64gcv build with glibc. * The x86 regression test with newlib. * The x86 bootstrap test with newlib. PR target/115387 gcc/ChangeLog: * tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children): Take the gsi of start_bb instead of last_bb. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr115387-1.c: New test. * gcc.target/riscv/pr115387-2.c: New test.
[Bug middle-end/115388] [15 Regression] wrong code at -O3 on x86_64-linux-gnu since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388 --- Comment #9 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:c3d1153bc0a2b820e3c373ecf19a5a127703f854 commit r15-1165-gc3d1153bc0a2b820e3c373ecf19a5a127703f854 Author: Andrew Pinski Date: Mon Jun 10 08:23:00 2024 -0700 Fix pr115388.c: plain char could be unsigned by default [PR115415] This is a simple fix to the testcase as plain `char` could be unsigned by default on some targets (e.g. aarch64 and powerpc). Committed as obvious after quick test of the testcase on both aarch64 and x86_64. gcc/testsuite/ChangeLog: PR testsuite/115415 PR tree-optimization/115388 * gcc.dg/torture/pr115388.c: Use `signed char` directly instead of plain `char`. Signed-off-by: Andrew Pinski
[Bug testsuite/115415] New test case gcc.dg/torture/pr115388.c in r15-1163-g818e760528d436 hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115415 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:c3d1153bc0a2b820e3c373ecf19a5a127703f854 commit r15-1165-gc3d1153bc0a2b820e3c373ecf19a5a127703f854 Author: Andrew Pinski Date: Mon Jun 10 08:23:00 2024 -0700 Fix pr115388.c: plain char could be unsigned by default [PR115415] This is a simple fix to the testcase as plain `char` could be unsigned by default on some targets (e.g. aarch64 and powerpc). Committed as obvious after quick test of the testcase on both aarch64 and x86_64. gcc/testsuite/ChangeLog: PR testsuite/115415 PR tree-optimization/115388 * gcc.dg/torture/pr115388.c: Use `signed char` directly instead of plain `char`. Signed-off-by: Andrew Pinski
[Bug c++/115378] [14/15 Regression] ICE with lambda function as a default template argument with variadic templates in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115378 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ff8105b4910f7dbee326cb36b01c16ac9bf10c4b commit r14-10301-gff8105b4910f7dbee326cb36b01c16ac9bf10c4b Author: Patrick Palka Date: Fri Jun 7 12:12:30 2024 -0400 c++: lambda in pack expansion [PR115378] Here find_parameter_packs_r is incorrectly treating the 'auto' return type of a lambda as a parameter pack due to Concepts-TS specific logic added in r6-4517, leading to confusion later when expanding the pattern. Since we intend on removing Concepts TS support soon anyway, this patch fixes this by restricting the problematic logic with flag_concepts_ts. Doing so revealed that add_capture was relying on this logic to set TEMPLATE_TYPE_PARAMETER_PACK for the 'auto' type of an pack expansion init-capture, which we now need to do explicitly. PR c++/115378 gcc/cp/ChangeLog: * lambda.cc (lambda_capture_field_type): Set TEMPLATE_TYPE_PARAMETER_PACK on the auto type of an init-capture pack expansion. * pt.cc (find_parameter_packs_r) : Restrict TEMPLATE_TYPE_PARAMETER_PACK promotion with flag_concepts_ts. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto-103497.C: Adjust expected diagnostic. * g++.dg/template/pr95672.C: Likewise. * g++.dg/cpp2a/lambda-targ5.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 5c761395402a730535983a5e49ef1775561ebc61)
[Bug middle-end/115388] [15 Regression] wrong code at -O3 on x86_64-linux-gnu since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:818e760528d436ea8f6c28ef620e2bb82d456ea1 commit r15-1163-g818e760528d436ea8f6c28ef620e2bb82d456ea1 Author: Richard Biener Date: Mon Jun 10 11:29:43 2024 +0200 tree-optimization/115388 - wrong DSE in irreductible regions The following fixes a latent bug in DSE with regarding to variant array accesses where the code avoiding bogus DSE in loops fails to handle irreducible regions. For those we need to make sure backedges are marked and discover a header for the irreducible region to check invariantness. PR tree-optimization/115388 * tree-ssa-dse.cc (dse_classify_store): Handle irreducible regions. (pass_dse::execute): Make sure to mark backedges. * gcc.dg/torture/pr115388.c: New testcase.
[Bug ada/114708] [12/13/14/15 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:12a3ba2be46e86ff1bffa5c876b6b17fe4929be3 commit r12-10501-g12a3ba2be46e86ff1bffa5c876b6b17fe4929be3 Author: Eric Botcazou Date: Mon Jun 10 12:12:21 2024 +0200 Fix crash on access-to-incomplete type This just adds the missing guard. gcc/ada/ PR ada/114708 * exp_util.adb (Finalize_Address): Add guard for incomplete types. gcc/testsuite/ * gnat.dg/incomplete8.adb: New test.
[Bug ada/114708] [12/13/14/15 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:ef494b147f6d210cfa7e1647fb0979aa3666022a commit r13-8831-gef494b147f6d210cfa7e1647fb0979aa3666022a Author: Eric Botcazou Date: Mon Jun 10 12:12:21 2024 +0200 Fix crash on access-to-incomplete type This just adds the missing guard. gcc/ada/ PR ada/114708 * exp_util.adb (Finalize_Address): Add guard for incomplete types. gcc/testsuite/ * gnat.dg/incomplete8.adb: New test.
[Bug ada/114708] [12/13/14/15 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:b5ad4431f97eed60e46fc447fcd1eb4077b3cd80 commit r14-10300-gb5ad4431f97eed60e46fc447fcd1eb4077b3cd80 Author: Eric Botcazou Date: Mon Jun 10 12:12:21 2024 +0200 Fix crash on access-to-incomplete type This just adds the missing guard. gcc/ada/ PR ada/114708 * exp_util.adb (Finalize_Address): Add guard for incomplete types. gcc/testsuite/ * gnat.dg/incomplete8.adb: New test.
[Bug ada/114708] [12/13/14/15 regression] internal error on access to an incomplete formal in generic package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114708 --- Comment #4 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:e29af8de31ba4b73dcee82917c8cec60d53dfa82 commit r15-1162-ge29af8de31ba4b73dcee82917c8cec60d53dfa82 Author: Eric Botcazou Date: Mon Jun 10 12:12:21 2024 +0200 Add testcase for PR ada/114708 gcc/testsuite/ PR ada/114708 * gnat.dg/incomplete8.adb: New test.
[Bug ada/114398] [13/14/15 regression] Storage_Error with 'Access of primitive function returning limited type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114398 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:02025fb144fcf4fbb964cd59e480149ac448ea6c commit r13-8830-g02025fb144fcf4fbb964cd59e480149ac448ea6c Author: Eric Botcazou Date: Mon Jun 10 11:44:24 2024 +0200 Add testcase for PR ada/114398 gcc/testsuite/ PR ada/114398 * gnat.dg/access11.adb: New test.
[Bug ada/114398] [13/14/15 regression] Storage_Error with 'Access of primitive function returning limited type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114398 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:72a59a1b8d4e69b1faac93a31c1162ef0dbe53e5 commit r14-10299-g72a59a1b8d4e69b1faac93a31c1162ef0dbe53e5 Author: Eric Botcazou Date: Mon Jun 10 11:44:24 2024 +0200 Add testcase for PR ada/114398 gcc/testsuite/ PR ada/114398 * gnat.dg/access11.adb: New test.
[Bug ada/114398] [13/14/15 regression] Storage_Error with 'Access of primitive function returning limited type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114398 --- Comment #5 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:e1c1f128d1c1e1f548cbae4eb014e455cfdfccc8 commit r15-1161-ge1c1f128d1c1e1f548cbae4eb014e455cfdfccc8 Author: Eric Botcazou Date: Mon Jun 10 11:44:24 2024 +0200 Add testcase for PR ada/114398 gcc/testsuite/ PR ada/114398 * gnat.dg/access11.adb: New test.
[Bug tree-optimization/115395] [15 regression] libarchive miscompiled with -O2 -march=znver2 -fno-vect-cost-model since r15-1006-gd93353e6423eca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115395 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4ed9c5df7efeb98e190573cca42a4fd40666c45f commit r15-1160-g4ed9c5df7efeb98e190573cca42a4fd40666c45f Author: Richard Biener Date: Mon Jun 10 10:12:52 2024 +0200 tree-optimization/115395 - wrong-code with SLP reduction in epilog When we continue a non-SLP reduction from the main loop in the epilog with a SLP reduction we currently fail to handle an adjustment by the initial value because that's not a thing with SLP. As long as we have the possibility to mix SLP and non-SLP we have to handle it though. PR tree-optimization/115395 * tree-vect-loop.cc (vect_create_epilog_for_reduction): Handle STMT_VINFO_REDUC_EPILOGUE_ADJUSTMENT also for SLP reductions of group_size one. * gcc.dg/vect/pr115395.c: New testcase.
[Bug tree-optimization/115383] [15 Regression] ICE with TCVC_2 build since r15-1053-g28edeb1409a7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c1429e3a8da0cdfe9391e1e9b2c7228d896a3a87 commit r15-1126-gc1429e3a8da0cdfe9391e1e9b2c7228d896a3a87 Author: Richard Biener Date: Fri Jun 7 12:15:31 2024 +0200 tree-optimization/115383 - EXTRACT_LAST_REDUCTION with multiple stmt copies The EXTRACT_LAST_REDUCTION code isn't ready to deal with multiple stmt copies but SLP no longer checks for this. The following adjusts code generation to handle the situation. PR tree-optimization/115383 * tree-vect-stmts.cc (vectorizable_condition): Handle generating a chain of .FOLD_EXTRACT_LAST. * gcc.dg/vect/pr115383.c: New testcase.
[Bug libstdc++/115308] std::experimental::simd is not convertible to NEON intrinsic type with Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115308 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:489b58b79782fa361c0d7e852e0e684d743c8399 commit r14-10296-g489b58b79782fa361c0d7e852e0e684d743c8399 Author: Matthias Kretz Date: Mon Jun 3 12:02:07 2024 +0200 libstdc++: Fix simd conversion for -fno-signed-char for Clang The special case for Clang in the trait producing a signed integer type lead to the trait returning 'char' where it should have been 'signed char'. This workaround was introduced because on Clang the return type of vector compares was not convertible to '_SimdWrapper< __int_for_sizeof_t<...' unless '__int_for_sizeof_t' was an alias for 'char'. In order to not rewrite the complete mask type code (there is code scattered around the implementation assuming signed integers), this needs to be 'signed char'; so the special case for Clang needs to be removed. The conversion issue is now solved in _SimdWrapper, which now additionally allows conversion from vector types with compatible integral type. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/115308 * include/experimental/bits/simd.h (__int_for_sizeof): Remove special cases for __clang__. (_SimdWrapper): Change constructor overload set to allow conversion from vector types with integral conversions via bit reinterpretation. (cherry picked from commit 8e36cf4c5c9140915d001db132a900b48037)
[Bug libstdc++/115247] experimental/simd/pr109261_constexpr_simd.cc FAILs on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115247 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:237f060033bc119461c43aae482254463f01b29e commit r14-10295-g237f060033bc119461c43aae482254463f01b29e Author: Matthias Kretz Date: Wed May 15 11:02:22 2024 +0200 libstdc++: Avoid MMX return types from __builtin_shufflevector This resolves a regression on i686 that was introduced with r15-429-gfb1649f8b4ad50. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/115247 * include/experimental/bits/simd.h (__as_vector): Don't use vector_size(8) on __i386__. (__vec_shuffle): Never return MMX vectors, widen to 16 bytes instead. (concat): Fix padding calculation to pick up widening logic from __as_vector. (cherry picked from commit 241a6cc88d866fb36bd35ddb3edb659453d6322e)
[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114958 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:ff4646793f2805f0c66705469becdfdd4b5356d1 commit r14-10294-gff4646793f2805f0c66705469becdfdd4b5356d1 Author: Matthias Kretz Date: Mon May 6 12:13:55 2024 +0200 libstdc++: Use __builtin_shufflevector for simd split and concat Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114958 * include/experimental/bits/simd.h (__as_vector): Return scalar simd as one-element vector. Return vector from single-vector fixed_size simd. (__vec_shuffle): New. (__extract_part): Adjust return type signature. (split): Use __extract_part for any split into non-fixed_size simds. (concat): If the return type stores a single vector, use __vec_shuffle (which calls __builtin_shufflevector) to produce the return value. * include/experimental/bits/simd_builtin.h (__shift_elements_right): Removed. (__extract_part): Return single elements directly. Use __vec_shuffle (which calls __builtin_shufflevector) to for all non-trivial cases. * include/experimental/bits/simd_fixed_size.h (__extract_part): Return single elements directly. * testsuite/experimental/simd/pr114958.cc: New test. (cherry picked from commit fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9)
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #14 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:8bb6b2f4ae19c3aab7d7a5e5c8f5965f89d90e01
commit r15-1122-g8bb6b2f4ae19c3aab7d7a5e5c8f5965f89d90e01
Author: Uros Bizjak
Date: Sun Jun 9 12:09:13 2024 +0200
i386: Implement .SAT_SUB for unsigned scalar integers [PR112600]
The following testcase:
unsigned
sub_sat (unsigned x, unsigned y)
{
unsigned res;
res = x - y;
res &= -(x >= y);
return res;
}
currently compiles (-O2) to:
sub_sat:
movl%edi, %edx
xorl%eax, %eax
subl%esi, %edx
cmpl%esi, %edi
setnb %al
negl%eax
andl%edx, %eax
ret
We can expand through ussub{m}3 optab to use carry flag from the
subtraction
and generate code using SBB instruction implementing:
unsigned res = x - y;
res &= ~(-(x < y));
sub_sat:
subl%esi, %edi
sbbl%eax, %eax
notl%eax
andl%edi, %eax
ret
PR target/112600
gcc/ChangeLog:
* config/i386/i386.md (ussub3): New expander.
(sub_3): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112600-b.c: New test.
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c3e16edcf2c8429da2cb479d8941397f4300e0c4 commit r14-10291-gc3e16edcf2c8429da2cb479d8941397f4300e0c4 Author: Harald Anlauf Date: Mon Jun 3 22:02:06 2024 +0200 Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865] gcc/fortran/ChangeLog: PR fortran/83865 * trans-stmt.cc (gfc_trans_allocate): Restrict special case for source-expression with zero-length character to rank 0, so that the array shape is not discarded. gcc/testsuite/ChangeLog: PR fortran/83865 * gfortran.dg/allocate_with_source_32.f90: New test. (cherry picked from commit 7f21aee0d4ef95eee7d9f7f42e9a056715836648)
[Bug libstdc++/108760] ranges::iota is not included in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760 --- Comment #6 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0bb1db32ccf54a9de59bea718f7575f7ef22abf5 commit r15-1117-g0bb1db32ccf54a9de59bea718f7575f7ef22abf5 Author: Michael Levine Date: Fri Jun 7 09:54:38 2024 +0100 libstdc++: Fix std::ranges::iota is not included in numeric [PR108760] Before this patch, using std::ranges::iota required including when it should have been sufficient to only include . libstdc++-v3/ChangeLog: PR libstdc++/108760 * include/bits/ranges_algo.h (ranges::out_value_result): Move to . (ranges::iota_result, ranges::__iota_fn, ranges::iota): Move to . * include/bits/ranges_algobase.h (ranges::out_value_result): Move to here. * include/std/numeric (ranges::iota_result, ranges::__iota_fn) (ranges::iota): Move to here. * testsuite/25_algorithms/iota/1.cc: Renamed to ... * testsuite/26_numerics/iota/2.cc: ... here. Signed-off-by: Michael Levine
[Bug c++/108438] [11/12/13/14/15 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:7611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108438
--- Comment #3 from GCC Commits ---
The master branch has been updated by Simon Martin :
https://gcc.gnu.org/g:2c9643c27ecddb7f597d34009d89e932b4aca58e
commit r15-1114-g2c9643c27ecddb7f597d34009d89e932b4aca58e
Author: Simon Martin
Date: Fri Jun 7 11:21:07 2024 +0200
c++: Make *_cast<*> parsing more robust to errors [PR108438]
We ICE upon the following when trying to emit a -Wlogical-not-parentheses
warning:
=== cut here ===
template T foo (T arg, T& ref, T* ptr) {
int a = 1;
return static_cast(a);
}
=== cut here ===
This patch makes *_cast<*> parsing more robust by skipping to the closing
'>'
upon error in the target type.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/108438
gcc/cp/ChangeLog:
* parser.cc (cp_parser_postfix_expression): Use
cp_parser_require_end_of_template_parameter_list to skip to the
closing
'>' upon error parsing the target type of *_cast<*> expressions.
gcc/testsuite/ChangeLog:
* g++.dg/parse/crash75.C: New test.
[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112600
--- Comment #13 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:de05e44b2ad9638d04173393b1eae3c38b2c3864
commit r15-1113-gde05e44b2ad9638d04173393b1eae3c38b2c3864
Author: Uros Bizjak
Date: Sat Jun 8 12:17:11 2024 +0200
i386: Implement .SAT_ADD for unsigned scalar integers [PR112600]
The following testcase:
unsigned
add_sat(unsigned x, unsigned y)
{
unsigned z;
return __builtin_add_overflow(x, y, ) ? -1u : z;
}
currently compiles (-O2) to:
add_sat:
addl%esi, %edi
jc .L3
movl%edi, %eax
ret
.L3:
orl $-1, %eax
ret
We can expand through usadd{m}3 optab to use carry flag from the addition
and generate branchless code using SBB instruction implementing:
unsigned res = x + y;
res |= -(res < x);
add_sat:
addl%esi, %edi
sbbl%eax, %eax
orl %edi, %eax
ret
PR target/112600
gcc/ChangeLog:
* config/i386/i386.md (usadd3): New expander.
(x86_movcc_0_m1_neg): Use SWI mode iterator.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112600-a.c: New test.
[Bug analyzer/105892] RFE: -fanalyzer could complain about pointer subtraction of pointers to different memory chunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105892
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:13dcaf1bb6d4f15665a47b14ac0c12cf454e38a2
commit r15-1107-g13dcaf1bb6d4f15665a47b14ac0c12cf454e38a2
Author: David Malcolm
Date: Fri Jun 7 16:14:28 2024 -0400
analyzer: new warning: -Wanalyzer-undefined-behavior-ptrdiff (PR
analyzer/105892)
Add a new warning to complain about pointer subtraction involving
different chunks of memory.
For example, given:
#include
int arr[42];
int sentinel;
ptrdiff_t
test_invalid_calc_of_array_size (void)
{
return - arr;
}
this emits:
demo.c: In function âtest_invalid_calc_of_array_sizeâ:
demo.c:9:20: warning: undefined behavior when subtracting pointers
[CWE-469] [-Wanalyzer-undefined-behavior-ptrdiff]
9 | return - arr;
|^
events 1-2
â
â3 | int arr[42];
â | ~~~
â | |
â | (2) underlying object for right-hand side of subtraction
created here
â4 | int sentinel;
â | ^~~~
â | |
â | (1) underlying object for left-hand side of subtraction
created here
â
âââ> âtest_invalid_calc_of_array_sizeâ: event 3
â
â9 | return - arr;
â |^
â ||
â |(3) â ï¸ subtraction of
pointers has undefined behavior if they do not point into the same array object
â
gcc/analyzer/ChangeLog:
PR analyzer/105892
* analyzer.opt (Wanalyzer-undefined-behavior-ptrdiff): New option.
* analyzer.opt.urls: Regenerate.
* region-model.cc (class undefined_ptrdiff_diagnostic): New.
(check_for_invalid_ptrdiff): New.
(region_model::get_gassign_result): Call it for POINTER_DIFF_EXPR.
gcc/ChangeLog:
* doc/invoke.texi: Add -Wanalyzer-undefined-behavior-ptrdiff.
gcc/testsuite/ChangeLog:
PR analyzer/105892
* c-c++-common/analyzer/out-of-bounds-pr110387.c: Add
expected warnings about pointer subtraction.
* c-c++-common/analyzer/ptr-subtraction-1.c: New test.
* c-c++-common/analyzer/ptr-subtraction-CWE-469-example.c: New
test.
Signed-off-by: David Malcolm
[Bug c++/107575] [12/13/14/15 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in duplicate_decls, at cp/decl.cc:2605 since r12-8115-g791a968630b3846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107575
--- Comment #4 from GCC Commits ---
The master branch has been updated by Simon Martin :
https://gcc.gnu.org/g:0ce138694a6b40708a80691fa4003f6af1defa49
commit r15-1105-g0ce138694a6b40708a80691fa4003f6af1defa49
Author: Simon Martin
Date: Tue Jun 4 21:20:23 2024 +0200
c++: Handle erroneous DECL_LOCAL_DECL_ALIAS in duplicate_decls [PR107575]
We currently ICE upon the following because we don't properly handle local
functions with an error_mark_node as DECL_LOCAL_DECL_ALIAS in
duplicate_decls.
=== cut here ===
void f (void) {
virtual int f (void) const;
virtual int f (void);
}
=== cut here ===
This patch fixes this by checking for error_mark_node.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/107575
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Check for error_mark_node
DECL_LOCAL_DECL_ALIAS.
gcc/testsuite/ChangeLog:
* g++.dg/parse/crash74.C: New test.
[Bug c++/115378] [14/15 Regression] ICE with lambda function as a default template argument with variadic templates in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115378 --- Comment #7 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5c761395402a730535983a5e49ef1775561ebc61 commit r15-1103-g5c761395402a730535983a5e49ef1775561ebc61 Author: Patrick Palka Date: Fri Jun 7 12:12:30 2024 -0400 c++: lambda in pack expansion [PR115378] Here find_parameter_packs_r is incorrectly treating the 'auto' return type of a lambda as a parameter pack due to Concepts-TS specific logic added in r6-4517, leading to confusion later when expanding the pattern. Since we intend on removing Concepts TS support soon anyway, this patch fixes this by restricting the problematic logic with flag_concepts_ts. Doing so revealed that add_capture was relying on this logic to set TEMPLATE_TYPE_PARAMETER_PACK for the 'auto' type of an pack expansion init-capture, which we now need to do explicitly. PR c++/115378 gcc/cp/ChangeLog: * lambda.cc (lambda_capture_field_type): Set TEMPLATE_TYPE_PARAMETER_PACK on the auto type of an init-capture pack expansion. * pt.cc (find_parameter_packs_r) : Restrict TEMPLATE_TYPE_PARAMETER_PACK promotion with flag_concepts_ts. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto-103497.C: Adjust expected diagnostic. * g++.dg/template/pr95672.C: Likewise. * g++.dg/cpp2a/lambda-targ5.C: New test. Reviewed-by: Jason Merrill
[Bug target/115353] [14 regression] Missed thumb2 table branch instruction optimisations since r14-4946-g7006e5d2d7b5b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115353 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Ball : https://gcc.gnu.org/g:ca1924947b5bed8105ae020bef6950bddda448f3 commit r14-10289-gca1924947b5bed8105ae020bef6950bddda448f3 Author: Richard Ball Date: Thu Jun 6 16:10:14 2024 +0100 arm: Fix CASE_VECTOR_SHORTEN_MODE for thumb2. The CASE_VECTOR_SHORTEN_MODE query is missing some equals signs which causes suboptimal codegen due to missed optimisation opportunities. This patch also adds a test for thumb2 switch statements as none exist currently. gcc/ChangeLog: PR target/115353 * config/arm/arm.h (enum arm_auto_incmodes): Correct CASE_VECTOR_SHORTEN_MODE query. gcc/testsuite/ChangeLog: * gcc.target/arm/thumb2-switchstatement.c: New test. (cherry picked from commit 2963c76e8e24d4ebaf2b1b4ac4d7ca44eb0a9025)
[Bug target/115351] [14/15 regression] pointless movs when passing by value on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351 --- Comment #4 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:fb3e4c549d16d5050e10114439ad77149f33c597 commit r15-1101-gfb3e4c549d16d5050e10114439ad77149f33c597 Author: Roger Sayle Date: Fri Jun 7 14:03:20 2024 +0100 i386: PR target/115351: RTX costs for *concatditi3 and *insvti_highpart. This patch addresses PR target/115351, which is a code quality regression on x86 when passing floating point complex numbers. The ABI considers these arguments to have TImode, requiring interunit moves to place the FP values (which are actually passed in SSE registers) into the upper and lower parts of a TImode pseudo, and then similar moves back again before they can be used. The cause of the regression is that changes in how TImode initialization is represented in RTL now prevents the RTL optimizers from eliminating these redundant moves. The specific cause is that the *concatditi3 pattern, (zext(hi)<<64)|zext(lo), has an inappropriately high (default) rtx_cost, preventing fwprop1 from propagating it. This pattern just sets the hipart and lopart of a double-word register, typically two instructions (less if reload can allocate things appropriately) but the current ix86_rtx_costs actually returns INSN_COSTS(13), i.e. 52. propagating insn 5 into insn 6, replacing: (set (reg:TI 110) (ior:TI (and:TI (reg:TI 110) (const_wide_int 0x0)) (ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ]) 0)) (const_int 64 [0x40] successfully matched this instruction to *concatditi3_3: (set (reg:TI 110) (ior:TI (ashift:TI (zero_extend:TI (subreg:DI (reg:DF 112 [ zD.2796+8 ]) 0)) (const_int 64 [0x40])) (zero_extend:TI (subreg:DI (reg:DF 111 [ zD.2796 ]) 0 change not profitable (cost 50 -> cost 52) This issue is resolved by having ix86_rtx_costs return more reasonable values for these (place-holder) patterns. 2024-06-07 Roger Sayle gcc/ChangeLog PR target/115351 * config/i386/i386.cc (ix86_rtx_costs): Provide estimates for the *concatditi3 and *insvti_highpart patterns, about two insns. gcc/testsuite/ChangeLog PR target/115351 * g++.target/i386/pr115351.C: New test case.
[Bug fortran/90068] Array Constructor Containing Function Call Leaks Memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90068 --- Comment #4 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:c3190756487080a11e819746f00b6e30fd0a0c2e commit r15-1094-gc3190756487080a11e819746f00b6e30fd0a0c2e Author: Andre Vehreschild Date: Thu Jul 27 14:51:34 2023 +0200 Add finalizer creation to array constructor for functions of derived type. PR fortran/90068 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_array_ctor_element): Eval non- variable expressions once only. (gfc_trans_array_constructor_value): Add statements of final block. (trans_array_constructor): Detect when final block is required. gcc/testsuite/ChangeLog: * gfortran.dg/finalize_57.f90: New test.
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0f616e75f32083e1bc6d08f31e3fbc3dea41fa0c commit r14-10288-g0f616e75f32083e1bc6d08f31e3fbc3dea41fa0c Author: Jakub Jelinek Date: Fri Jun 7 10:32:08 2024 +0200 bitint: Fix up lower_addsub_overflow [PR115352] The following testcase is miscompiled because of a flawed optimization. If one changes the 65 in the testcase to e.g. 66, one gets: ... _25 = .USUBC (0, _24, _14); _12 = IMAGPART_EXPR <_25>; _26 = REALPART_EXPR <_25>; if (_23 >= 1) goto ; [80.00%] else goto ; [20.00%] : if (_23 != 1) goto ; [80.00%] else goto ; [20.00%] : _27 = (signed long) _26; _28 = _27 >> 1; _29 = (unsigned long) _28; _31 = _29 + 1; _30 = _31 > 1; goto ; [100.00%] : _32 = _26 != _18; _33 = _22 | _32; : # _17 = PHI <_30(9), _22(7), _33(10)> # _19 = PHI <_29(9), _18(7), _18(10)> ... so there is one path for limbs below the boundary (in this case there are actually no limbs there, maybe we could consider optimizing that further, say with simply folding that _23 >= 1 condition to 1 == 1 and letting cfg cleanup handle it), another case where it is exactly the limb on the boundary (that is the bb 9 handling where it extracts the interesting bits (the first 3 statements) and then checks if it is zero or all ones and finally the case of limbs above that where it compares the current result limb against the previously recorded 0 or all ones and ors differences into accumulated result. Now, the optimization which the first hunk removes was based on the idea that for that case the extraction of the interesting bits from the limb don't need anything special, so the _27/_28/_29 statements above aren't needed, the whole limb is interesting bits, so it handled the >= 1 case like the bb 9 above without the first 3 statements and bb 10 wasn't there at all. There are 2 problems with that, for the higher limbs it only checks if the the result limb bits are all zeros or all ones, but doesn't check if they are the same as the other extension bits, and it forgets the previous flag whether there was an overflow. First I wanted to fix it just by adding the _33 = _22 | _30; statement to the end of bb 9 above, which fixed the originally filed huge testcase and the first 2 foo calls in the testcase included in the patch, it no longer forgets about previously checked differences from 0/1. But as the last 2 foo calls show, it still didn't check whether each even (or each odd depending on the exact position) result limb is equal to the first one, so every second limb it could choose some other 0 vs. all ones value and as long as it repeated in another limb above it it would be ok. So, the optimization just can't work properly and the following patch removes it. 2024-06-07 Jakub Jelinek PR middle-end/115352 * gimple-lower-bitint.cc (lower_addsub_overflow): Don't disable single_comparison if cmp_code is GE_EXPR. * gcc.dg/torture/bitint-71.c: New test. (cherry picked from commit a47b1aaa7a76201da7e091d9f8d4488105786274)
[Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115352 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a47b1aaa7a76201da7e091d9f8d4488105786274 commit r15-1093-ga47b1aaa7a76201da7e091d9f8d4488105786274 Author: Jakub Jelinek Date: Fri Jun 7 10:32:08 2024 +0200 bitint: Fix up lower_addsub_overflow [PR115352] The following testcase is miscompiled because of a flawed optimization. If one changes the 65 in the testcase to e.g. 66, one gets: ... _25 = .USUBC (0, _24, _14); _12 = IMAGPART_EXPR <_25>; _26 = REALPART_EXPR <_25>; if (_23 >= 1) goto ; [80.00%] else goto ; [20.00%] : if (_23 != 1) goto ; [80.00%] else goto ; [20.00%] : _27 = (signed long) _26; _28 = _27 >> 1; _29 = (unsigned long) _28; _31 = _29 + 1; _30 = _31 > 1; goto ; [100.00%] : _32 = _26 != _18; _33 = _22 | _32; : # _17 = PHI <_30(9), _22(7), _33(10)> # _19 = PHI <_29(9), _18(7), _18(10)> ... so there is one path for limbs below the boundary (in this case there are actually no limbs there, maybe we could consider optimizing that further, say with simply folding that _23 >= 1 condition to 1 == 1 and letting cfg cleanup handle it), another case where it is exactly the limb on the boundary (that is the bb 9 handling where it extracts the interesting bits (the first 3 statements) and then checks if it is zero or all ones and finally the case of limbs above that where it compares the current result limb against the previously recorded 0 or all ones and ors differences into accumulated result. Now, the optimization which the first hunk removes was based on the idea that for that case the extraction of the interesting bits from the limb don't need anything special, so the _27/_28/_29 statements above aren't needed, the whole limb is interesting bits, so it handled the >= 1 case like the bb 9 above without the first 3 statements and bb 10 wasn't there at all. There are 2 problems with that, for the higher limbs it only checks if the the result limb bits are all zeros or all ones, but doesn't check if they are the same as the other extension bits, and it forgets the previous flag whether there was an overflow. First I wanted to fix it just by adding the _33 = _22 | _30; statement to the end of bb 9 above, which fixed the originally filed huge testcase and the first 2 foo calls in the testcase included in the patch, it no longer forgets about previously checked differences from 0/1. But as the last 2 foo calls show, it still didn't check whether each even (or each odd depending on the exact position) result limb is equal to the first one, so every second limb it could choose some other 0 vs. all ones value and as long as it repeated in another limb above it it would be ok. So, the optimization just can't work properly and the following patch removes it. 2024-06-07 Jakub Jelinek PR middle-end/115352 * gimple-lower-bitint.cc (lower_addsub_overflow): Don't disable single_comparison if cmp_code is GE_EXPR. * gcc.dg/torture/bitint-71.c: New test.
[Bug go/87589] [11/12/13/14/15 regression] index0-out.go FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589 --- Comment #14 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:9ab90fc627301b1701cf19bf4ca220f02a93d894 commit r15-1091-g9ab90fc627301b1701cf19bf4ca220f02a93d894 Author: Rainer Orth Date: Fri Jun 7 10:12:09 2024 +0200 testsuite: go: Require split-stack support for go.test/test/index0.go [PR87589] The index0-out.go test FAILs on Solaris (SPARC and x86, 32 and 64-bit), as well as several others: FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments The test SEGVs because it tries a stack acess way beyond the stack area. As Ian analyzed in the PR, the testcase currently requires split-stack support, so this patch requires just that. Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. 2024-06-05 Rainer Orth gcc/testsuite: PR go/87589 * go.test/go-test.exp (go-gc-tests): Require split-stack support for index0.go.
[Bug fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90072 --- Comment #3 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:51046e46ae66ca95bf2b93ae60f0c4d6b338f8af commit r15-1090-g51046e46ae66ca95bf2b93ae60f0c4d6b338f8af Author: Andre Vehreschild Date: Wed Jul 19 11:57:43 2023 +0200 Fix returned type to be allocatable for user-functions. The returned type of user-defined function returning a class object was not detected and handled correctly, which lead to memory leaks. PR fortran/90072 gcc/fortran/ChangeLog: * expr.cc (gfc_is_alloc_class_scalar_function): Detect allocatable class return types also for user-defined functions. * trans-expr.cc (gfc_conv_procedure_call): Same. (trans_class_vptr_len_assignment): Compute vptr len assignment correctly for user-defined functions. gcc/testsuite/ChangeLog: * gfortran.dg/class_77.f90: New test.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #12 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:56c73729c3eab08ca48f366bd435f98457743e45 commit r14-10286-g56c73729c3eab08ca48f366bd435f98457743e45 Author: Jakub Jelinek Date: Thu Jun 6 22:12:11 2024 +0200 c: Fix up pointer types to may_alias structures [PR114493] The following testcase ICEs in ipa-free-lang, because the fld_incomplete_type_of gcc_assert (TYPE_CANONICAL (t2) != t2 && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); assertion doesn't hold. This is because t is a struct S * type which was created while struct S was still incomplete and without the may_alias attribute (and TYPE_CANONICAL of a pointer type is a type created with can_alias_all = false argument), while later on on the struct definition may_alias attribute was used. fld_incomplete_type_of then creates an incomplete distinct copy of the structure (but with the original attributes) but pointers created for it are because of the "may_alias" attribute TYPE_REF_CAN_ALIAS_ALL, including their TYPE_CANONICAL, because while that is created with !can_alias_all argument, we later set it because of the "may_alias" attribute on the to_type. This doesn't ICE with C++ since PR70512 fix because the C++ FE sets TYPE_REF_CAN_ALIAS_ALL on all pointer types to the class type (and its variants) when the may_alias is added. The following patch does that in the C FE as well. 2024-06-06 Jakub Jelinek PR c/114493 * c-decl.cc (c_fixup_may_alias): New function. (finish_struct): Call it if "may_alias" attribute is specified. * gcc.dg/pr114493-1.c: New test. * gcc.dg/pr114493-2.c: New test. (cherry picked from commit d5a3c6d43acb8b2211d9fb59d59482d74c010f01)
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #11 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d5a3c6d43acb8b2211d9fb59d59482d74c010f01 commit r15-1080-gd5a3c6d43acb8b2211d9fb59d59482d74c010f01 Author: Jakub Jelinek Date: Thu Jun 6 22:12:11 2024 +0200 c: Fix up pointer types to may_alias structures [PR114493] The following testcase ICEs in ipa-free-lang, because the fld_incomplete_type_of gcc_assert (TYPE_CANONICAL (t2) != t2 && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); assertion doesn't hold. This is because t is a struct S * type which was created while struct S was still incomplete and without the may_alias attribute (and TYPE_CANONICAL of a pointer type is a type created with can_alias_all = false argument), while later on on the struct definition may_alias attribute was used. fld_incomplete_type_of then creates an incomplete distinct copy of the structure (but with the original attributes) but pointers created for it are because of the "may_alias" attribute TYPE_REF_CAN_ALIAS_ALL, including their TYPE_CANONICAL, because while that is created with !can_alias_all argument, we later set it because of the "may_alias" attribute on the to_type. This doesn't ICE with C++ since PR70512 fix because the C++ FE sets TYPE_REF_CAN_ALIAS_ALL on all pointer types to the class type (and its variants) when the may_alias is added. The following patch does that in the C FE as well. 2024-06-06 Jakub Jelinek PR c/114493 * c-decl.cc (c_fixup_may_alias): New function. (finish_struct): Call it if "may_alias" attribute is specified. * gcc.dg/pr114493-1.c: New test. * gcc.dg/pr114493-2.c: New test.
[Bug target/113880] V2SF->V2DF conversion pattern seems to be missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113880 --- Comment #2 from GCC Commits --- The master branch has been updated by Pengxuan Zheng : https://gcc.gnu.org/g:230d62a2cdd16c1ec8fe87998ec01081503f010d commit r15-1079-g230d62a2cdd16c1ec8fe87998ec01081503f010d Author: Pengxuan Zheng Date: Thu May 30 17:53:23 2024 -0700 aarch64: Add vector floating point extend pattern [PR113880, PR113869] This patch adds vector floating point extend pattern for V2SF->V2DF and V4HF->V4SF conversions by renaming the existing aarch64_float_extend_lo_ pattern to the standard optab one, i.e., extend2. This allows the vectorizer to vectorize certain floating point widening operations for the aarch64 target. PR target/113880 PR target/113869 gcc/ChangeLog: * config/aarch64/aarch64-builtins.cc (VAR1): Remap float_extend_lo_ builtin codes to standard optab ones. * config/aarch64/aarch64-simd.md (aarch64_float_extend_lo_): Rename to... (extend2): ... This. gcc/testsuite/ChangeLog: * gcc.target/aarch64/extend-vec.c: New test. Signed-off-by: Pengxuan Zheng
