aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2022-04-14c++: lambda and the current instantiation [PR82980]Jason Merrill2-1/+37
When a captured variable is type-dependent, we've expressed the type of the capture field and proxy with a decltype variant. But if the type is "the current instantiation", we need to be able to see that so that we can do lookup inside it just like we could with the captured variable itself. I also tried looking through lambda capture in cp_parser_postfix_dot_deref_expression, but this way seems cleaner. I plan to treat more types as deducible in stage 1. I considered also using this in do_auto_deduction, but think that would be wrong: [temp.dep.expr] says an id-expression is type-dependent if it is "associated by name lookup with a variable declared with a type that contains a placeholder type where the initializer is type-dependent". That doesn't clearly exclude deducing a dependent type from the initializer, but it seems like a barrier, and other implementations agree. PR c++/82980 gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): New. (lambda_capture_field_type): Check it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-current-inst1.C: New test.
2022-04-14Refactor and update CTF testcases [PR105089]Indu Bhagat3-15/+46
This commit splits the ctf-array-2.c into ctf-array-5.c and ctf-variables.c with the following responsibilities: [1] ctf-array-2.c: Test CTF generation for unsized arrays. [2] ctf-array-5.c: Test CTF generation for unsized but initialized array. [3] ctf-variables-3.c: Test CTF generation for extern variable with defining decl. Earlier all three tests above were being done in ctf-array-2.c. The checks around [3] were very loose in the original version of ctf-array-2.c in that the testcase was only checking that the types are as expected. The compiler was emitting two CTF variable records as follows: Variables: _CTF_NEWSTR -> 5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0) _CTF_NEWSTR -> 8: const const char [8] (size 0x8) -> 7: const char [8] (size 0x8) This is incorrect behaviour as it creates ambiguity. The testcase ctf-variables-3.c now has added checks that only one CTF variable record is expected. 2022-04-14 Indu Bhagat <indu.bhagat@oracle.com> gcc/testsuite/ChangeLog: PR debug/105089 * gcc.dg/debug/ctf/ctf-array-2.c: Refactor testcase. Move some checks ... * gcc.dg/debug/ctf/ctf-array-5.c: ... to here. * gcc.dg/debug/ctf/ctf-variables-3.c: ... and here. Add additional checks for one CTF variable and one CTF object info record.
2022-04-14CTF for extern variable fix [PR105089]Indu Bhagat4-12/+98
The CTF format cannot differentiate between a non-defining extern variable declaration vs. a defining variable declaration (unlike DWARF). So, the correct behaviour wrt the compiler generating CTF for such extern variables (i.e., when both the defining and non-defining decl are present in the same CU) is to simply emit the CTF variable correspoding to the defining declaration. To carry out the above, following changes are introduced via the patch: 1. The CTF container (ctfc.h) now keeps track of the non-defining declarations (by noting the DWARF attribute DW_AT_specification) in a new ctfc_ignore_vars hashtable. Such book-keeping is necessary because the CTF container should not rely on the order of DWARF DIEs presented to it at generation time. 2. At the time of ctf_add_variable (), the DW_AT_specification DIE if present is added in the ctfc_ignore_vars hashtable. The CTF variable generation for the defining declaration continues as normal. 3. If the ctf_add_variable () is asked to generate CTF variable for a DIE present in the ctfc_ignore_vars, it skips generating CTF for it. 4. Recall that CTF variables are pre-processed before emission. Till now, the only pre-processing that was being done was to sort them in order of their names. Now an additional step is added: If the CTF variable which corresponds to the non-defining declaration is indeed present in the ctfc_vars hashtable (because the corresponding DWARF DIE was encountered first by the CTF generation engine), skip that CTF variable from output. An important side effect of such a workflow above is that CTF for the C type of the non-defining decl will remain in the CTF dictionary (and will be emitted in the output section as well). This type can be pruned by the link-time de-duplicator as usual, if deemed unused. 2022-04-14 Indu Bhagat <indu.bhagat@oracle.com> gcc/ChangeLog: PR debug/105089 * ctfc.cc (ctf_dvd_ignore_insert): New function. (ctf_dvd_ignore_lookup): Likewise. (ctf_add_variable): Keep track of non-defining decl DIEs. (new_ctf_container): Initialize the new hash-table. (ctfc_delete_container): Empty hash-table. * ctfc.h (struct ctf_container): Add new hash-table. (ctf_dvd_ignore_lookup): New declaration. (ctf_add_variable): Add additional argument. * ctfout.cc (ctf_dvd_preprocess_cb): Skip adding CTF variable record for non-defining decl for which a defining decl exists in the same TU. (ctf_preprocess): Defer updating the number of global objts until here. (output_ctf_header): Use ctfc_vars_list_count as some CTF variables may not make it to the final output. (output_ctf_vars): Likewise. * dwarf2ctf.cc (gen_ctf_variable): Skip generating CTF variable if this is known to be a non-defining decl DIE.
2022-04-14ctfc: get rid of the static variable in ctf_list_add_ctf_vars ()Indu Bhagat2-3/+3
2022-04-14 Indu Bhagat <indu.bhagat@oracle.com> gcc/ChangeLog: * ctfc.h (struct ctf_container): Introduce a new member. * ctfout.cc (ctf_list_add_ctf_vars): Use it instead of static variable.
2022-04-14analyzer: fix ICE comparing VECTOR_CSTs [PR105252]David Malcolm2-3/+30
gcc/analyzer/ChangeLog: PR analyzer/105252 * svalue.cc (cmp_cst): When comparing VECTOR_CSTs, compare the types of the encoded elements before calling cmp_cst on them. gcc/testsuite/ChangeLog: PR analyzer/105252 * gcc.dg/analyzer/pr105252.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-04-14simplify-rtx: Don't assume shift count has the same mode as the shift [PR105247]Jakub Jelinek2-1/+33
The following testcase ICEs on ia64. It is UB at runtime, but we shouldn't ICE on it... The problem is that on ia64, the shift count (last operand of ASHIFT etc.) is promoted to DImode (using zero-extension), while most other targets use much narrower modes (say QImode). If we try to simplify a shift and the shift count is CONST_INT or other VOIDmode integer constant which isn't properly sign extended for the first operand's mode (in the testcase the shift count is 0xfffffff8U and it is a SImode shift), then we ICE during wide_int wop1 = pop1; in the first hunk, INTVAL == 0xfffffff8U is not valid for SImode. I think in theory we could run into this even on other targets, say if they use SImode or HImode shift counts for e.g. QImode shifts. I hope word size is the upper bound of what a reasonable target should use, using e.g. multiple registers for the shift count is insane, so the following patch if op1 has VOIDmode and int_mode is narrower than word uses word_mode for extraction of the value. 2022-04-14 Jakub Jelinek <jakub@redhat.com> PR target/105247 * simplify-rtx.cc (simplify_const_binary_operation): For shifts or rotates by VOIDmode constant integer shift count use word_mode for the operand if int_mode is narrower than word. * gcc.c-torture/compile/pr105247.c: New test.
2022-04-14testsuite/s390: Silence warning in pr80725.cRobin Dapp1-1/+1
This test case checks that we do not ICE but FAILs because of -Wint-to-pointer-cast. Silence this warning. gcc/testsuite/ChangeLog: * gcc.target/s390/pr80725.c: Add -Wno-int-to-pointer-cast.
2022-04-14s390: Add scheduler description for z16.Robin Dapp4-6/+2592
This patch adds the scheduler description for the z16 machine. gcc/ChangeLog: * config/s390/s390.cc (s390_get_sched_attrmask): Add z16. (s390_get_unit_mask): Likewise. (s390_is_fpd): Likewise. (s390_is_fxd): Likewise. * config/s390/s390.h (s390_tune_attr): Set max tune level to z16. * config/s390/s390.md (z900,z990,z9_109,z9_ec,z10,z196,zEC12,z13,z14,z15): Add z16. (z900,z990,z9_109,z9_ec,z10,z196,zEC12,z13,z14,z15,z16): Likewise. * config/s390/3931.md: New file.
2022-04-13c++: alignment of local typedef in template [PR65211]Jason Merrill2-0/+22
Because common_handle_aligned_attribute only applies the alignment to the TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it explicitly in tsubst. PR c++/65211 gcc/cp/ChangeLog: * pt.cc (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN. gcc/testsuite/ChangeLog: * g++.target/i386/vec-tmpl1.C: New test.
2022-04-13c++: local fn and generic lambda [PR97219]Jason Merrill5-4/+42
When instantiating the op() for a generic lambda, we can no longer do name lookup inside function scopes enclosing the lambda, so we need to remember the lookup result from processing the definition of the lambda. So the code in finish_call_expr to throw away the lookup result and instead look it up again at instantiation time needs to be adjusted. The approach I take is to only discard the result if the local extern comes from dependent scope; once the enclosing function template is instantiated and we're regenerating the lambda, then we can remember the result of lookup. We also need any default arguments to be instantiated at that point. PR c++/97219 gcc/cp/ChangeLog: * name-lookup.cc (dependent_local_decl_p): New. * cp-tree.h (dependent_local_decl_p): Declare. * semantics.cc (finish_call_expr): Use it. * pt.cc (tsubst_arg_types): Also substitute default args for local externs. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-local-fn1.C: New test.
2022-04-13c++: template conversion op [PR101698]Jason Merrill2-1/+36
Asking for conversion to a dependent type also makes a BASELINK dependent. PR c++/101698 gcc/cp/ChangeLog: * pt.cc (tsubst_baselink): Also check dependent optype. gcc/testsuite/ChangeLog: * g++.dg/template/conv19.C: New test.
2022-04-13c++: NRV and ref-extended temps [PR101442]Jason Merrill4-3/+38
This issue goes back to r83221, where the cleanup for extended ref temps changed from being unconditional to being tied to the declaration they formed part of the initializer for. The named return value optimization changes the cleanup for the NRV variable to only run on the EH path; we don't want that change to affect temporary cleanups. The perform_member_init change isn't necessary (there 'decl' is a COMPONENT_REF), it's just for consistency. PR c++/101442 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Don't pass decl to push_cleanup. * init.cc (perform_member_init): Likewise. * semantics.cc (push_cleanup): Adjust comment. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-nrv1.C: New test.
2022-04-13c++: add test [PR105265]Jason Merrill1-0/+39
This was fixed by r12-1165, but good to have a test that doesn't need -fno-elide-constructors. PR c++/105265 PR c++/100838 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-new6.C: New test.
2022-04-14Daily bump.GCC Administrator6-1/+169
2022-04-13go.test: update issue10441.go to current upstream versionIan Lance Taylor1-1/+1
This test only needs to be compiled, not linked.
2022-04-13aarch64: Make sure the UF divides the VF [PR105254]Richard Sandiford2-4/+34
In this PR, we were trying to set the unroll factor to a value higher than the minimum VF (or more specifically, to a value that doesn't divide the VF). I guess there are two approaches to this: let the target pick any value it likes and make target-independent code pare it back to something that makes sense, or require targets to supply sensible values from the outset. This patch goes for the latter approach. gcc/ PR tree-optimization/105254 * config/aarch64/aarch64.cc (aarch64_vector_costs::determine_suggested_unroll_factor): Take a loop_vec_info as argument. Restrict the unroll factor to values that divide the VF. (aarch64_vector_costs::finish_cost): Update call accordingly. gcc/testsuite/ PR tree-optimization/105254 * g++.dg/vect/pr105254.cc: New test.
2022-04-13OpenMP/Fortran: Fix EXIT in loop diagnostic [PR105242]Tobias Burnus2-71/+769
gcc/fortran/ChangeLog: PR fortran/105242 * match.cc (match_exit_cycle): Handle missing OMP LOOP, DO and SIMD directives in the EXIT/CYCLE diagnostic. gcc/testsuite/ChangeLog: PR fortran/105242 * gfortran.dg/gomp/loop-exit.f90: New test.
2022-04-13c++: empty base constexpr -fno-elide-ctors [PR105245]Jason Merrill2-0/+7
The patch for 100111 extended our handling of empty base elision to the case where the derived class has no other fields, but we still need to make sure that there's some initializer for the derived object. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_store_expression): Build a CONSTRUCTOR as needed in empty base handling. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.
2022-04-13d: Merge upstream dmd 4d1bfcf14, druntime 9ba9a6ae, phobos c0cc5e917.Iain Buclaw87-504/+1560
D front-end changes: - Import dmd v2.099.1. - Added `@mustuse' attribute, implmenting DIP 1038. - Added `.tupleof` property for static arrays D runtime changes: - Import druntime v2.099.1. Phobos changes: - Import phobos v2.099.1. - Zlib bindings have been updated to 1.2.12. gcc/d/ChangeLog: * Make-lang.in (D_FRONTEND_OBJS): Add d/common-bitfields.o, d/mustuse.o. * d-ctfloat.cc (CTFloat::isIdentical): Don't treat NaN values as identical. * dmd/MERGE: Merge upstream dmd 4d1bfcf14. * expr.cc (ExprVisitor::visit (VoidInitExp *)): New. libphobos/ChangeLog: * libdruntime/MERGE: Merge upstream druntime 9ba9a6ae. * src/MERGE: Merge upstream phobos c0cc5e917.
2022-04-13tree-optimization/105263 - reassoc and DFPRichard Biener2-1/+18
reassoc has certain tricks which in the end depend on the ability to undo them. For DFP creating a -1. constant is easy but re-identifying is appearantly not - real_minus_onep rejects those outright for DFP. So we have to disable (at least) this one trick. 2022-04-13 Richard Biener <rguenther@suse.de> PR tree-optimization/105263 * tree-ssa-reassoc.cc (try_special_add_to_ops): Do not consume negates in multiplication chains with DFP. * gcc.dg/pr105263.c: New testcase.
2022-04-13tree.cc: Use useless_type_conversion_p in ↵Jakub Jelinek2-6/+33
tree_builtin_call_types_compatible_p while in gimple form [PR105253] tree_builtin_call_types_compatible_p uses TYPE_MAIN_VARIANT comparisons or tree_nop_conversion_p to ensure a builtin has correct GENERIC arguments. Unfortunately this regressed when get_call_combined_fn is called during GIMPLE optimizations. E.g. when number_of_iterations_popcount is called, it doesn't ensure TYPE_MAIN_VARIABLE compatible argument type, it picks __builtin_popcount{,l,ll} based just on types' precision and doesn't fold_convert the arg to the right type. We are in GIMPLE, such conversions are useless... So, either we'd need to fix number_of_iterations_popcount to add casts and inspect anything else that creates CALL_EXPRs late, or we can in tree_builtin_call_types_compatible_p just use the GIMPLE type comparisons (useless_type_conversion_p) when we are in GIMPLE form and the TYPE_MAIN_VARIANT comparison or tree_nop_conversion_p test otherwise. I think especially this late in stage4 the latter seems safer to me. 2022-04-13 Jakub Jelinek <jakub@redhat.com> PR middle-end/105253 * tree.cc (tree_builtin_call_types_compatible_p): If PROP_gimple, use useless_type_conversion_p checks instead of TYPE_MAIN_VARIANT comparisons or tree_nop_conversion_p checks. * gcc.target/i386/pr105253.c: New test.
2022-04-13c++: Treat alignas align_expr and aligned attribute's operand as manifestly ↵Jakub Jelinek2-1/+27
constant evaluation [PR105233] The following testcase fails, because we only constant evaluate the alignas argument as non-manifestly constant-evaluated and as __builtin_is_constant_evaluated appears, we make it non-constant (the reason is that we often try to evaluate some expression without manifestly_const_eval perhaps even multiple times before actually evaluating it with manifestly_const_eval (e.g. when folding for warnings and in many other places), and we don't want __builtin_is_constant_evaluated to evaluate to false in those cases, because we could get a different result from when we actually evaluate it with manifestly_const_eval set). Now, for alignas the standard seems to be clear, it says the argument is constant-expression, which means we should manifestly-constant-eval it. Attributes are a fuzzy area, they are extensions and various attributes take e.g. identifiers, or string literals etc. as arguments. Either we can just treat alignas as manifestly-const-eval, for that we'd need some way how to differentiate between alignas and gnu::aligned or aligned attribute. Another possibility is what the patch below implements, treat both alignas and gnu::aligned and aligned attribute's argument as manifestly-const-eval and not do that for other attributes. Another is to go through all attributes and figure out for which such treatment is useful (e.g. those that expect INTEGER_CST as argument), and either add a new column in the attribute table or have another table in the C++ FE to find out which attribute needs that. Another is do that for all the attribute arguments that are EXPR_P and see what breaks (bet that it could be quite risky this late in GCC 12 cycle and especially for backporting). 2022-04-13 Jakub Jelinek <jakub@redhat.com> PR c++/105233 * decl2.cc (cp_check_const_attributes): For aligned attribute pass manifestly_const_eval=true to fold_non_dependent_expr. * g++.dg/cpp2a/is-constant-evaluated13.C: New test.
2022-04-13testsuite: Increase auto-inlining param in gcc.dg/ipa/remref-7.c (PR 105183)Martin Jambor1-1/+1
A scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of platforms. I investigated only i?86-*-* with -mno-sse but assume the issue is the same on all of the affected platform. Because function bar is not inlined there even though it is only called once, the process that is being tested is simply not triggered. This can be "fixed" by increasing parameter max-inline-insns-auto to something high, I randomly picked 100. I have only manually tested the change but hopefully that is enough. gcc/testsuite/ChangeLog: 2022-04-08 Martin Jambor <mjambor@suse.cz> PR testsuite/105183 * gcc.dg/ipa/remref-7.c: Add --param max-inline-insns-auto=100 to options.
2022-04-13c++: ambiguous call not diagnosed after DR2352 [PR97296]Marek Polacek3-3/+24
DR 2352 changed the definitions of reference-related (so that it uses "similar type" instead of "same type") and of reference-compatible (use a standard conversion sequence). That means that reference-related is now more broad, which means that we will be binding more things directly. The original patch for DR 2352 caused some problems, which were fixed in r276251 by creating a "fake" ck_qual in direct_reference_binding, so that in void f(int *); // #1 void f(const int * const &); // #2 int *x; int main() { f(x); // call #1 } we call #1. The extra ck_qual in #2 causes compare_ics to select #1, which is a better match for "int *" because then we don't have to do a qualification conversion. Let's turn to the problem in this PR. We have void f(const int * const &); // #1 void f(const int *); // #2 int *x; int main() { f(x); } We arrive in compare_ics to decide which one is better. The ICS for #1 looks like ck_ref_bind <- ck_qual <- ck_identity const int *const & const int *const int * and the ICS for #2 is ck_qual <- ck_rvalue <- ck_identity const int * int * int * We strip the reference and then comp_cv_qual_signature when comparing two ck_quals sees that "const int *" is a proper subset of "const int *const" and we return -1. But that's wrong; presumably the top-level "const" should be ignored and the call should be ambiguous. This patch adjust the type of the "fake" ck_qual so that this problem doesn't arise. PR c++/97296 gcc/cp/ChangeLog: * call.cc (direct_reference_binding): strip_top_quals when creating a ck_qual. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/ref-bind4.C: Add dg-error. * g++.dg/cpp0x/ref-bind8.C: New test.
2022-04-13middle-end/105259 - adjust gcc.target/i386/auto-init-4.cRichard Biener1-2/+3
This adjusts the FAILing testcase to only check for the pieces that work. The bug tracks improving pattern-init for long double. 2022-04-13 Richard Biener <rguenther@suse.de> PR middle-end/105259 * gcc.target/i386/auto-init-4.c: Adjust.
2022-04-13i386: Fix infinite loop under -mrelax-cmpxchg-loop [PR 103069]Hongyu Wang1-0/+1
For -mrelax-cmpxchg-loop which relaxes atomic_fetch_<logic> loops, there is a missing set to %eax when compare fails, which would result in infinite loop in some benchmark. Add set to %eax to avoid it. gcc/ChangeLog: PR target/103069 * config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop): Add missing set to target_val at pause label.
2022-04-13attribs: Restrict decl_attributes DECL_FUNCTION_SPECIFIC_TARGET changes to ↵Jakub Jelinek2-9/+28
targets that care about target attributes/pragmas [PR105234] The following code is rejected e.g. on mips64el-linux (but I think many other targets which don't support target attribute or pragma). The problem is that the change to decl_attributes below is done unconditionally and with just #pragma GCC push_options/pop_options pair we have target_option_default_node NULL, but after popping options target_option_current_node becomes non-NULL and this decl_attribute spot fills in DECL_FUNCTION_SPECIFIC_TARGET of a subset of a functions. Those appearing before push_options/pop_options will have it NULL and as target_option_default_node is also NULL on those targets, the default can_inline_p will refuse to inline any functions defined with NULL DECL_FUNCTION_SPECIFIC_TARGET into any function with non-NULL DECL_FUNCTION_SPECIFIC_TARGET (even when nothing in the options really changed). The following patch restricts that snippet to targets that care (initialize target_option_default_node to non-NULL to the command line options early) which include all targets that actually implement target attribute and/or pragma. 2022-04-13 Jakub Jelinek <jakub@redhat.com> PR target/105234 * attribs.cc (decl_attributes): Don't set DECL_FUNCTION_SPECIFIC_TARGET if target_option_default_node is NULL. * gcc.c-torture/compile/pr105234.c: New test.
2022-04-13tree-optimization/105250 - adjust fold_convertible_p PR105140 fixRichard Biener2-4/+32
The following reverts the original PR105140 fix and goes for instead applying the additional fold_convert constraint for VECTOR_TYPE conversions also to fold_convertible_p. I did not try sanitizing all of this at this point. 2022-04-13 Richard Biener <rguenther@suse.de> PR tree-optimization/105250 * fold-const.cc (fold_convertible_p): Revert r12-7979-geaaf77dd85c333, instead check for size equality of the vector types involved. * gcc.dg/pr105250.c: New testcase.
2022-04-13Revert "tree-optimization/104912 - ensure cost model is checked first"Richard Biener1-57/+3
This reverts commit ac8340ee4d1e65f3fd41c547b16895875f4aefa7.
2022-04-13tree-optimization/104912 - ensure cost model is checked firstRichard Biener1-3/+57
The following makes sure that when we build the versioning condition for vectorization including the cost model check, we check for the cost model and branch over other versioning checks. That is what the cost modeling assumes, since the cost model check is the only one accounted for in the scalar outside cost. Currently we emit all checks as straight-line code combined with bitwise ops which can result in surprising ordering of checks in the final assembly. Since loop_version accepts only a single versioning condition the splitting is done after the fact. The result is a 1.5% speedup of 416.gamess on x86_64 when compiling with -Ofast and tuning for generic or skylake. That's not enough to recover from the slowdown when vectorizing but it now cuts off the expensive alias versioning test. 2022-03-21 Richard Biener <rguenther@suse.de> PR tree-optimization/104912 * tree-vect-loop-manip.cc (vect_loop_versioning): Split the cost model check to a separate BB to make sure it is checked first and not combined with other version checks.
2022-04-13scev: Fix a comment typoJakub Jelinek1-1/+1
When looking at the kernel __popcountdi2 issue, I've noticed a comment typo. 2022-04-13 Jakub Jelinek <jakub@redhat.com> * tree-scalar-evolution.cc (expression_expensive_p): Fix a comment typo.
2022-04-12ppc: testsuite: skip pr60203 on no ldbl128Alexandre Oliva1-0/+1
If neither 128-bit long double format is available, skip pr60203.c. for gcc/testsuite/ChangeLog * gcc.target/powerpc/pr60203.c: Skip on no 128-bit long double.
2022-04-12ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146]Alexandre Oliva1-1/+1
The test expects a compare of DImode values, but after the removal of PROMOTE_MODE from rs6000/, we get SImode. Adjust the expectations. for gcc/testsuite/ChangeLog PR target/102146 * gcc.target/powerpc/pr56605.c: Accept SImode compare operand.
2022-04-13mips: testsuite: enforce -ffat-lto-objects for pr102024-4.cXi Ruoyao1-1/+1
The body of func is optimized away with -flto -fno-fat-lto-objects, so the psABI inform is not emitted, causing a test failure. gcc/testsuite/ * gcc.target/mips/pr102024-4.c (dg-options): Add -ffat-lto-objects.
2022-04-13Daily bump.GCC Administrator5-1/+351
2022-04-12libgccjit: Add support for setting the alignment [PR104293]Antoni Boucher11-614/+871
gcc/jit/ PR jit/104293 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag. * docs/topics/expressions.rst: Add documentation for the functions gcc_jit_lvalue_set_alignment and gcc_jit_lvalue_get_alignment. * jit-playback.h: New function (set_alignment). * jit-recording.cc: New function (set_alignment). * jit-recording.h: New functions (set_alignment, get_alignment) and new field (m_alignment). * libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment, gcc_jit_lvalue_set_alignment) * libgccjit.h: New functions (gcc_jit_lvalue_get_alignment, gcc_jit_lvalue_set_alignment) * libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag. gcc/testsuite/ PR jit/104293 * jit.dg/all-non-failing-tests.h: Mention test-setting-alignment. * jit.dg/test-setting-alignment.c: New test.
2022-04-12libgccjit: Add function to hide stderr logs [PR104073]Antoni Boucher8-845/+953
gcc/jit/ PR jit/104073 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_23): New ABI tag. * docs/topics/contexts.rst: Add documentation for the new function gcc_jit_context_set_bool_print_errors_to_stderr. * jit-common.h: New enum value (INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR). * jit-recording.cc: Handle the new option INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR. * libgccjit.cc: New function (gcc_jit_context_set_bool_print_errors_to_stderr). * libgccjit.h: New function (gcc_jit_context_set_bool_print_errors_to_stderr). * libgccjit.map (LIBGCCJIT_ABI_23): New ABI tag.
2022-04-12libgccjit: Add support for register variables [PR104072]Antoni Boucher17-615/+895
gcc/jit/ PR jit/104072 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_22): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_lvalue_set_register_name. * jit-playback.h: New function (set_register_name). * jit-recording.cc: New function (set_register_name) and add support for register variables. * jit-recording.h: New field (m_reg_name) and new function (set_register_name). * libgccjit.cc: New function (gcc_jit_lvalue_set_register_name). * libgccjit.h: New function (gcc_jit_lvalue_set_register_name). * libgccjit.map (LIBGCCJIT_ABI_22): New ABI tag. gcc/ PR jit/104072 * reginfo.cc: New functions (clear_global_regs_cache, reginfo_cc_finalize) to avoid an issue where compiling the same code multiple times gives an error about assigning the same register to 2 global variables. * rtl.h: New function (reginfo_cc_finalize). * toplev.cc: Call it. gcc/testsuite/ PR jit/104072 * jit.dg/all-non-failing-tests.h: Add new test-register-variable. * jit.dg/harness.h: Add -fdiagnostics-color=never to context's command-line options. * jit.dg/test-error-register-variable-bad-name.c: New test. * jit.dg/test-error-register-variable-size-mismatch.c: New test. * jit.dg/test-register-variable.c: New test.
2022-04-12libgccjit: Add support for bitcasts [PR104071]Antoni Boucher17-625/+1079
gcc/jit/ PR jit/104071 * docs/_build/texinfo/libgccjit.texi: Regenerate. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_context_new_bitcast. * jit-playback.cc: New function (new_bitcast). * jit-playback.h: New function (new_bitcast). * jit-recording.cc: New functions (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer). * jit-recording.h: New class (bitcast) and new function (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer, bitcast::get_precedence). * libgccjit.cc: New function (gcc_jit_context_new_bitcast) * libgccjit.h: New function (gcc_jit_context_new_bitcast) * libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag. gcc/testsuite/ PR jit/104071 * jit.dg/all-non-failing-tests.h: Add new test-bitcast. * jit.dg/test-bitcast.c: New test. * jit.dg/test-error-bad-bitcast.c: New test. * jit.dg/test-error-bad-bitcast2.c: New test. gcc/ PR jit/104071 * toplev.cc: Call the new function tree_cc_finalize in toplev::finalize. * tree.cc: New functions (clear_nonstandard_integer_type_cache and tree_cc_finalize) to clear the cache of non-standard integer types to avoid having issues with some optimizations of bitcast where the SSA_NAME will have a size of a cached integer type that should have been invalidated, causing a comparison of integer constant to fail. * tree.h: New function (tree_cc_finalize).
2022-04-12libgccjit: Add support for sized integer types, including 128-bit integers ↵Antoni Boucher12-732/+1352
[PR95325] gcc/jit/ PR target/95325 * docs/_build/texinfo/libgccjit.texi: Regenerate * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag. * docs/topics/types.rst: Add documentation for the new types GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T and new functions (gcc_jit_compatible_types, gcc_jit_type_get_size). * jit-builtins.cc: Add support for BT_UINT128. * jit-common.h: Update the value of NUM_GCC_JIT_TYPES. * jit-playback.cc: Add support for the sized integer types. * jit-recording.cc: Add support for the sized integer types. * jit-recording.h: Add support for comparing integer types and new function (is_signed). * libgccjit.cc (gcc_jit_compatible_types): New. (gcc_jit_type_get_size) New. * libgccjit.h: New enum variants for gcc_jit_types (GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T) and new functions (gcc_jit_compatible_types, gcc_jit_type_get_size). * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. gcc/testsuite/ PR target/95325 * jit.dg/test-types.c: Add tests for sized integer types.
2022-04-12c++: local function versioning [PR104669]Jason Merrill3-8/+34
There were two problems with this testcase: we weren't copying the target attribute from the second declaration to the global alias for the first one (duplicate_decls hunk), and then we were treating the third one as matching the earlier one even though both are versioned (decls_match hunk). The latter change required a fix to find_last_decl (used for attribute mismatch warnings) to give up if we see a versioned function, as in that case we can't determine whether the decls match, because we are still in the process of setting the attributes on the new decl. PR c++/104669 gcc/cp/ChangeLog: * decl.cc (decls_match): Compare versions even if not recording. (duplicate_decls): Propagate attributes to alias. * decl2.cc (find_last_decl): Give up if versioned. gcc/testsuite/ChangeLog: * g++.target/i386/mv31.C: New test.
2022-04-12c++: non-array new alignment [PR102071]Jason Merrill2-1/+5
While considering the PR102071 patch for backporting, I noticed that I was considering the alignment of the array new cookie even when there isn't one because we aren't allocating an array. PR c++/102071 gcc/cp/ChangeLog: * init.cc (build_new_1): Check array_p for alignment. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/aligned-new9.C: Add single-object test.
2022-04-12Let nvptx-as figure out the target architecture [PR97348]Thomas Schwinge2-6/+0
... now that it has been enhanced to do so. This is a follow-up to PR97348 commit 383400a6078d75bbfa1216c9af2c37f7e88740c9 "[nvptx] Set -misa=sm_35 by default". gcc/ PR target/97348 * config/nvptx/nvptx.h (ASM_SPEC): Don't set. * config/nvptx/nvptx.opt (misa): Adjust comment.
2022-04-12Revert "[nvptx] Use --no-verify for sm_30"Thomas Schwinge1-1/+1
This reverts commit 12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4.
2022-04-12Revert "[nvptx] Fix ASM_SPEC workaround for sm_30"Thomas Schwinge1-18/+4
This reverts commit bf4832d6fa817f66009f100a9cd68953062add7d.
2022-04-12c++: requires-expr in pack expansion using pack [PR103105]Patrick Palka3-1/+42
Here after dependent substitution of {Ts...} into the alias 'wrap', since we never partially instantiate a requires-expr, we end up with a requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts). Then when hashing the resulting dependent specialization of A, we crash from iterative_hash_template_arg since it deliberately doesn't handle ARGUMENT_PACK_SELECT. Like in r12-7102-gdb5f1c17031ad8, it seems the right fix here is to resolve ARGUMENT_PACK_SELECT arguments before storing them into an extra args tree (such as REQUIRES_EXPR). PR c++/103105 gcc/cp/ChangeLog: * pt.cc (build_extra_args): Call preserve_args. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires29.C: New test. * g++.dg/cpp2a/concepts-requires29a.C: New test.
2022-04-12ipa/104303 - revert overly conservative DCE changeRichard Biener1-1/+1
The following reverts the DCE change back to the original behavior which should be handled well during the propagation stage. That should fix the failures Thomas Schwinge is reporting. 2022-04-12 Richard Biener <rguenther@suse.de> PR ipa/104303 * tree-ssa-dce.cc (mark_stmt_if_obviously_necessary): Do not include local escaped memory as obviously necessary stores.
2022-04-12arm: fix testsuite failure of reg_equal_test.c [PR101755]Richard Earnshaw1-17/+8
The test failure in PR101755 is due to the gimple optimizers getting smarter. But really we are just testing that RTL expansion is doing the right thing and annotating a constant accordingly. So rework the test to use GIMPLE input and simplify the code entirely. Also, this test only ever worked on architecture versions with the MOVW/MOVT instructions, so check for this before running. gcc/testsuite/ChangeLog: PR target/101755 * gcc.target/arm/reg_equal_test.c: Convert to gimple test. Restrict to architectures with MOVW/MOVT.
2022-04-12tree-optimization/105235 - clean EH in execute_cse_conv_1Richard Biener2-6/+21
When a FP conversion is removed we have to eventually clean EH. 2022-04-12 Richard Biener <rguenther@suse.de> PR tree-optimization/105235 * tree-ssa-math-opts.cc (execute_cse_conv_1): Clean EH and return whether the CFG changed. (execute_cse_sincos_1): Adjust. * g++.dg/opt/pr105235-1.C: New testcase.
2022-04-12arm: remove unnecessary armv9-a multilib variant [PR104144]Przemyslaw Wirkus3-32/+21
Remove the armv9-a specific multilib variants. Instead, arrange to use either the armv8-a multilibs or the armv7-a versions, depeding on the configuration. This eliminates the need to have a version of gas that understands --march=armv9-a when building GCC. Very little, if anything in the standard libraries directly uses Armv9-a features anyway. Also remove the +crc variant rules for Armv9-a. CRC is an implicit part of Armv9-a, so doesn't have a explicit feature to handle it. gcc/ChangeLog: PR target/104144 * config/arm/t-aprofile (MULTI_ARCH_OPTS_A): Remove Armv9-a options. (MULTI_ARCH_DIRS_A): Remove Armv9-a diretories. (MULTILIB_REQUIRED): Don't require Armv9-a libraries. (MULTILIB_MATCHES): Treat Armv9-a as equivalent to Armv8-a. (MULTILIB_REUSE): Remove remap rules for Armv9-a. * config/arm/t-multilib (v9_a_nosimd_variants): Delete. (MULTILIB_MATCHES): Remove mappings for v9_a_nosimd_variants. gcc/testsuite/ChangeLog: PR target/104144 * gcc.target/arm/multilib.exp: Updated tests.