Releases/gcc 12 #65
Open
Releases/gcc 12 #65
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is an unofficial mirror that has nothing to do with the GCC project, so submitting pull requests here is a waste of time. Also, I have no idea what this pull request is trying to do but it would never be accepted even if it was submitted to the right place. |
atahanozbayram
approved these changes
Apr 2, 2024
NinaRanns
pushed a commit
to NinaRanns/gcc
that referenced
this pull request
Jan 28, 2025
…on-r15-7214-g0710024b5bd861 Contracts nonattr rebase on r15 7214 g0710024b5bd861
The testcase contains a VNx2QImode pseudo that is live across a call and that cannot be allocated a call-preserved register. LRA quite reasonably tried to save it before the call and restore it afterwards. Unfortunately, the target told it to do that in SImode, even though punning between SImode and VNx2QImode is disallowed by both TARGET_CAN_CHANGE_MODE_CLASS and TARGET_MODES_TIEABLE_P. The natural class to use for SImode is GENERAL_REGS, so this led to an unsalvageable situation in which we had: (set (subreg:VNx2QI (reg:SI A) 0) (reg:VNx2QI B)) where A needed GENERAL_REGS and B needed FP_REGS. We therefore ended up in a reload loop. The hooks above should ensure that this situation can never occur for incoming subregs. It only happened here because the target explicitly forced it. The decision to use SImode for modes smaller than 4 bytes dates back to the beginning of the port, before 16-bit floating-point modes existed. I'm not sure whether promoting to SImode really makes sense for any FPR, but that's a separate performance/QoI discussion. For now, this patch just disallows using SImode when it is wrong for correctness reasons, since that should be safer to backport. gcc/ PR testsuite/116238 * config/aarch64/aarch64.cc (aarch64_hard_regno_caller_save_mode): Only return SImode if we can convert to and from it. gcc/testsuite/ PR testsuite/116238 * gcc.target/aarch64/sve/pr116238.c: New test. (cherry picked from commit ec9d6d4)
The svwhilele folder mishandled the degenerate case in which the second argument is the maximum integer. In that case, the result is all-true regardless of the first parameter: If the second scalar operand is equal to the maximum signed integer value then a condition which includes an equality test can never fail and the result will be an all-true predicate. This is because the conceptual "increment the first operand by 1 after each element" is done modulo the range of the operand. The GCC code was instead treating it as infinite precision. whilele_5.c even had a test for the incorrect behaviour. The easiest fix seemed to be to handle that case specially before doing constant folding. This also copes with variable first operands. gcc/ PR target/116999 PR target/117045 * config/aarch64/aarch64-sve-builtins-base.cc (svwhilelx_impl::fold): Check for WHILELTs of the minimum value and WHILELEs of the maximum value. Fold them to all-false and all-true respectively. gcc/testsuite/ PR target/116999 PR target/117045 * gcc.target/aarch64/sve/acle/general/whilele_5.c: Fix bogus expected result. * gcc.target/aarch64/sve/acle/general/whilele_11.c: New test. * gcc.target/aarch64/sve/acle/general/whilele_12.c: Likewise. (cherry picked from commit 50e7c51)
There was an embarrassing typo in the folding of BIT_NOT_EXPR for POLY_INT_CSTs: it used - rather than ~ on the poly_int. Not sure how that happened, but it might have been due to the way that ~x is implemented as -1 - x internally. gcc/ PR tree-optimization/118976 * fold-const.cc (const_unop): Use ~ rather than - for BIT_NOT_EXPR. * config/aarch64/aarch64.cc (aarch64_test_sve_folding): New function. (aarch64_run_selftests): Run it. (cherry picked from commit 78380fd)
An optimization was added in GDC-12 which sets the TREE_READONLY flag on all local variables with the storage class `const' assigned. For some reason, const is also being added by the front-end to `__result' variables in non-virtual functions, which ends up getting wrong code by the gimplify pass promoting the local to static storage. A bug has been raised upstream, as this looks like an error in the AST. For now, turn off setting TREE_READONLY on all result variables. PR d/119139 gcc/d/ChangeLog: * decl.cc (get_symbol_decl): Don't set TREE_READONLY for __result declarations. gcc/testsuite/ChangeLog: * gdc.dg/pr119139.d: New test. (cherry picked from commit 81582ca)
PR middle-end/117811 PR testsuite/52641 gcc/testsuite/ * gcc.dg/torture/pr117811.c: Fix for int < 32 bit. (cherry picked from commit 07f229c)
r8-7538 for PR84968 made strip_typedefs_expr diagnose STATEMENT_LIST so that we reject statement-expressions in noexcept-specifiers to match our behavior in template arguments (which the parser diagnoses directly). Later r11-7452 made decltype(auto) deduction canonicalize the expression (as an implementation detail) which in turn calls strip_typedefs_expr, and so ever since we inadvertently reject decltype(auto) deduction of a statement-expression. This patch just removes the diagnostic in strip_typedefs_expr and instead treats statement-expressions similar to lambda-expressions. The function doesn't seem like the right place for such a diagnostic and so it seems easier to just accept rather than try to reject them in a suitable place. PR c++/116418 gcc/cp/ChangeLog: * tree.cc (strip_typedefs_expr) <case STATEMENT_LIST>: Replace this error path with ... <case STMT_EXPR>: ... this, returning the original tree. gcc/testsuite/ChangeLog: * g++.dg/eh/pr84968.C: No longer expect an ahead of time diagnostic for the statement-expresssion. Instantiate the template and expect an incomplete type error instead. * g++.dg/ext/stmtexpr26.C: New test. Reviewed-by: Jason Merrill <[email protected]> (cherry picked from commit 12bdcc3)
r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts first so that we prefer processing a local specialization in an evaluated context even if its first use is in an unevaluated context. But this means we need to avoid walking a tree that already has extra args/specs saved because the list of saved specs appears to be an evaluated context which we'll now walk first. It seems then that we should be calculating the saved specs from scratch each time, rather than potentially walking the saved specs list from an earlier partial instantiation when calling build_extra_args a second time around. PR c++/114303 gcc/cp/ChangeLog: * constraint.cc (tsubst_requires_expr): Clear REQUIRES_EXPR_EXTRA_ARGS before calling build_extra_args. * pt.cc (tree_extra_args): Define. (extract_locals_r): Assert *_EXTRA_ARGS is empty. (tsubst_stmt) <case IF_STMT>: Clear IF_SCOPE on the new IF_STMT. Call build_extra_args on the new IF_STMT instead of t which might already have IF_STMT_EXTRA_ARGS. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if-lambda6.C: New test. Reviewed-by: Jason Merrill <[email protected]> (cherry picked from commit b262b17)
Here when checking the access of (the injected-class-name) B in c->B::m at parse time, we notice its context B (now the type) is a base of the object type C<T>, so we proceed to use C<T> as the effective qualifying type. But this C<T> is the dependent specialization not the primary template type, so it has empty TYPE_BINFO, which leads to a segfault later from perform_or_defer_access_check. The reason the DERIVED_FROM_P (B, C<T>) test guarding this code path works despite C<T> having empty TYPE_BINFO is because of its currently_open_class logic (added in r9-713-gd9338471b91bbe) which replaces a dependent specialization with the primary template type if we're inside it. So the safest fix seems to be to call currently_open_class in the caller as well. PR c++/116320 gcc/cp/ChangeLog: * semantics.cc (check_accessibility_of_qualified_id): Try currently_open_class when using the object type as the effective qualifying type. gcc/testsuite/ChangeLog: * g++.dg/template/access42.C: New test. Reviewed-by: Jason Merrill <[email protected]> (cherry picked from commit 484f139)
Here we end up ICEing at instantiation time for the call to f<local_static> ultimately because we wrongly consider the call to be non-dependent, and so we specialize f ahead of time and then get confused when fully substituting this specialization. The call is dependent due to [temp.dep.temp]/3 and we miss that because function template-id arguments aren't coerced until overload resolution, and so the local static template argument lacks an implicit cast to reference type that value_dependent_expression_p looks for before considering dependence of the address. Other kinds of template-ids aren't affected since they're coerced ahead of time. So when considering dependence of a function template-id, we need to conservatively consider dependence of the address of each argument (if applicable). PR c++/117792 gcc/cp/ChangeLog: * pt.cc (type_dependent_expression_p): Consider the dependence of the address of each template argument of a function template-id. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/nontype7.C: New test. Reviewed-by: Jason Merrill <[email protected]> (cherry picked from commit 40f0f6a)
When a loop is marked with #pragma GCC novector the following makes sure to also skip BB vectorization for contained blocks. That avoids gcc.dg/vect/bb-slp-29.c failing on aarch64 because of extra BB vectorization therein. I'm not specifically dealing with sub-loops of novector loops, the desired semantics isn't documented. PR tree-optimization/111125 * tree-vect-slp.cc (vect_slp_function): Split at novector loop entry, do not push blocks in novector loops. (cherry picked from commit 43da77a)
The first argument is supposed to be a type, not a decl. PR c++/79786 gcc/cp/ * rtti.cc (emit_tinfo_decl): Fix DATA_ABI_ALIGNMENT invocation. (cherry picked from commit 6ec1982)
The following disables redundant store elimination to hard register variables which isn't valid. PR tree-optimization/87984 * tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do not perform redundant store elimination to hard register variables. * tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt): Likewise. * gcc.target/i386/pr87984.c: New testcase. (cherry picked from commit 535115c)
The following fixes a thinko in the handling of interposed weak definitions which confused the interposition check in get_availability by setting DECL_EXTERNAL too early. PR lto/91299 gcc/lto/ * lto-symtab.cc (lto_symtab_merge_symbols): Set DECL_EXTERNAL only after calling get_availability. gcc/testsuite/ * gcc.dg/lto/pr91299_0.c: New testcase. * gcc.dg/lto/pr91299_1.c: Likewise. (cherry picked from commit bc34db5)
When we gimplify &MEM[0B + 4] we are re-folding the address in case types are not canonical which ends up with a constant address that recompute_tree_invariant_for_addr_expr ICEs on. Properly guard that call. PR middle-end/101478 * gimplify.cc (gimplify_addr_expr): Check we still have an ADDR_EXPR before calling recompute_tree_invariant_for_addr_expr. * gcc.dg/pr101478.c: New testcase. (cherry picked from commit 33ead64)
view_converted_memref_p was checking the reference type against the pointer type of the offset operand rather than its pointed-to type which leads to all refs being subject to view-convert treatment in get_alias_set causing numerous testsuite fails but with its new uses from r15-512-g9b7cad5884f21c is also a wrong-code issue. PR middle-end/115110 * tree-ssa-alias.cc (view_converted_memref_p): Fix. (cherry picked from commit a5b3721)
PR107467 ended up being fixed by the fix for PR115110, but let's add the testcase on top. gcc/testsuite/ChangeLog: PR tree-optimization/107467 PR middle-end/115110 * g++.dg/lto/pr107467_0.C: New test. (cherry picked from commit 4e09ae3)
We currently record a kill for *x_4(D) = always_throws (); because we consider the store always executing since the appropriate check for whether the stmt could throw is guarded by !cfun->can_throw_non_call_exceptions. PR ipa/111245 * ipa-modref.cc (modref_access_analysis::analyze_store): Do not guard the check of whether the stmt could throw by cfun->can_throw_non_call_exceptions. * g++.dg/torture/pr111245.C: New testcase. (cherry picked from commit e6037af)
When we get a zero distance vector we still have to check for the situation of a common inner loop with zero distance. But we can still allow a zero distance for the loop we distribute (gcc.dg/tree-ssa/ldist-33.c is such a case). This is because zero distances in non-outermost loops are a misrepresentation of dependence by dependence analysis. Note that test coverage of loop distribution of loop nests is very low. PR tree-optimization/112859 PR tree-optimization/115347 * tree-loop-distribution.cc (loop_distribution::pg_add_dependence_edges): For a zero distance vector still make sure to not have an inner loop with zero distance. * gcc.dg/torture/pr112859.c: New testcase. * gcc.dg/torture/pr115347.c: Likewise. * gcc.dg/tree-ssa/ldist-36.c: Adjust. (cherry picked from commit 04ba130)
This adds a comment before the workaround, indicating flaky dependence analysis. PR tree-optimization/112859 * tree-loop-distribution.cc (loop_distribution::pg_add_dependence_edges): Add comment. (cherry picked from commit 3ccbc8c)
When we process function types we strip volatile and const qualifiers after building a simplified type variant (which preserves those). The qualified type handling of both isn't really compatible, so avoid bad interaction by swapping this, first dropping const/volatile qualifiers and then building the simplified type thereof. PR lto/113207 * ipa-free-lang-data.cc (free_lang_data_in_type): First drop const/volatile qualifiers from function argument types, then build a simplified type. * gcc.dg/pr113207.c: New testcase. (cherry picked from commit a55e14b)
The following makes sure to also walk CONSTRUCTOR element indexes which can be FIELD_DECLs, referencing otherwise unused types we need to clean. walk_tree only walks CONSTRUCTOR element data. PR lto/114501 * ipa-free-lang-data.cc (find_decls_types_r): Explicitly handle CONSTRUCTORs as walk_tree handling of those is incomplete. * g++.dg/pr114501_0.C: New testcase. (cherry picked from commit fdd95e1)
When there's an inner loop without virtual header PHI but the outer loop has one the fusion process cannot handle the need to create an inner loop virtual header PHI. Punt in this case. PR tree-optimization/117113 * gimple-loop-jam.cc (unroll_jam_possible_p): Detect when we cannot handle virtual SSA update. * gcc.dg/torture/pr117113.c: New testcase. (cherry picked from commit 0675eb1)
The following addresses a bug in tree_could_trap_p leading to hoisting of a possibly trapping, because of out-of-bound, access. We only ensured the first accessed byte is within a decl there, the patch makes sure the whole base of the reference is within it. This is pessimistic if a handled component would then subset to a sub-object within the decl but upcasting of a decl to larger types should be uncommon, questionable, and wrong without -fno-strict-aliasing. The testcase is a bit fragile, but I could not devise a (portable) way to ensure an out-of-bound access to a decl would fault. PR tree-optimization/117424 * tree-eh.cc (tree_could_trap_p): Verify the base is fully contained within a decl. * gcc.dg/tree-ssa/ssa-lim-25.c: New testcase. (cherry picked from commit f1e776c)
We are detecting a cycle as double reduction where the inner loop cycle has extra out-of-loop uses. This clashes at least with assumptions from the SLP discovery code which says the cycle isn't reachable from another SLP instance. It also was not intended to support this case, in fact with GCC 14 we seem to generate wrong code here. PR tree-optimization/119057 * tree-vect-loop.cc (check_reduction_path): Add argument specifying whether we're analyzing the inner loop of a double reduction. Do not allow extra uses outside of the double reduction cycle in this case. (vect_is_simple_reduction): Adjust. * gcc.dg/vect/pr119057.c: New testcase. (cherry picked from commit 758de62)
The following testcase runs into a re-gimplification issue during
inlining when processing
MEM[(struct e *)this_2(D)].a = {};
where re-gimplification does not handle assignments in the same
way than the gimplifier but instead relies on rhs_predicate_for
and gimplifying the RHS standalone. This fails to handle
special-casing of CTORs. The is_gimple_mem_rhs_or_call predicate
already handles clobbers but not empty CTORs so we end up in
the fallback code trying to force the CTOR into a separate stmt
using a temporary - but as we have a non-copyable type here that ICEs.
The following generalizes empty CTORs in is_gimple_mem_rhs_or_call
since those need no additional re-gimplification.
PR middle-end/119119
* gimplify.cc (is_gimple_mem_rhs_or_call): All empty CTORs
are OK when not a register type.
* g++.dg/torture/pr11911.C: New testcase.
(cherry picked from commit 3bd61c1)
The following makes sure to reject the attempts to emulate a vector gather when the discovered index vector type is a vector mask. PR tree-optimization/119534 * tree-vect-stmts.cc (get_load_store_type): Reject VECTOR_BOOLEAN_TYPE_P offset vector type for emulated gathers. * gcc.dg/vect/pr119534.c: New testcase. (cherry picked from commit d0cc14c)
We currently only INTEGER_CST, but not POLY_INT_CST, which leads to the situation that when the POLY_INT_CST is only indrectly present via a SSA def the IL is valid but when propagated it's not. That's unsustainable. PR middle-end/119706 * gimple-expr.cc (is_gimple_mem_ref_addr): Also allow POLY_INT_CST. (cherry picked from commit bf812c6)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support for Apple Silicon!!!