aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2020-10-30Predefine __ppc and __ppc__ for VxWorks 7Olivier Hainque1-0/+6
Unfortunately, some VxWorks 7r2 system headers rely on a couple more variations of the predefined macros expected to characterize a "powerpc" target that we discussed recently. setjmp.h, for example, relies on __ppc and the absence of a definition results in "gcc" dejagnu test failures from all the tests #including that header, which stumble on: #error "_JBLEN not set!" The other case is __ppc__ expected by yvals.h, key to libstdc++. This change adjusts the VxWorks 7 section of our configuration to honor those expectations. 2020-10-29 Olivier Hainque <hainque@adacore.com> gcc/ * config/rs6000/vxworks.h (TARGET_OS_CPP_BUILTINS): Also builtin_define __ppc and __ppc__ for VxWorks 7.
2020-10-30Introduce support for vxworks7r2 on x86 and x86_64Olivier Hainque3-37/+80
This change extends the VxWorks support on intel CPUs to VxWorks7r2 for x86_64 as well as x86, with a "mcmodel=large" additional multilib for the 64bit configuration. The support for fPIC is not functional yet for this model, so we just don't add the corresponding multilib. We extend the range of CPU families handled by TARGET_OS_CPP_BUILTINS, accounting for the fact that archs older than PENTIUM4 are not supported (any more) by VxWorks 7. As we did for powerpc, we leverage VX_CPU_PREFIX to emit different forms of definitions for different families of VxWorks as the system headers's expectations has evolved between Vx 5, 6 and 7. 2020-10-27 Olivier Hainque <hainque@adacore.com> gcc/ * config.gcc: Adjust the ix86/x86_64-wrs-vxworks filters to apply to VxWorks 7 as well. * config/i386/t-vxworks (MULTILIB_OPTIONS, MULTILIB_DIRNAMES): Remove the fPIC multilib and add one for the large code model on x86_64. * config/i386/vxworks.h: Separate sections for TARGET_VXWORKS7, other variants and common bits. (TARGET_OS_CPP_BUILTINS): Augment to support a range of CPU families. Leverage VX_CPU_PREFIX. (CC1_SPEC): Add definition. (STACK_CHECK_PROTECT): Use conditional expression instead of heavier to read conditioned macro definitions. libgcc/ * config.host: Adjust the ix86/x86_64-wrs-vxworks filters to apply to VxWorks 7 as well. Co-authored-by: Douglas Rupp <rupp@adacore.com> Co-authored-by: Pat Bernardi <bernardi@adacore.com>
2020-10-30openmp: Fix handling of allocate clause on taskloopJakub Jelinek2-5/+88
This patch fixes gimplification of allocate clause on taskloop - puts allocate on inner taskloop only if there is allocate clause, because otherwise the data sharing clauses are only on the task construct in the construct sandwich. 2020-10-30 Jakub Jelinek <jakub@redhat.com> * gimplify.c (gimplify_scan_omp_clauses): Force OMP_CLAUSE_ALLOCATE_ALLOCATOR into a temporary if it is non-NULL and non-constant. (gimplify_omp_for): Only put allocate on inner taskloop if lastprivate for the same variable is going to be put there, and in that case if the OMP_CLAUSE_ALLOCATE_ALLOCATOR is non-NULL non-constant, make the allocator firstprivate on task. * c-c++-common/gomp/allocate-3.c: New test.
2020-10-30openmp: Handle non-static data members in allocate clause and other C++ ↵Jakub Jelinek4-13/+117
allocate fixes This allows specification of non-static data members in allocate clause like it can be specified in other privatization clauses and adds a new testcase that covers also handling of that clause in templates. 2020-10-30 Jakub Jelinek <jakub@redhat.com> * semantics.c (finish_omp_clauses) <case OMP_CLAUSE_ALLOCATE>: Handle non-static members in methods. * pt.c (tsubst_omp_clauses): Handle OMP_CLAUSE_ALLOCATE. * c-c++-common/gomp/allocate-1.c (qux): Add another test. * g++.dg/gomp/allocate-1.C: New test.
2020-10-30Adjust gcc.dg/vect/bb-slp-pr65935.cRichard Biener1-1/+1
This adjusts the testcase to allow splitting up the group for larger vector sizes and thus printing the splat message multiple times. 2020-10-30 Richard Biener <rguenther@suse.de> * gcc.dg/vect/bb-slp-pr65935.c: Adjust.
2020-10-29PowerPC: Adjust float128/ibm128 warnings.Michael Meissner4-26/+55
This patch ccombines two patches: 1) If GLIBC is 2.32 or newer, and the language is C or C++, allow the user to change the long double type without having to use -Wno-psabi. 2) Adjust the warnings for intermixing __float128 and __ibm128 to accomidate the future change to allow long double to use the IEEE 128-bit format. gcc/ 2020-10-29 Michael Meissner <meissner@linux.ibm.com> * config/rs6000/rs6000.c (rs6000_option_override_internal): Allow long double type to be changed for C/C++ if glibc 2.32 or newer. (rs6000_invalid_binary_op): Update error messages about mixing IBM long double and IEEE 128-bit. gcc/testsuite/ 2020-10-27 Michael Meissner <meissner@linux.ibm.com> * gcc.target/powerpc/float128-mix-2.c: New test. * gcc.target/powerpc/float128-mix-3.c: New test. * gcc.target/powerpc/float128-mix.c: Update failure messages.
2020-10-30Daily bump.GCC Administrator5-1/+363
2020-10-29c++: Implement CWG 625: Use of auto as template-arg [PR97479]Marek Polacek7-17/+46
This patch implements CWG 625 which prohibits using auto in a template argument. A few tests used this construction. Since this usage was allowed by the Concepts TS, we only give an error in C++20. gcc/cp/ChangeLog: DR 625 PR c++/97479 * parser.c (cp_parser_type_id_1): Reject using auto as a template-argument in C++20. gcc/testsuite/ChangeLog: DR 625 PR c++/97479 * g++.dg/cpp0x/auto3.C: Update dg-error. * g++.dg/cpp0x/auto9.C: Likewise. * g++.dg/cpp2a/concepts-pr84979-2.C: Likewise. * g++.dg/cpp2a/concepts-pr84979-3.C: Likewise. * g++.dg/cpp2a/concepts-pr84979.C: Likewise. * g++.dg/DRs/dr625.C: New test.
2020-10-29Replace free with XDELETE.Asher Gordon1-5/+5
gcc/c/ChangeLog: * c-typeck.c (free_all_tagged_tu_seen_up_to): Replace free with XDELETE. (finish_init): Likewise. (pop_init_level): Likewise.
2020-10-29c++: Deducing type from initializer_list<auto> [PR93107]Marek Polacek2-1/+29
In this testcase we weren't able to deduce b's type: template<typename T> void Task() { } auto b = { &Task<int> }; because resolve_nondeduced_context doesn't iterate on the {}'s elements. So make sure to look into {} too. We don't need to handle nested {} here. We could either tweak resolve_nondeduced_context to handle CONSTRUCTORs or add a _ctor version, but then resolve_nondeduced_context_or_error would need some changes too -- it'd have to check the result of a call to r_n_c for each element. gcc/cp/ChangeLog: PR c++/93107 * pt.c (do_auto_deduction): Call resolve_nondeduced_context for the elements of a { } list. gcc/testsuite/ChangeLog: PR c++/93107 * g++.dg/cpp0x/initlist-deduce3.C: New test.
2020-10-29c++: Reject float <=> enum.Marek Polacek3-5/+34
As [depr.arith.conv.enum] says, these are ill-formed. gcc/cp/ChangeLog: * typeck.c (do_warn_enum_conversions): Don't warn for SPACESHIP_EXPR. (cp_build_binary_op): Reject float <=> enum or enum <=> float. Use CP_INTEGRAL_TYPE_P instead of INTEGRAL_OR_ENUMERATION_TYPE_P. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/enum-conv1.C: Remove unused code. * g++.dg/cpp2a/spaceship-err5.C: New test.
2020-10-29c++: Simplify constraint normalization routinesPatrick Palka3-54/+24
Many of the high-level constraint normalization routines allow the caller to supply the initial template arguments for normalization, but in practice all of the callers supply something equivalent to the identity mapping(*). This patch hard-codes this prevalent choice of initial template arguments by making get_normalized_constraints always pass NULL_TREE as the args to normalize_expression. This admits some simplifications in the high-level routines, such as removing their 'args' parameter and consolidating the two versions of normalize_constraint_expression. (*): In particular, a set of generic template arguments or NULL_TREE. In the case of the two-parm version of normalize_constraint_expression, we were suspiciously using the template arguments of a concept-id when normalizing the concept-id as a constraint-expression. gcc/cp/ChangeLog: * constraint.cc (get_normalized_constraints): Remove 'args' parameter. Pass NULL_TREE as the initial template arguments to normalize_expression. (get_normalized_constraints_from_info): Remove 'args' parameter and adjust the call to get_normalized_constraints. (get_normalized_constraints_from_decl): Remove 'args' local variable and adjust call to get_normalized_constraints_from_info. (normalize_concept_definition): Remove 'args' local variable and adjust call to get_normalized_constraints. (normalize_constraint_expression): Remove the two-parameter overload. Remove 'args' parameter from the three-parameter overload and update function comment accordingly. Remove default argument from 'diag' parameter. Adjust call to get_normalized_constraints. (finish_nested_requirement): Adjust call to normalize_constraint_expression. (strictly_subsumes): Remove 'args' parameter. Adjust call to get_normalized_constraints_from_info. (weakly_subsumes): Likewise. * cp-tree.h (strictly_subsumes): Remove 'args' parameter. (weakly_subsumes): Likewise. * pt.c (process_partial_specialization): Adjust call to strictly_subsumes. (is_compatible_template_arg): Adjust call to weakly_subsumes.
2020-10-29c++: Tolerate empty initial args during normalization [PR97412]Patrick Palka2-1/+14
When normalizing the constraint-expression of a nested-requirement, we pass NULL_TREE as the initial template arguments for normalization, but tsubst_argument_pack is not prepared to handle a NULL_TREE args vector. This causes us to ICE when normalizing a variadic concept as part of a nested-requirement. This patch fixes the ICE by guarding the call to tsubst_template_args in normalize_concept_check appropriately. This will also enable us to simplify many of the normalization routines to just pass NULL_TREE (instead of a set of generic template arguments) as the initial template arguments. gcc/cp/ChangeLog: PR c++/97412 * constraint.cc (normalize_concept_check): Don't call tsubst_template_args when 'args' is NULL. gcc/testsuite/ChangeLog: PR c++/97412 * g++.dg/cpp2a/concepts-variadic2.C: New test.
2020-10-29Fix some memleaksRichard Biener2-2/+5
This fixes some memleaks, one older, one recently introduced. 2020-10-29 Richard Biener <rguenther@suse.de> * tree-ssa-pre.c (compute_avail): Free operands consistently. * tree-vect-loop.c (vectorizable_phi): Make sure all operand defs vectors are released.
2020-10-29c++: Fix constexpr cleanup error handling.Jason Merrill2-6/+23
In this testcase, the primary evaluation successfully produces 'true', and then running one of the cleanups hits a double delete, making the whole thing not a valid constant expression. So we were returning 'true' wrapped in a NOP_EXPR to indicate its non-constancy, but evaluating that again is a perfectly acceptable constant expression, so we weren't getting the verbose diagnostic we were looking for. So if non_constant_p gets set other than for overflow, go back to the original expression. With this change, we should never hit the manifestly_const_eval test, and the is-constant-evaluated1.C test passes without it. gcc/cp/ChangeLog: PR c++/97388 * constexpr.c (cxx_eval_outermost_constant_expr): Revert to original expression if evaluation sets non_constant_p. gcc/testsuite/ChangeLog: PR c++/97388 * g++.dg/cpp2a/constexpr-dtor8.C: New test.
2020-10-29c++: Fix constexpr dtors vs invisible ref [PR97388]Jakub Jelinek4-7/+102
For arguments passed by invisible reference, in the IL until genericization we have the source types on the callee side and while on the caller side we already pass references to the actual argument slot in the caller, we undo that in cxx_bind_parameters_in_call's if (TREE_ADDRESSABLE (type)) /* Undo convert_for_arg_passing work here. */ x = convert_from_reference (x); This works fine most of the time, except when the type also has constexpr destructor; in that case the destructor is invoked in the caller and thus the unsharing we do to make sure that the callee doesn't modify caller's values is in that case undesirable, it prevents the changes done in the callee propagating to the caller which should see them for the constexpr dtor evaluation. The following patch fixes that. While it could be perhaps done for all TREE_ADDRESSABLE types, I don't see the need to change the behavior if there is no constexpr non-trivial dtor. Jason: And we need to avoid memoizing the call, because a later equivalent call also needs to modify its argument. And we don't need to unshare constructors when we aren't memoizing the call, because we already unshared them when evaluating the TARGET_EXPR representing the copy-initialization of the argument. 2020-10-20 Jakub Jelinek <jakub@redhat.com> Jason Merrill <jason@redhat.com> PR c++/97388 * constexpr.c (cxx_bind_parameters_in_call): Set non_constant_args if the parameter type has a non-trivial destructor. (cxx_eval_call_expression): Only unshare arguments if we're memoizing this evaluation. * g++.dg/cpp2a/constexpr-dtor5.C: New test. * g++.dg/cpp2a/constexpr-dtor6.C: New test. * g++.dg/cpp2a/constexpr-dtor7.C: New test.
2020-10-29Annotate vec::copy better for mem statsJan Hubicka1-1/+1
* vec.h (vec<T, va_heap, vl_ptr>::copy): Pass mem stat info.
2020-10-29Avoid typeless storage in wide-intJan Hubicka1-4/+6
* wide-int.h (trailing_wide_ints <N>): Turn len to array of structures so it does not imply typeless storage. (trailing_wide_ints <N>::operator): update (trailing_wide_ints <N>::operator []): Update.
2020-10-29c++: Diagnose constexpr delete [] new int; and delete new int[N]; [PR95808]Jakub Jelinek4-5/+80
This patch diagnoses delete [] new int; and delete new int[1]; in constexpr contexts by remembering IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun)) & OVL_OP_FLAG_VEC from the operator new and checking it at operator delete time. 2020-10-29 Jakub Jelinek <jakub@redhat.com> PR c++/95808 * cp-tree.h (enum cp_tree_index): Add CPTI_HEAP_VEC_UNINIT_IDENTIFIER and CPTI_HEAP_VEC_IDENTIFIER. (heap_vec_uninit_identifier, heap_vec_identifier): Define. * decl.c (initialize_predefined_identifiers): Initialize those identifiers. * constexpr.c (cxx_eval_call_expression): Reject array allocations deallocated with non-array deallocation or non-array allocations deallocated with array deallocation. (non_const_var_error): Handle heap_vec_uninit_identifier and heap_vec_identifier too. (cxx_eval_constant_expression): Handle also heap_vec_uninit_identifier and in that case during initialization replace it with heap_vec_identifier. (find_heap_var_refs): Handle heap_vec_uninit_identifier and heap_vec_identifier too. * g++.dg/cpp2a/constexpr-new15.C: New test.
2020-10-29stdbool.h: Update true and false expansions for C2xJoseph Myers4-0/+151
C2x has changed the expansions of the true and false macros in <stdbool.h> so that they have type _Bool (including in #if conditions, i.e. an unsigned type in that context). Use the new expansions in GCC's <stdbool.h> for C2x. See bug 82272 for related discussion (but this patch does *not* implement the warning discussed there). Note that it's possible there may be a further change to make bool, true and false keywords (there was support in principle for that at the April WG14 meeting). But currently these expansions of type _Bool are what C2x requires and there isn't actually a paper before WG14 at present that would introduce the new keywords. Bootstrapped with no regressions on x86_64-pc-linux-gnu. gcc/ 2020-10-29 Joseph Myers <joseph@codesourcery.com> * ginclude/stdbool.h [__STDC_VERSION__ > 201710L] (true, false): Define with type _Bool. gcc/testsuite/ 2020-10-29 Joseph Myers <joseph@codesourcery.com> * gcc.dg/c11-bool-1.c, gcc.dg/c2x-bool-1.c, gcc.dg/c99-bool-4.c: New tests.
2020-10-29Selectively trap if ranger and vr-values disagree on range builtins.Aldy Hernandez1-3/+6
The UBSAN builtins degrade into PLUS/MINUS/MULT and call extract_range_from_binary_expr, which as the PR shows, can special case some symbolics which the ranger doesn't currently handle. Looking at vr_values::extract_range_builtin(), I see that every single place where we ask for a range, we bail on non-integers (symbolics, etc). That is, with the exception of the UBSAN builtins. Since this seems to be particular to UBSAN, we could still go with the original plan of removing the duplicity in ranger vs vr-values, but leave in the UBSAN builtin handling. This isn't ideal, as we'd like to remove all the common code, but I'd be willing to put up with UBSAN duplication for the time being. This patch disables the assert on the UBSAN builtins, while still trapping if any other differences are found between the vr_values and the ranger versions of builtin range handling. As a follow-up, once Fedora can test this approach, I'll remove all the builtin code from extract_range_builtin, with the exception of the UBSAN stuff (renaming it to extract_range_ubsan_builtin). Since the builtin code has proven fickle across architectures, I've tested this with {-m32,-m64,-fsanitize=signed-integer-overflow} on x86, ppc64le, and aarch64. I think this should be enough. If it isn't, we can revert the patch, and leave the duplicate code until the next release cycle when hopefully vr_values, evrp, and friends will all be overhauled. gcc/ChangeLog: PR tree-optimization/97505 * vr-values.c (vr_values::extract_range_basic): Enable trap again for everything except UBSAN builtins.
2020-10-29 * gcc.dg/pr97596.c: Require int128 effective target.Jakub Jelinek1-1/+1
2020-10-29Add testcase for PR97596Andrew MacLeod1-0/+12
Add testcase gcc/testsuite * gcc.dg/pr97596.c: New.
2020-10-29c++: Stop (most) function-scope entities having a template headerNathan Sidwell1-63/+80
Currently push_template_decl (mostly) decides whether to add a template header to an entity by seeing if it has DECL_LANG_SPECIFIC. That might have been a useful predicate at one time, but basing semantic implications on how we've decided to represent decls is bound to be brittle. And indeed it is, as more decls grow a use for lang-specific. In particular I discovered that function-scope VAR_DECLs couild grow lang-specific, and thereby get a template header. There's no need for that, and it breaks an invariant modules was expected. This patch changes that, and bases the descision on the properties of the decl. In particular the only function-scope decl that gets a template header is an implicit-typedef. I also cleaned up the behaviour of it building a template-info only to ignore it. gcc/cp/ * pt.c (push_template_decl): Do not give function-scope entities other than implicit typedefs a template header. Do not readd template info to a redeclared template.
2020-10-29vect: Fix load costs for SLP permutesRichard Sandiford3-31/+43
For the following test case (compiled with load/store lanes disabled locally): void f (uint32_t *restrict x, uint8_t *restrict y, int n) { for (int i = 0; i < n; ++i) { x[i * 2] = x[i * 2] + y[i * 2]; x[i * 2 + 1] = x[i * 2 + 1] + y[i * 2]; } } we have a redundant no-op permute on the x[] load node: node 0x4472350 (max_nunits=8, refcnt=2) stmt 0 _5 = *_4; stmt 1 _13 = *_12; load permutation { 0 1 } Then, when costing it, we pick a cost of 1, even though we need 4 copies of the x[] load to match a single y[] load: ==> examining statement: _5 = *_4; Vectorizing an unaligned access. vect_model_load_cost: unaligned supported by hardware. vect_model_load_cost: inside_cost = 1, prologue_cost = 0 . The problem is that the code only considers the permutation for the first scalar iteration, rather than for all VF iterations. This patch tries to fix that by making vect_transform_slp_perm_load calculate the value instead. gcc/ * tree-vectorizer.h (vect_transform_slp_perm_load): Take an optional extra parameter. * tree-vect-slp.c (vect_transform_slp_perm_load): Calculate the number of loads as well as the number of permutes, taking the counting loop from... * tree-vect-stmts.c (vect_model_load_cost): ...here. Use the value computed by vect_transform_slp_perm_load for ncopies.
2020-10-29LTO: get_section: add new argumentMartin Liska5-26/+14
gcc/ChangeLog: PR lto/97508 * langhooks.c (lhd_begin_section): Call get_section with not_existing = true. * output.h (get_section): Add new argument. * varasm.c (get_section): Fail when NOT_EXISTING is true and a section already exists. * ipa-cp.c (ipcp_write_summary): Remove. (ipcp_read_summary): Likewise. * ipa-fnsummary.c (ipa_fn_summary_read): Always read jump functions summary. (ipa_fn_summary_write): Always stream it.
2020-10-29Consistently pass the vector type for scalar SLP cost computeRichard Biener1-1/+2
This avoids randomly (based on whether the stmt is SLP_TREE_REPRESENTATIVE and not a pattern stmt) passing a vector type or NULL to the add_stmt_cost hook for scalar code cost compute. For example the x86 backend uses only the vector type to decide on the scalar computation mode which makes costing off. So the following explicitely passes the vector type and uses SLP_TREE_VECTYPE for this purpose. 2020-10-29 Richard Biener <rguenther@suse.de> * tree-vect-slp.c (vect_bb_slp_scalar_cost): Pass SLP_TREE_VECTYPE to record_stmt_cost.
2020-10-29opts: Sanity check for param names.Martin Liska2-1/+4
gcc/ChangeLog: * optc-gen.awk: Check that params start with -param=. * params.opt: Fix ipa-jump-function-lookups.
2020-10-29CSE conversions within sincosAlexandre Oliva4-1/+165
On platforms in which Aux_[Real_Type] involves non-NOP conversions (e.g., between single- and double-precision, or between short float and float), the conversions before the calls are CSEd too late for sincos to combine calls. This patch enables the sincos pass to CSE type casts used as arguments to eligible calls before looking for other calls using the same operand. for gcc/ChangeLog * tree-ssa-math-opts.c (sincos_stats): Add conv_removed. (execute_cse_conv_1): New. (execute_cse_sincos_1): Call it. Fix return within FOR_EACH_IMM_USE_STMT. (pass_cse_sincos::execute): Report conv_inserted. for gcc/testsuite/ChangeLog * gnat.dg/sin_cos.ads: New. * gnat.dg/sin_cos.adb: New. * gcc.dg/sin_cos.c: New.
2020-10-29Enable GCC to support Intel Key Locker ISAliuhongt37-33/+1129
gcc/ChangeLog 2018-12-15 Xuepeng Guo <xuepeng.guo@intel.com> Hongyu Wang <hongyu.wang@intel.com> Hongtao Liu <hongtao.liu@intel.com> * common/config/i386/cpuinfo.h (get_available_features): Detect KL, AESKLE and WIDEKL features. * common/config/i386/i386-common.c (OPTION_MASK_ISA_KL_SET): New. (OPTION_MASK_ISA_WIDEKL_SET): Likewise. (OPTION_MASK_ISA_KL_UNSET): Likewise. (OPTION_MASK_ISA_WIDEKL_UNSET): Likewise. (OPTION_MASK_ISA2_AVX2_UNSET): Likewise. (OPTION_MASK_ISA2_AVX_UNSET): Likewise. (OPTION_MASK_ISA2_SSE4_2_UNSET): Likewise. (OPTION_MASK_ISA2_SSE4_1_UNSET): Likewise. (OPTION_MASK_ISA2_SSE4_UNSET): Likewise. (OPTION_MASK_ISA2_SSSE3_UNSET): Likewise. (OPTION_MASK_ISA2_SSE3_UNSET): Likewise. (OPTION_MASK_ISA2_SSE2_UNSET): Likewise. (OPTION_MASK_ISA2_SSE_UNSET): Likewise. (ix86_handle_option): Handle kl and widekl, add dependency chain for KL and SSE2. * common/config/i386/i386-cpuinfo.h (enum processor_features): (FEATURE_KL, FEATURE_AESKLE, FEATURE_WIDEKL): New. * common/config/i386/i386-isas.h: Add ISA_NAMES_TABLE_ENTRY for KL, AESKLE and WIDEKL. * config.gcc: Add keylockerintrin.h. * doc/invoke.texi: Document new option -mkl and -mwidekl. * doc/extend.texi: Document kl and widekl. * config/i386/cpuid.h (bit_KL, bit_AESKLE, bit_WIDEKL): New. * config/i386/i386-builtin-types.def ((UINT, UINT, V2DI, V2DI, PVOID), (UINT, UINT, V2DI, PVOID), (VOID, V2DI, V2DI, V2DI, UINT), (UINT8, PV2DI, V2DI, PCVOID), (UINT8, PV2DI, PCV2DI, PCVOID)): New function types. * config/i386/i386-builtin.def: Add __builtin_ia32_loadiwkey, __builtin_ia32_aesdec128kl_u8, __builtin_ia32_aesdec256kl_u8, __builtin_ia32_aesenc128kl_u8, __builtin_ia32_aesenc256kl_u8, __builtin_ia32_aesdecwide128kl_u8, __builtin_ia32_aesdecwide256kl_u8, __builtin_ia32_aesencwide128kl_u8, __builtin_ia32_aesencwide256kl_u8, __builtin_ia32_encodekey128_u32, __builtin_ia32_encodekey256_u32. * config/i386/i386-c.c (ix86_target_macros_internal): Handle kl and widekl. * config/i386/i386-options.c (isa2_opts): Add -mkl and -mwidekl. (ix86_option_override_internal): Handle KL and WIDEKL. (ix86_valid_target_attribute_inner_p): Add attribute for kl and widekl. * config/i386/i386-expand.c (ix86_expand_builtin): Expand Keylocker Builtins. * config/i386/i386.h (TARGET_KL): New. (TARGET_KL_P): Likewise. (TARGET_WIDEKL): Likewise. (TARGET_WIDEKL_P): Likewise. (PTA_KL): Likewise. (PTA_WIDEKL): Likewise. (PTA_TIGERLAKE): Add PTA_KL, PTA_WIDEKL. (PTA_ALDERLAKE): Likewise. * config/i386/i386.opt: Add new option mkl and mwidekl. * config/i386/keylockerintrin.h: New header file for Keylocker. * config/i386/immintrin.h: Include keylockerintrin.h. * config/i386/predicates.md (encodekey128_operation): New predicate. (encodekey256_operation): Likewise. (aeswidekl_operation): Likewise. * config/i386/sse.md (UNSPECV_LOADIWKEY): New. (UNSPECV_AESDEC128KLU8): Likewise. (UNSPECV_AESENC128KLU8): Likewise. (UNSPECV_AESDEC256KLU8): Likewise. (UNSPECV_AESENC256KLU8): Likewise. (UNSPECV_AESDECWIDE128KLU8): Likewise. (UNSPECV_AESENCWIDE128KLU8): Likewise. (UNSPECV_AESDECWIDE256KLU8): Likewise. (UNSPECV_AESENCWIDE256KLU8): Likewise. (UNSPECV_ENCODEKEY128U32): Likewise. (UNSPECV_ENCODEKEY256U32): Likewise. (encodekey128u32): New expander. (encodekey256u32): Likewise. (aes<aeswideklvariant>u8): Likewise. (loadiwkey): New insn pattern. (*encodekey128u32): Likewise. (*encodekey256u32): Likewise. (aes<aesklvariant>u8): Likewise. (*aes<aeswideklvariant>u8): Likewise. gcc/testsuite/ChangeLog * gcc.target/i386/keylocker-aesdec128kl.c: New test. * gcc.target/i386/keylocker-aesdec256kl.c: Likewise. * gcc.target/i386/keylocker-aesdecwide128kl.c: Likewise. * gcc.target/i386/keylocker-aesdecwide256kl.c: Likewise. * gcc.target/i386/keylocker-aesenc128kl.c: Likewise. * gcc.target/i386/keylocker-aesencwide128kl.c: Likewise. * gcc.target/i386/keylocker-aesencwide256kl.c: Likewise. * gcc.target/i386/keylocker-encodekey128.c: Likewise. * gcc.target/i386/keylocker-encodekey256.c: Likewise. * gcc.target/i386/keylocker-loadiwkey.c: Likewise. * g++.dg/other/i386-2.C: Add -mkl and -mwidekl. * g++.dg/other/i386-3.C: Likewise. * gcc.target/i386/sse-12.c: Likewise. * gcc.target/i386/sse-13.c: Likewise. * gcc.target/i386/sse-14.c: Likewise. * gcc.target/i386/sse-22.c: Add kl and widekl. * gcc.target/i386/sse-23.c: Likewise. * gcc.target/i386/funcspec-56.inc: Add new target attribute test.
2020-10-29More BB vectorization tweaksRichard Biener2-6/+9
This tweaks the op build from splats to allow loads marked as not vectorizable. It also amends some dump prints with the address of the SLP node or the instance to better be able to debug things. 2020-10-29 Richard Biener <rguenther@suse.de> * tree-vect-slp.c (vect_build_slp_tree_2): Allow splatting not vectorizable loads. (vect_build_slp_instance): Amend dumping with address. (vect_slp_convert_to_external): Likewise. * gcc.dg/vect/bb-slp-pr65935.c: Adjust.
2020-10-28Call infer_non_null() directly when checking for non-null.Andrew MacLeod2-8/+50
Simply call infer_non_null directly and avoid uneccessary checks of the statement being modified. gcc/ PR tree-optimization/97609 * gimple-range-cache.cc (non_null_ref::process_name): Call infer_nonnull_range directly instead of infer_value_range. gcc/testsuite/ * g++.dg/pr97609.C: New.
2020-10-28libgo: handle linking to NetBSD's versioned symbolsNikhil Benesch1-1/+1
On NetBSD, for backwards compatibility, various libc symbols are renamed to a symbol with a version suffix. For example, this is the (abbreviated) definition of sigaction: int sigaction(...) __asm__ ("__sigaction14") This poses a challenge for libgo, which attempts to link sigaction by way of an "//extern" comment: //extern sigaction func sigaction(...) This results in a reference to the deprecated compatibility symbol "sigaction", rather than the desired "__sigaction14" symbol. This patch introduces a new "//extern-sysinfo" comment to handle this situation. The new mklinknames.awk script scans a package for these comments and outputs a "//go:linkname" directive that links the wrapper to the correct versioned symbol, as determined by parsing the __asm__ annotation on the function's declaration in gen-sysinfo.go. For now, only the following packages are scanned by mklinknames.awk: os os/user runtime syscall gotools/: * Makefile.am (check-runtime): Add runtime_linknames.go to --extrafiles. * Makefile.in: Regenerate. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/265125
2020-10-29Daily bump.GCC Administrator9-1/+517
2020-10-28analyzer: more non-determinism fixesDavid Malcolm2-4/+32
gcc/analyzer/ChangeLog: * program-state.cc (sm_state_map::on_liveness_change): Sort the leaking svalues before calling on_state_leak. (program_state::detect_leaks): Likewise when calling on_svalue_leak. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Likewise when calling on_escaped_function.
2020-10-28analyzer: fix false leak diagnostic on offsets from malloc [PR97608]David Malcolm3-0/+59
gcc/analyzer/ChangeLog: PR analyzer/97608 * region-model-reachability.cc (reachable_regions::handle_sval): Operands of reachable reversible operations are reachable. gcc/testsuite/ChangeLog: PR analyzer/97608 * gcc.dg/analyzer/malloc-1.c (test_42d): New. * gcc.dg/analyzer/pr97608.c: New test.
2020-10-28analyzer: move svalue and region decls to their own header filesDavid Malcolm9-2162/+2332
gcc/ChangeLog: * Makefile.in (ANALYZER_OBJS): Add analyzer/complexity.o. gcc/analyzer/ChangeLog: * analyzer.h (class state_machine): New forward decl. (class logger): Likewise. (class visitor): Likewise. * complexity.cc: New file, taken from svalue.cc. * complexity.h: New file, taken from region-model.h. * region-model.h: Include "analyzer/svalue.h" and "analyzer/region.h". Move struct complexity to complexity.h. Move svalue, its subclasses and supporting decls to svalue.h. Move region, its subclasses and supporting decls to region.h. * region.cc: Include "analyzer/region.h". (symbolic_region::symbolic_region): Move here from region-model.h. * region.h: New file, based on material from region-model.h. * svalue.cc: Include "analyzer/svalue.h". (complexity::complexity): Move to complexity.cc. (complexity::from_pair): Likewise. * svalue.h: New file, based on material from region-model.h.
2020-10-28analyzer: fix more pointer-printing in logsDavid Malcolm2-5/+11
gcc/analyzer/ChangeLog: * program-state.cc (sm_state_map::print): Guard the printing of the origin pointer with !flag_dump_noaddr. * region.cc (string_region::dump_to_pp): Likewise for m_string_cst.
2020-10-29[RS6000] Don't be too clever with dg-do run and dg-do compileAlan Modra10-20/+28
Otherwise some versions of dejagnu go ahead and run the vsx tests below when they should not. To best cope with older dejagnu, put "run" before "compile", the idea being that if the second dg-do always wins then that won't cause fails. The altivec tests also need -save-temps for the scan-assembler test to occur when vms_hw. * gcc.target/powerpc/vsx-load-element-extend-char.c: Put "dg-do run" before "dg-do compile", and make them mutually exclusive. * gcc.target/powerpc/vsx-load-element-extend-int.c: Likewise. * gcc.target/powerpc/vsx-load-element-extend-longlong.c: Likewise. * gcc.target/powerpc/vsx-load-element-extend-short.c: Likewise. * gcc.target/powerpc/vsx-store-element-truncate-char.c: Likewise. * gcc.target/powerpc/vsx-store-element-truncate-int.c: Likewise. * gcc.target/powerpc/vsx-store-element-truncate-longlong.c: Likewise. * gcc.target/powerpc/vsx-store-element-truncate-short.c: Likewise. * gcc.target/powerpc/altivec-consts.c: Likewise, add -save-temps. * gcc.target/powerpc/le-altivec-consts.c: Likewise.
2020-10-29[RS6000] float128-type-2.c unsupportedAlan Modra2-2/+2
I noticed this test is unsupported on power10 when looking through test logs. There seems no reason why that should be the case, ie. the target test was meant to be powerpc64*-*-linux*. And that simplifies down further. * gcc.target/powerpc/float128-type-1.c: Simplify target test. * gcc.target/powerpc/float128-type-2.c: Likewise.
2020-10-29Re: testsuite: Enable and adjust powerpc fold-vec-extract/insert testcasesAlan Modra5-6/+0
git commit badeac77f552 changed expected number of addi instructions, causing these fails on powerpc-linux. gcc.target/powerpc/fold-vec-insert-int-p9.c: \\maddi\\M found 12 times FAIL: gcc.target/powerpc/fold-vec-insert-int-p9.c scan-assembler-times \\maddi\\M 8 gcc.target/powerpc/fold-vec-extract-char.p9.c: addi found 6 times FAIL: gcc.target/powerpc/fold-vec-extract-char.p9.c scan-assembler-times addi 3 gcc.target/powerpc/fold-vec-extract-int.p9.c: \\maddi\\M found 6 times FAIL: gcc.target/powerpc/fold-vec-extract-int.p9.c scan-assembler-times \\maddi\\M 3 gcc.target/powerpc/fold-vec-extract-longlong.p7.c: \\maddi\\M found 6 times FAIL: gcc.target/powerpc/fold-vec-extract-longlong.p7.c scan-assembler-times \\maddi\\M 4 gcc.target/powerpc/fold-vec-extract-longlong.p8.c: \\maddi\\M found 6 times FAIL: gcc.target/powerpc/fold-vec-extract-longlong.p8.c scan-assembler-times \\maddi\\M 4 changed by badeac77f552 I'm not at all sure why we are counting addi. On linux I see eight in fold-vec-insert-int-p9.c tearing down the stack frame in function epilogues, and four in addi 9,1,16 lvewx 0,0,9 For aix you have the above four but with a -16 offset. There are no stack frames, and you have four addressing stack red-zone as addi 9,1,-64 fold-vec-extract-char.p9.c on linux just has epilogue addi, aix has red-zone addressing. The same for fold-vec-extract-int.p9.c, fold-vec-extract-longlong.p7.c and fold-vec-extract-longlong.p8.c. It seems silly to count addi in a function epilogue, and fragile to count them in code. So remove the ilp32 addi checks. * gcc.target/powerpc/fold-vec-extract-char.p9.c: Don't check addi count for ilp32. * gcc.target/powerpc/fold-vec-extract-int.p9.c: Likewise. * gcc.target/powerpc/fold-vec-extract-longlong.p7.c: Likewise. * gcc.target/powerpc/fold-vec-extract-longlong.p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-int-p9.c: Likewise.
2020-10-28c++: Improve the MVP -Wparentheses diagnostic.Marek Polacek3-3/+44
I noticed that declarator->parenthesized is, for this warning, only set to the opening paren. But we can easily make it a range and generate a nicer diagnostic. Moreover, we can then offer a fix-it hint. TL;DR: This patch changes mvp3.C:8:7: warning: unnecessary parentheses in declaration of ‘i’ [-Wparentheses] 8 | int (i); | ^ to mvp3.C:8:7: warning: unnecessary parentheses in declaration of ‘i’ [-Wparentheses] 8 | int (i); | ^~~ mvp3.C:8:7: note: remove parentheses 8 | int (i); | ^~~ | - - Tested by using -fdiagnostics-generate-patch and verifying that the generated patch DTRT. gcc/cp/ChangeLog: * decl.c (grokdeclarator): Offer a fix-it hint for the "unnecessary parentheses in declaration" warning. * parser.c (cp_parser_direct_declarator): When setting declarator->parenthesized, use a location range. gcc/testsuite/ChangeLog: * g++.dg/warn/mvp3.C: New test.
2020-10-28c++: Deprecate arithmetic convs on different enums [PR97573]Marek Polacek10-17/+549
I noticed that C++20 P1120R0 deprecated certain arithmetic conversions as outlined in [depr.arith.conv.enum], but we don't warn about them. In particular, "If one operand is of enumeration type and the other operand is of a different enumeration type or a floating-point type, this behavior is deprecated." These will likely become ill-formed in C++23, so we should warn by default in C++20. To this effect, this patch adds two new warnings (like clang++): -Wdeprecated-enum-enum-conversion and -Wdeprecated-enum-float-conversion. They are enabled by default in C++20. In older dialects, to enable these warnings you can now use -Wenum-conversion which I made available in C++ too. Note that unlike C, in C++ it is not enabled by -Wextra, because that breaks bootstrap. We already warn about comparisons of two different enumeration types via -Wenum-compare, the rest is handled in this patch: we're performing the usual arithmetic conversions in these contexts: - an arithmetic operation, - a bitwise operation, - a comparison, - a conditional operator, - a compound assign operator. Using the spaceship operator as enum <=> real_type is ill-formed but we don't reject it yet. We should also address [depr.array.comp] too, but it's not handled in this patch. gcc/c-family/ChangeLog: PR c++/97573 * c-opts.c (c_common_post_options): In C++20, turn on -Wdeprecated-enum-enum-conversion and -Wdeprecated-enum-float-conversion. * c.opt (Wdeprecated-enum-enum-conversion, Wdeprecated-enum-float-conversion): New options. (Wenum-conversion): Allow for C++ too. gcc/cp/ChangeLog: PR c++/97573 * call.c (build_conditional_expr_1): Warn about the deprecated enum/real type conversion in C++20. Also warn about a non-enumerated and enumerated type in ?: when -Wenum-conversion is on. * typeck.c (do_warn_enum_conversions): New function. (cp_build_binary_op): Call it. gcc/ChangeLog: PR c++/97573 * doc/invoke.texi: Document -Wdeprecated-enum-enum-conversion and -Wdeprecated-enum-float-conversion. -Wenum-conversion is no longer C/ObjC only. gcc/testsuite/ChangeLog: PR c++/97573 * g++.dg/cpp0x/linkage2.C: Add dg-warning. * g++.dg/parse/attr3.C: Likewise. * g++.dg/cpp2a/enum-conv1.C: New test. * g++.dg/cpp2a/enum-conv2.C: New test. * g++.dg/cpp2a/enum-conv3.C: New test.
2020-10-28c++: Prevent warnings for value-dependent exprs [PR96742]Marek Polacek5-5/+31
Here, in r11-155, I changed the call to uses_template_parms to type_dependent_expression_p_push to avoid a crash in C++98 in value_dependent_expression_p on a non-constant expression. But that prompted a host of complaints that we now warn for value-dependent expressions in templates. Those warnings are technically valid, but people still don't want them because they're awkward to avoid. This patch uses value_dependent_expression_p or type_dependent_expression_p. But make sure that we don't ICE in value_dependent_expression_p by checking potential_constant_expression first. gcc/cp/ChangeLog: PR c++/96675 PR c++/96742 * pt.c (tsubst_copy_and_build): Call value_dependent_expression_p or type_dependent_expression_p instead of type_dependent_expression_p_push. But only call value_dependent_expression_p for expressions that are potential_constant_expression. gcc/testsuite/ChangeLog: PR c++/96675 PR c++/96742 * g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus. * g++.dg/warn/Wtautological-compare3.C: New test. * g++.dg/warn/Wtype-limits5.C: New test. * g++.old-deja/g++.pt/crash10.C: Remove dg-warning.
2020-10-28testsuite: Adjust target requirements for sad-vectorize and signbit.David Edelsohn7-11/+9
More testcases with incorrect target selectors. gcc/testsuite/ChangeLog: * gcc.target/powerpc/sad-vectorize-1.c: Remove AIX skip. * gcc.target/powerpc/sad-vectorize-2.c: Remove AIX skip. * gcc.target/powerpc/sad-vectorize-3.c: Remove target. Require p9vector_hw. * gcc.target/powerpc/sad-vectorize-4.c: Remove target. Require p9vector_hw. * gcc.target/powerpc/signbit-1.c: Remove target. Require ppc_float128_sw. * gcc.target/powerpc/signbit-2.c: Remove target. Require ppc_float128_sw. * gcc.target/powerpc/signbit-3.c: Remove target. Require ppc_float128_sw.
2020-10-28c++: Member template function lookup failure [PR94799]Marek Polacek2-7/+29
My earlier patch for this PR, r11-86, broke pybind11. That patch changed cp_parser_class_name to also consider the object expression scope (parser->context->object_type) to fix parsing of p->template A<T>::foo(); // consider p's scope too Here we reject b.operator typename B<T>::type(); because 'typename_p' in cp_parser_class_name uses 'scope', which means that 'typename_p' will be true for the example above. Then we create a TYPENAME_TYPE via make_typename_type, which fails when tsubsting it; the code basically created 'typename B::B' and then we complain that there is no member named 'B' in 'A<int>'. So, when deciding if we should create a TYPENAME_TYPE, don't consider the object_type scope, like we did pre-r11-86. gcc/cp/ChangeLog: PR c++/94799 * parser.c (cp_parser_class_name): Use parser->scope when setting typename_p. gcc/testsuite/ChangeLog: PR c++/94799 * g++.dg/template/lookup16.C: New test.
2020-10-28c++: GCC accepts junk before fold-expression [PR86773]Marek Polacek2-0/+15
Here we accept a bogus expression before a left fold: Recall that a fold expression looks like: fold-expression: ( cast-expression fold-operator ... ) ( ... fold-operator cast-expression ) ( cast-expression fold-operator ... fold-operator cast-expression ) but here we have ( cast-expression ... fold-operator cast-expression ) The best fix seems to just return error_mark_node when we know this code is invalid, and let the subsequent code report that a ) was expected. gcc/cp/ChangeLog: PR c++/86773 * parser.c (cp_parser_fold_expression): Return error_mark_node if a left fold is preceded by an expression. gcc/testsuite/ChangeLog: PR c++/86773 * g++.dg/cpp1z/fold12.C: New test.
2020-10-28syscall: don't build libcall_bsd.go on solarisIan Lance Taylor1-1/+1
This new file was based on master sources that are built for *BSD but not Solaris Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/266017
2020-10-28AArch64: Skip test for pr97535 on ILP32 since it can't express the range.Tamar Christina1-1/+1
I am excluding the test from ILP32 since the goal of the test is to test truncations of large numbers above INT_MAX. gcc/testsuite/ChangeLog: PR target/97535 * gcc.target/aarch64/pr97535.c: Exclude ILP32.
2020-10-28value-range: Give up on POLY_INT_CST ranges [PR97457]Richard Sandiford2-25/+20
This PR shows another problem with calculating value ranges for POLY_INT_CSTs. We have: ivtmp_76 = ASSERT_EXPR <ivtmp_60, ivtmp_60 > POLY_INT_CST [9, 4294967294]> where the VQ coefficient is unsigned but is effectively acting as a negative number. We wrongly give the POLY_INT_CST the range: [9, INT_MAX] and things go downhill from there: later iterations of the unrolled epilogue are wrongly removed as dead. I guess this is the final nail in the coffin for doing VRP on POLY_INT_CSTs. For other similarly exotic testcases we could have overflow for any coefficient, not just those that could be treated as contextually negative. Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we couldn't handle warn_strict_overflow properly. At this stage we're just recording a range that might or might not lead to strict-overflow assumptions later. It still feels like we should be able to do something here, but for now removing the code seems safest. It's also telling that there are no testsuite failures on SVE from doing this. gcc/ PR tree-optimization/97457 * value-range.cc (irange::set): Don't decay POLY_INT_CST ranges to integer ranges. gcc/testsuite/ PR tree-optimization/97457 * gcc.dg/vect/pr97457.c: New test.
generated by cgit v1.1 at 2025-04-04 02:52:58 +0000