aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-29c++: check DECL_INITIAL for constexprJason Merrill5-7/+10
We were overlooking non-potentially-constant bits in variable initializer because we didn't walk into DECL_INITIAL. gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1): Look into DECL_INITIAL. Use location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-local4.C: Expect error sooner. * g++.dg/cpp2a/consteval24.C: Likewise. * g++.dg/cpp2a/consteval7.C: Likewise. * g++.dg/cpp2a/inline-asm3.C: Likewise.
2022-09-29c++: fix class-valued ?: extensionJason Merrill2-3/+19
When the gimplifier encounters the same TARGET_EXPR twice, it evaluates TARGET_EXPR_INITIAL the first time and clears it so that the later evaluation is just the temporary. With this testcase, using the extension to treat an omitted middle operand as repeating the first operand, that led to doing a bitwise copy of the S(1) temporary on return rather than properly calling the copy constructor. We can't use S(1) to initialize the return value here anyway, because we need to materialize it into a temporary so we can convert it to bool and determine which arm we're evaluating. So let's just treat the middle operand as an xvalue. PR c++/93046 gcc/cp/ChangeLog: * call.cc (build_conditional_expr): For a?:c extension, treat a reused class prvalue as an xvalue. gcc/testsuite/ChangeLog: * g++.dg/ext/cond4.C: Add runtime test.
2022-09-29c++: reduce temporaries in ?:Jason Merrill2-1/+23
When the sides of ?: are class prvalues, we wrap the COND_EXPR in a TARGET_EXPR so that both sides will initialize the same temporary. But in this case we were stripping the outer TARGET_EXPR and conditionally creating different temporaries, unnecessarily using extra stack. The recently added TARGET_EXPR_NO_ELIDE flag avoids this. gcc/cp/ChangeLog: * call.cc (build_conditional_expr): Set TARGET_EXPR_NO_ELIDE on the outer TARGET_EXPR. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/cond-temp1.C: New test.
2022-09-29amdgcn: remove unused variableAndrew Stubbs1-2/+0
This was left over from a previous version of the SIMD clone patch. gcc/ChangeLog: * config/gcn/gcn.cc (gcn_simd_clone_compute_vecsize_and_simdlen): Remove unused elt_bits variable.
2022-09-29Comment about HAVE_INITFINI_ARRAY_SUPPORT in vxworks.hOlivier Hainque1-0/+5
Explain that we rely on compiler .c files to include auto-host.h before target configuration headers. 2022-09-29 Olivier Hainque <hainque@adacore.com> gcc/ * config/vxworks.h: Add comment on our use of HAVE_INITFINI_ARRAY_SUPPORT.
2022-09-29Add an mcmodel=large multilib for aarch64-vxworksOlivier Hainque1-0/+5
This makes good sense in general anyway, and in particular with forthcoming support for shared shared libraries, which will work for mrtp alone but not yet for mrtp+mcmodel=large. 2022-09-29 Olivier Hainque <hainque@adacore.com> gcc/ * config/aarch64/t-aarch64-vxworks: Request multilib variants for mcmodel=large.
2022-09-29Remove TARGET_FLOAT128_ENABLE_TYPE setting for VxWorksOlivier Hainque1-3/+4
We have, in vxworks.h: /* linux64.h enables this, not supported in vxWorks. */ #undef TARGET_FLOAT128_ENABLE_TYPE #define TARGET_FLOAT128_ENABLE_TYPE 0 We inherit linux64.h for a few reasons, but don't really support float128 for vxworks, so the setting made sense. Many tests rely on the linux default (1) though, so resetting is causing lots of failures on compilation tests that would pass otherwise. Not resetting lets users write code declaring floa128 objects but linking will typically fail at some point, so there's no real adverse effect. Bottom line is we don't have any particular incentive to alter the default, whatever the default, so better leave the parameter alone. 2022-09-29 Olivier Hainque <hainque@adacore.com> gcc/ * config/rs6000/vxworks.h (TARGET_FLOAT128_ENABLE_TYPE): Remove resetting to 0.
2022-09-29Robustify DWARF2_UNWIND_INFO handling in vx-common.hOlivier Hainque1-2/+5
This adjusts vx-common.h to #define DWARF2_UNWIND_INFO to 0 when ARM_UNWIND_INFO is set, preventing defaults.h from possibly setting DWARF2_UNWIND_INFO to 1 (as well) on its own afterwards if the macro isn't defined. 2022-09-29 Olivier Hainque <hainque@adacore.com> gcc/ * config/vx-common.h (DWARF2_UNWIND_INFO): #define to 0 when ARM_UNWIND_INFO is set.
2022-09-29OpenACC: whole struct vs. component mappings (PR107028)Julian Brown5-37/+268
This patch fixes an ICE when both a complete struct variable and components of that struct are mapped on the same directive for OpenACC, using a modified version of the scheme used for OpenMP in the following patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601558.html A new function has been added to make sure that the mapping kinds of the whole struct and the member access are compatible -- conservatively, so as not to copy more to/from the device than the user expects. This version of the patch uses a different method to detect duplicate clauses for OpenACC in oacc_resolve_clause_dependencies, and removes the now-redundant check in omp_accumulate_sibling_lists. (The latter check would no longer trigger when we map the whole struct on the same directive because the component-mapping clauses are now deleted before the check is executed.) 2022-09-28 Julian Brown <julian@codesourcery.com> gcc/ PR middle-end/107028 * gimplify.cc (omp_check_mapping_compatibility, oacc_resolve_clause_dependencies): New functions. (omp_accumulate_sibling_list): Remove redundant duplicate clause detection for OpenACC. (build_struct_sibling_lists): Skip deleted groups. Don't build sibling list for struct variables that are fully mapped on the same directive for OpenACC. (gimplify_scan_omp_clauses): Call oacc_resolve_clause_dependencies. gcc/testsuite/ PR middle-end/107028 * c-c++-common/goacc/struct-component-kind-1.c: New test. * g++.dg/goacc/pr107028-1.C: New test. * g++.dg/goacc/pr107028-2.C: New test. * gfortran.dg/goacc/mapping-tests-5.f90: New test.
2022-09-29c++: implement __remove_cv, __remove_reference and __remove_cvrefPatrick Palka13-5/+157
This implements builtins for std::remove_cv, std::remove_reference and std::remove_cvref using TRAIT_TYPE from the previous patch. gcc/c-family/ChangeLog: * c-common.cc (c_common_reswords): Add __remove_cv, __remove_reference and __remove_cvref. * c-common.h (enum rid): Add RID_REMOVE_CV, RID_REMOVE_REFERENCE and RID_REMOVE_CVREF. gcc/cp/ChangeLog: * constraint.cc (diagnose_trait_expr): Handle CPTK_REMOVE_CV, CPTK_REMOVE_REFERENCE and CPTK_REMOVE_CVREF. * cp-objcp-common.cc (names_builtin_p): Likewise. * cp-tree.h (enum cp_trait_kind): Add CPTK_REMOVE_CV, CPTK_REMOVE_REFERENCE and CPTK_REMOVE_CVREF. * cxx-pretty-print.cc (pp_cxx_trait): Handle CPTK_REMOVE_CV, CPTK_REMOVE_REFERENCE and CPTK_REMOVE_CVREF. * parser.cc (cp_keyword_starts_decl_specifier_p): Return true for RID_REMOVE_CV, RID_REMOVE_REFERENCE and RID_REMOVE_CVREF. (cp_parser_trait): Handle RID_REMOVE_CV, RID_REMOVE_REFERENCE and RID_REMOVE_CVREF. (cp_parser_simple_type_specifier): Likewise. * semantics.cc (finish_trait_type): Likewise. libstdc++-v3/ChangeLog: * include/bits/unique_ptr.h (unique_ptr<_Tp[], _Dp>): Remove __remove_cv and use __remove_cv_t instead. gcc/testsuite/ChangeLog: * g++.dg/ext/has-builtin-1.C: Test existence of __remove_cv, __remove_reference and __remove_cvref. * g++.dg/ext/remove_cv.C: New test. * g++.dg/ext/remove_reference.C: New test. * g++.dg/ext/remove_cvref.C: New test.
2022-09-29c++: introduce TRAIT_TYPE alongside TRAIT_EXPRPatrick Palka17-78/+197
We already have generic support for predicate-like traits that yield a boolean value via TRAIT_EXPR, but we lack the same support for traits that yield a type instead of a value. Such support would streamline implementing efficient builtins for the standard library type traits. To that end this patch implements a generic TRAIT_TYPE type alongside TRAIT_EXPR, and reimplements the existing UNDERLYING_TYPE builtin trait using this new TRAIT_TYPE. gcc/cp/ChangeLog: * cp-objcp-common.cc (cp_common_init_ts): Replace UNDERLYING_TYPE with TRAIT_TYPE. * cp-tree.def (TRAIT_TYPE): Define. (UNDERLYING_TYPE): Remove. * cp-tree.h (TRAIT_TYPE_KIND_RAW): Define. (TRAIT_TYPE_KIND): Define. (TRAIT_TYPE_TYPE1): Define. (TRAIT_TYPE_TYPE2): Define. (WILDCARD_TYPE_P): Return true for TRAIT_TYPE. (finish_trait_type): Declare. * cxx-pretty-print.cc (cxx_pretty_printer::primary_expression): Adjust after renaming pp_cxx_trait_expression. (cxx_pretty_printer::simple_type_specifier) <case TRAIT_TYPE>: New. (cxx_pretty_printer::type_id): Replace UNDERLYING_TYPE with TRAIT_TYPE. (pp_cxx_trait_expression): Rename to ... (pp_cxx_trait): ... this. Handle TRAIT_TYPE as well. Correct pretty printing of the trailing arguments. * cxx-pretty-print.h (pp_cxx_trait_expression): Rename to ... (pp_cxx_trait_type): ... this. * error.cc (dump_type) <case UNDERLYING_TYPE>: Remove. <case TRAIT_TYPE>: New. (dump_type_prefix): Replace UNDERLYING_WITH with TRAIT_TYPE. (dump_type_suffix): Likewise. * mangle.cc (write_type) <case UNDERLYING_TYPE>: Remove. <case TRAIT_TYPE>: New. * module.cc (trees_out::type_node) <case UNDERLYING_TYPE>: Remove. <case TRAIT_TYPE>: New. (trees_in::tree_node): Likewise. * parser.cc (cp_parser_primary_expression): Adjust after renaming cp_parser_trait_expr. (cp_parser_trait_expr): Rename to ... (cp_parser_trait): ... this. Call finish_trait_type for traits that yield a type. (cp_parser_simple_type_specifier): Adjust after renaming cp_parser_trait_expr. * pt.cc (for_each_template_parm_r) <case UNDERLYING_TYPE>: Remove. <case TRAIT_TYPE>: New. (tsubst): Likewise. (unify): Replace UNDERLYING_TYPE with TRAIT_TYPE. (dependent_type_p_r): Likewise. * semantics.cc (finish_underlying_type): Don't return UNDERLYING_TYPE anymore when processing_template_decl. (finish_trait_type): Define. * tree.cc (strip_typedefs) <case UNDERLYING_TYPE>: Remove. <case TRAIT_TYPE>: New. (cp_walk_subtrees): Likewise. * typeck.cc (structural_comptypes): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-59.C: Adjust expected error message. * g++.dg/ext/underlying_type7.C: Likewise. * g++.dg/ext/underlying_type13.C: New test. * g++.dg/ext/underlying_type14.C: New test.
2022-09-29libstdc++: Guard use of new built-in with __has_builtinJonathan Wakely1-1/+6
I forgot that non-GCC compilers don't have this built-in yet. For Clang we could do something like the check below (as described in P2255), but for now I'm just fixing the regression. #if __has_builtin((__reference_binds_to_temporary) bool _Dangle = __reference_binds_to_temporary(_Tp, _Res_t) && __and_<is_reference<_Tp>, __not_<is_reference<_Res_t>>, is_convertible<__remove_cvref_t<_Res_t>*, __remove_cvref_t<_Tp>*>>::value #endif libstdc++-v3/ChangeLog: * include/std/type_traits (__is_invocable_impl): Check __has_builtin(__reference_converts_from_temporary) before using built-in.
2022-09-29c++: import/export NTTP objectsNathan Sidwell5-0/+64
This adds smarts to the module machinery to handle NTTP object VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol table, streamed specially and recreated on stream in. gcc/cp/ PR c++/100616 * module.cc (enum tree_tag): Add tt_nttp_var. (trees_out::decl_node): Handle NTTP objects. (trees_in::tree_node): Handle tt_nttp_var. (depset::hash::add_binding_entry): Skip NTTP objects. gcc/testsuite/ PR c++/100616 * g++.dg/modules/100616_a.H: New. * g++.dg/modules/100616_b.C: New. * g++.dg/modules/100616_c.C: New. * g++.dg/modules/100616_d.C: New.
2022-09-29place `const volatile' objects in read-only sectionsJose E. Marchesi3-3/+20
It is common for C BPF programs to use variables that are implicitly set by the BPF loader and run-time. It is also necessary for these variables to be stored in read-only storage so the BPF verifier recognizes them as such. This leads to declarations using both `const' and `volatile' qualifiers, like this: const volatile unsigned char is_allow_list = 0; Where `volatile' is used to avoid the compiler to optimize out the variable, or turn it into a constant, and `const' to make sure it is placed in .rodata. Now, it happens that: - GCC places `const volatile' objects in the .data section, under the assumption that `volatile' somehow voids the `const'. - LLVM places `const volatile' objects in .rodata, under the assumption that `volatile' is orthogonal to `const'. So there is a divergence, that has practical consequences: it makes BPF programs compiled with GCC to not work properly. When looking into this, I found this bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 "change semantics of const volatile variables" which was filed back in 2005, long ago. This report was already asking to put `const volatile' objects in .rodata, questioning the current behavior. While discussing this in the #gcc IRC channel I was pointed out to the following excerpt from the C18 spec: 6.7.3 Type qualifiers / 5 The properties associated with qualified types are meaningful only for expressions that are lval-values [note 135] 135) The implementation may place a const object that is not volatile in a read-only region of storage. Moreover, the implementation need not allocate storage for such an object if its $ address is never used. This footnote may be interpreted as if const objects that are volatile shouldn't be put in read-only storage. Even if I personally was not very convinced of that interpretation (see my earlier comment in BZ 25521) I filed the following issue in the LLVM tracker in order to discuss the matter: https://github.com/llvm/llvm-project/issues/56468 As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14 reflectors about this. He reported that the reflectors don't think footnote 135 has any normative value. So, not having a normative mandate on either direction, there are two options: a) To change GCC to place `const volatile' objects in .rodata instead of .data. b) To change LLVM to place `const volatile' objects in .data instead of .rodata. Considering that: - One target (bpf-unknown-none) breaks with the current GCC behavior. - No target/platform relies on the GCC behavior, that we know. - Changing the LLVM behavior at this point would be very severely traumatic for the BPF people and their users. I think the right thing to do at this point is a). Therefore this patch. Regtested in x86_64-linux-gnu and bpf-unknown-none. No regressions observed. gcc/ChangeLog: PR middle-end/25521 * varasm.cc (categorize_decl_for_section): Place `const volatile' objects in read-only sections. (default_select_section): Likewise. gcc/testsuite/ChangeLog: PR middle-end/25521 * lib/target-supports.exp (check_effective_target_elf): Define. * gcc.dg/pr25521.c: New test.
2022-09-29data-ref: Fix ranges_maybe_overlap_p testRichard Sandiford1-4/+4
dr_may_alias_p rightly used poly_int_tree_p to guard a use of ranges_maybe_overlap_p, but used the non-poly extractors. This caused a few failures in the SVE ACLE asm tests. gcc/ * tree-data-ref.cc (dr_may_alias_p): Use to_poly_widest instead of to_widest.
2022-09-29aarch64: Remove redundant TARGET_* checksRichard Sandiford4-49/+47
After previous patches, it's possible to remove TARGET_* options that are redundant due to (IMO) obvious dependencies. gcc/ * config/aarch64/aarch64.h (TARGET_CRYPTO, TARGET_SHA3, TARGET_SM4) (TARGET_DOTPROD): Don't depend on TARGET_SIMD. (TARGET_AES, TARGET_SHA2): Likewise. Remove TARGET_CRYPTO test. (TARGET_FP_F16INST): Don't depend on TARGET_FLOAT. (TARGET_SVE2, TARGET_SVE_F32MM, TARGET_SVE_F64MM): Don't depend on TARGET_SVE. (TARGET_SVE2_AES, TARGET_SVE2_BITPERM, TARGET_SVE2_SHA3) (TARGET_SVE2_SM4): Don't depend on TARGET_SVE2. (TARGET_F32MM, TARGET_F64MM): Delete. * config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Guard float macros with just TARGET_FLOAT rather than TARGET_FLOAT || TARGET_SIMD. * config/aarch64/aarch64-simd.md (copysign<mode>3): Depend only on TARGET_SIMD, rather than TARGET_FLOAT && TARGET_SIMD. (aarch64_crypto_aes<aes_op>v16qi): Depend only on TARGET_AES, rather than TARGET_SIMD && TARGET_AES. (aarch64_crypto_aes<aesmc_op>v16qi): Likewise. (*aarch64_crypto_aese_fused): Likewise. (*aarch64_crypto_aesd_fused): Likewise. (aarch64_crypto_pmulldi): Likewise. (aarch64_crypto_pmullv2di): Likewise. (aarch64_crypto_sha1hsi): Likewise TARGET_SHA2. (aarch64_crypto_sha1hv4si): Likewise. (aarch64_be_crypto_sha1hv4si): Likewise. (aarch64_crypto_sha1su1v4si): Likewise. (aarch64_crypto_sha1<sha1_op>v4si): Likewise. (aarch64_crypto_sha1su0v4si): Likewise. (aarch64_crypto_sha256h<sha256_op>v4si): Likewise. (aarch64_crypto_sha256su0v4si): Likewise. (aarch64_crypto_sha256su1v4si): Likewise. (aarch64_crypto_sha512h<sha512_op>qv2di): Likewise TARGET_SHA3. (aarch64_crypto_sha512su0qv2di): Likewise. (aarch64_crypto_sha512su1qv2di, eor3q<mode>4): Likewise. (aarch64_rax1qv2di, aarch64_xarqv2di, bcaxq<mode>4): Likewise. (aarch64_sm3ss1qv4si): Likewise TARGET_SM4. (aarch64_sm3tt<sm3tt_op>qv4si): Likewise. (aarch64_sm3partw<sm3part_op>qv4si): Likewise. (aarch64_sm4eqv4si, aarch64_sm4ekeyqv4si): Likewise. * config/aarch64/aarch64.md (<FLOATUORS:optab>dihf2) (copysign<GPF:mode>3, copysign<GPF:mode>3_insn) (xorsign<mode>3): Remove redundant TARGET_FLOAT condition.
2022-09-29aarch64: Tweak handling of -mgeneral-regs-onlyRichard Sandiford7-22/+68
-mgeneral-regs-only is effectively "+nofp for the compiler without changing the assembler's ISA flags". Currently that's implemented by making TARGET_FLOAT, TARGET_SIMD and TARGET_SVE depend on !TARGET_GENERAL_REGS_ONLY and then making any feature that needs FP registers depend (directly or indirectly) on one of those three TARGET macros. The problem is that it's easy to forgot to do the last bit. This patch instead represents the distinction between "assemnbler ISA flags" and "compiler ISA flags" more directly, funnelling all updates through a new function that sets both sets of flags together. gcc/ * config/aarch64/aarch64.opt (aarch64_asm_isa_flags): New variable. * config/aarch64/aarch64.h (aarch64_asm_isa_flags) (aarch64_isa_flags): Redefine as read-only macros. (TARGET_SIMD, TARGET_FLOAT, TARGET_SVE): Don't depend on !TARGET_GENERAL_REGS_ONLY. * common/config/aarch64/aarch64-common.cc (aarch64_set_asm_isa_flags): New function. (aarch64_handle_option): Call it when updating -mgeneral-regs. * config/aarch64/aarch64-protos.h (aarch64_simd_switcher): Replace m_old_isa_flags with m_old_asm_isa_flags. (aarch64_set_asm_isa_flags): Declare. * config/aarch64/aarch64-builtins.cc (aarch64_simd_switcher::aarch64_simd_switcher) (aarch64_simd_switcher::~aarch64_simd_switcher): Save and restore aarch64_asm_isa_flags instead of aarch64_isa_flags. * config/aarch64/aarch64-sve-builtins.cc (check_required_extensions): Use aarch64_asm_isa_flags instead of aarch64_isa_flags. * config/aarch64/aarch64.cc (aarch64_set_asm_isa_flags): New function. (aarch64_override_options, aarch64_handle_attr_arch) (aarch64_handle_attr_cpu, aarch64_handle_attr_isa_flags): Use aarch64_set_asm_isa_flags to set the ISA flags. (aarch64_option_print, aarch64_declare_function_name) (aarch64_start_file): Use aarch64_asm_isa_flags instead of aarch64_isa_flags. (aarch64_can_inline_p): Check aarch64_asm_isa_flags as well as aarch64_isa_flags.
2022-09-29aarch64: Tweak contents of flags_on/off fieldsRichard Sandiford1-8/+6
After previous changes, it's more convenient if the flags_on and flags_off fields of all_extensions include the feature flag itself. gcc/ * common/config/aarch64/aarch64-common.cc (all_extensions): Include the feature flag in flags_on and flags_off. (aarch64_parse_extension): Update accordingly. (aarch64_get_extension_string_for_isa_flags): Likewise.
2022-09-29aarch64: Make more use of aarch64_feature_flagsRichard Sandiford7-47/+56
A previous patch added a aarch64_feature_flags typedef, to abstract the representation of the feature flags. This patch makes existing code use the typedef too. Hope I've caught them all! gcc/ * common/config/aarch64/aarch64-common.cc: Use aarch64_feature_flags for feature flags throughout. * config/aarch64/aarch64-protos.h: Likewise. * config/aarch64/aarch64-sve-builtins.h: Likewise. * config/aarch64/aarch64-sve-builtins.cc: Likewise. * config/aarch64/aarch64.cc: Likewise. * config/aarch64/aarch64.opt: Likewise. * config/aarch64/driver-aarch64.cc: Likewise.
2022-09-29aarch64: Tweak constness of option-related dataRichard Sandiford3-28/+27
Some of the option structures have all-const member variables. That doesn't seem necessary: we can just use const on the objects that are supposed to be read-only. Also, with the new, more C++-heavy option handling, it seems better to use constexpr for the static data, to make sure that we're not adding unexpected overhead. gcc/ * common/config/aarch64/aarch64-common.cc (aarch64_option_extension) (processor_name_to_arch, arch_to_arch_name): Remove const from member variables. (all_extensions, all_cores, all_architectures): Make a constexpr. * config/aarch64/aarch64.cc (processor): Remove const from member variables. (all_architectures): Make a constexpr. * config/aarch64/driver-aarch64.cc (aarch64_core_data) (aarch64_arch_driver_info): Remove const from member variables. (aarch64_cpu_data, aarch64_arches): Make a constexpr. (get_arch_from_id): Return a pointer to const. (host_detect_local_cpu): Update accordingly.
2022-09-29aarch64: Avoid std::string in static dataRichard Sandiford1-2/+2
Just a minor patch to avoid having to construct std::strings in static data. gcc/ * common/config/aarch64/aarch64-common.cc (processor_name_to_arch) (arch_to_arch_name): Use const char * instead of std::string.
2022-09-29aarch64: Simplify generation of .arch stringsRichard Sandiford9-204/+55
aarch64-common.cc has two arrays, one maintaining the original definition order and one sorted by population count. Sorting by population count was a way of ensuring topological ordering, taking advantage of the fact that the entries are partially ordered by the subset relation. However, the sorting is not needed now that the .def file is forced to have topological order from the outset. Other changes are: (1) The population count used: uint64_t total_flags_a = opt_a->flag_canonical & opt_a->flags_on; uint64_t total_flags_b = opt_b->flag_canonical & opt_b->flags_on; int popcnt_a = popcount_hwi ((HOST_WIDE_INT)total_flags_a); int popcnt_b = popcount_hwi ((HOST_WIDE_INT)total_flags_b); where I think the & was supposed to be |. This meant that the counts would always be 1 in practice, since flag_canonical is a single bit. This led us to printing +nofp+nosimd even though GCC "knows" (and GAS agrees) that +nofp disables simd. (2) The .arch output code converts +aes+sha2 to +crypto. I think the main reason for doing this is to support assemblers that predate the individual per-feature crypto flags. It therefore seems more natural to treat it as a special case, rather than as an instance of a general pattern. Hopefully we won't do something similar in future! (There is already special handling of CRC, for different reasons.) (3) Previously, if the /proc/cpuinfo code saw a feature like sve, it would assume the presence of all the features that sve depends on. It would be possible to keep that behaviour if necessary, but it was simpler to assume the presence of fp16 (say) only when fphp is present. There's an argument that that's more conservatively correct too. gcc/ * common/config/aarch64/aarch64-common.cc (TARGET_OPTION_INIT_STRUCT): Delete. (aarch64_option_extension): Remove is_synthetic_flag. (all_extensions): Update accordingly. (all_extensions_by_on, opt_ext, opt_ext_cmp): Delete. (aarch64_option_init_struct, aarch64_contains_opt): Delete. (aarch64_get_extension_string_for_isa_flags): Rewrite to use all_extensions instead of all_extensions_on. gcc/testsuite/ * gcc.target/aarch64/cpunative/info_8: Add all dependencies of sve. * gcc.target/aarch64/cpunative/info_9: Likewise svesm4. * gcc.target/aarch64/cpunative/info_15: Likewise. * gcc.target/aarch64/cpunative/info_16: Likewise sve2. * gcc.target/aarch64/cpunative/info_17: Likewise. * gcc.target/aarch64/cpunative/native_cpu_2.c: Expect just +nofp rather than +nofp+nosimd. * gcc.target/aarch64/cpunative/native_cpu_10.c: Likewise. * gcc.target/aarch64/target_attr_15.c: Likewise.
2022-09-29aarch64: Simplify feature definitionsRichard Sandiford10-454/+374
Currently the aarch64-option-extensions.def entries, the aarch64-cores.def entries, and the AARCH64_FL_FOR_* macros have a transitive closure of dependencies that is maintained by hand. This is a bit error-prone and is becoming less tenable as more features are added. The main point of this patch is to maintain the closure automatically instead. For example, the +sve2-aes extension requires sve2 and aes. This is now described using: AARCH64_OPT_EXTENSION("sve2-aes", SVE2_AES, (SVE2, AES), ...) If life was simple, we could just give the name of the feature and the list of features that it requires/depends on. But sadly things are more complicated. For example: - the legacy +crypto option enables aes and sha2 only, but +nocrypto disables all crypto-related extensions, including sm4. - +fp16fml enables fp16, but armv8.4-a enables fp16fml without fp16. fp16fml only has an effect when fp16 is also present; see the comments for more details. - +bf16 enables simd, but +bf16+nosimd is valid and enables just the scalar bf16 instructions. rdma behaves similarly. To handle cases like these, the option entries have extra fields to specify what an explicit +foo enables and what an explicit +nofoo disables, in addition to the absolute dependencies. The other main changes are: - AARCH64_FL_* are now defined automatically. - the feature list for each architecture level moves from aarch64.h to aarch64-arches.def. As a consequence, we now have a (redundant) V8A feature flag. While there, the patch uses a new typedef, aarch64_feature_flags, for the set of feature flags. This should make it easier to switch to a class if we run out of bits in the uint64_t. For now the patch hardcodes the fact that crypto is the only synthetic option. A later patch will remove this field. To test for things that might not be covered by the testsuite, I made the driver print out the all_extensions, all_cores and all_archs arrays before and after the patch, with the following tweaks: - renumber the old AARCH64_FL_* bit assignments to match the .def order - remove the new V8A flag when printing the new tables - treat CRYPTO and CRYPTO | AES | SHA2 the same way when printing the core tables (On the last point: some cores enabled just CRYPTO while others enabled CRYPTO, AES and SHA2. This doesn't cause a difference in behaviour because of how the dependent macros are defined. With the new scheme, all entries with CRYPTO automatically get AES and SHA2 too.) The only difference is that +nofp now turns off dotprod. This was another instance of an incomplete transitive closure, but unlike the instances fixed in a previous patch, it had no observable effect. gcc/ * config/aarch64/aarch64-option-extensions.def: Switch to a new format. * config/aarch64/aarch64-cores.def: Use the same format to specify lists of features. * config/aarch64/aarch64-arches.def: Likewise, moving that information from aarch64.h. * config/aarch64/aarch64-opts.h (aarch64_feature_flags): New typedef. * config/aarch64/aarch64.h (aarch64_feature): New class enum. Turn AARCH64_FL_* macros into constexprs, getting the definitions from aarch64-option-extensions.def. Remove AARCH64_FL_FOR_* macros. * common/config/aarch64/aarch64-common.cc: Include aarch64-feature-deps.h. (all_extensions): Update for new .def format. (all_extensions_by_on, all_cores, all_architectures): Likewise. * config/aarch64/driver-aarch64.cc: Include aarch64-feature-deps.h. (aarch64_extensions): Update for new .def format. (aarch64_cpu_data, aarch64_arches): Likewise. * config/aarch64/aarch64.cc: Include aarch64-feature-deps.h. (all_architectures, all_cores): Update for new .def format. * config/aarch64/aarch64-sve-builtins.cc (check_required_extensions): Likewise.
2022-09-29aarch64: Reorder an entry in aarch64-option-extensions.defRichard Sandiford10-20/+20
aarch64-option-extensions.def was topologically sorted except for one case: crypto came before its aes and sha2 dependencies. This patch moves crypto after sha2 instead. gcc/ * config/aarch64/aarch64-option-extensions.def: Move crypto after sha2. gcc/testsuite/ * gcc.target/aarch64/cpunative/native_cpu_0.c: Expect +crypto to come after +crc. * gcc.target/aarch64/cpunative/native_cpu_13.c: Likewise. * gcc.target/aarch64/cpunative/native_cpu_16.c: Likewise. * gcc.target/aarch64/cpunative/native_cpu_17.c: Likewise. * gcc.target/aarch64/cpunative/native_cpu_6.c: Likewise. * gcc.target/aarch64/cpunative/native_cpu_7.c: Likewise. * gcc.target/aarch64/options_set_2.c: Likewise. * gcc.target/aarch64/options_set_3.c: Likewise. * gcc.target/aarch64/options_set_4.c: Likewise.
2022-09-29aarch64: Fix transitive closure of featuresRichard Sandiford3-10/+58
aarch64-option-extensions.def requires us to maintain the transitive closure of options by hand. This patch fixes a few cases where a flag was missed. +noaes and +nosha2 now disable +crypto, which IMO makes more sense and is consistent with the Clang behaviour. gcc/ * config/aarch64/aarch64-option-extensions.def (dotprod): Depend on fp as well as simd. (sha3): Likewise. (aes): Likewise. Make +noaes disable crypto. (sha2): Likewise +nosha2. Also make +nosha2 disable sha3 and sve2-sha3. (sve2-sha3): Depend on sha2 as well as sha3. gcc/testsuite/ * gcc.target/aarch64/options_set_6.c: Expect +crypto+nosha2 to disable crypto but keep aes. * gcc.target/aarch64/pragma_cpp_predefs_4.c: New test.
2022-09-29aarch64: Remove AARCH64_FL_RCPC8_4 [PR107025]Richard Sandiford2-4/+3
AARCH64_FL_RCPC8_4 is an odd-one-out in that it has no associated entry in aarch64-option-extensions.def. This means that, although it is internally separated from AARCH64_FL_V8_4A, there is no mechanism for turning it on and off individually, independently of armv8.4-a. The only place that the flag was used independently was in the entry for thunderx3t110, which enabled it alongside V8_3A. As noted in PR107025, this means that any use of the extension will fail to assemble. In the PR trail, Andrew suggested removing the core entry. That might be best long-term, but since the barrier for removing command-line options without a deprecation period is very high, this patch instead just drops the flag from the core entry. We'll still produce correct code. gcc/ PR target/107025 * config/aarch64/aarch64.h (oAARCH64_FL_RCPC8_4): Delete. (AARCH64_FL_FOR_V8_4A): Update accordingly. (AARCH64_ISA_RCPC8_4): Use AARCH64_FL_V8_4A directly. * config/aarch64/aarch64-cores.def (thunderx3t110): Remove AARCH64_FL_RCPC8_4.
2022-09-29aarch64: Avoid redundancy in aarch64-cores.defRichard Sandiford4-68/+68
The flags fields of the aarch64-cores.def always start with AARCH64_FL_FOR_<ARCH>. After previous changes, <ARCH> is always identical to the previous field, so we can drop the explicit AARCH64_FL_FOR_<ARCH> and derive it programmatically. This isn't a big saving in itself, but it helps with later patches. gcc/ * config/aarch64/aarch64-cores.def: Remove AARCH64_FL_FOR_<ARCH> from the flags field. * common/config/aarch64/aarch64-common.cc (all_cores): Add it here instead. * config/aarch64/aarch64.cc (all_cores): Likewise. * config/aarch64/driver-aarch64.cc (all_cores): Likewise.
2022-09-29aarch64: Small config.gcc cleanupsRichard Sandiford2-9/+1
The aarch64-option-extensions.def parsing in config.gcc had some code left over from when it tried to parse the whole macro definition. Also, config.gcc now only looks at the first fields of the aarch64-arches.def entries. gcc/ * config.gcc: Remove dead aarch64-option-extensions.def code. * config/aarch64/aarch64-arches.def: Update comment.
2022-09-29aarch64: Add "V" to aarch64-arches.def namesRichard Sandiford5-82/+83
This patch completes the renaming of architecture-level related things by adding "V" to the name of the architecture in aarch64-arches.def. Since the "V" is predictable, we can easily drop it when we don't need it (as when matching /proc/cpuinfo). Having a valid C identifier is necessary for later patches. gcc/ * config/aarch64/aarch64-arches.def: Add a leading "V" to the ARCH_IDENT fields. * config/aarch64/aarch64-cores.def: Update accordingly. * common/config/aarch64/aarch64-common.cc (all_cores): Likewise. * config/aarch64/aarch64.cc (all_cores): Likewise. * config/aarch64/driver-aarch64.cc (aarch64_arches): Skip the leading "V".
2022-09-29aarch64: Rename AARCH64_FL_FOR_ARCH macrosRichard Sandiford5-109/+109
This patch renames AARCH64_FL_FOR_ARCH* macros to follow the same V<number><profile> names that we (now) use elsewhere. The names are only temporary -- a later patch will move the information to the .def file instead. However, it helps with the sequencing to do this first. gcc/ * config/aarch64/aarch64.h (AARCH64_FL_FOR_ARCH8): Rename to... (AARCH64_FL_FOR_V8A): ...this. (AARCH64_FL_FOR_ARCH8_1): Rename to... (AARCH64_FL_FOR_V8_1A): ...this. (AARCH64_FL_FOR_ARCH8_2): Rename to... (AARCH64_FL_FOR_V8_2A): ...this. (AARCH64_FL_FOR_ARCH8_3): Rename to... (AARCH64_FL_FOR_V8_3A): ...this. (AARCH64_FL_FOR_ARCH8_4): Rename to... (AARCH64_FL_FOR_V8_4A): ...this. (AARCH64_FL_FOR_ARCH8_5): Rename to... (AARCH64_FL_FOR_V8_5A): ...this. (AARCH64_FL_FOR_ARCH8_6): Rename to... (AARCH64_FL_FOR_V8_6A): ...this. (AARCH64_FL_FOR_ARCH8_7): Rename to... (AARCH64_FL_FOR_V8_7A): ...this. (AARCH64_FL_FOR_ARCH8_8): Rename to... (AARCH64_FL_FOR_V8_8A): ...this. (AARCH64_FL_FOR_ARCH8_R): Rename to... (AARCH64_FL_FOR_V8R): ...this. (AARCH64_FL_FOR_ARCH9): Rename to... (AARCH64_FL_FOR_V9A): ...this. (AARCH64_FL_FOR_ARCH9_1): Rename to... (AARCH64_FL_FOR_V9_1A): ...this. (AARCH64_FL_FOR_ARCH9_2): Rename to... (AARCH64_FL_FOR_V9_2A): ...this. (AARCH64_FL_FOR_ARCH9_3): Rename to... (AARCH64_FL_FOR_V9_3A): ...this. * common/config/aarch64/aarch64-common.cc (all_cores): Update accordingly. * config/aarch64/aarch64-arches.def: Likewise. * config/aarch64/aarch64-cores.def: Likewise. * config/aarch64/aarch64.cc (all_cores): Likewise.
2022-09-29aarch64: Rename AARCH64_FL architecture-level macrosRichard Sandiford1-36/+36
Following on from the previous AARCH64_ISA patch, this one adds the profile name directly to the end of architecture-level AARCH64_FL_* macros. gcc/ * config/aarch64/aarch64.h (AARCH64_FL_V8_1, AARCH64_FL_V8_2) (AARCH64_FL_V8_3, AARCH64_FL_V8_4, AARCH64_FL_V8_5, AARCH64_FL_V8_6) (AARCH64_FL_V9, AARCH64_FL_V8_7, AARCH64_FL_V8_8, AARCH64_FL_V9_1) (AARCH64_FL_V9_2, AARCH64_FL_V9_3): Add "A" to the end of the name. (AARCH64_FL_V8_R): Rename to AARCH64_FL_V8R. (AARCH64_FL_FOR_ARCH8_1, AARCH64_FL_FOR_ARCH8_2): Update accordingly. (AARCH64_FL_FOR_ARCH8_3, AARCH64_FL_FOR_ARCH8_4): Likewise. (AARCH64_FL_FOR_ARCH8_5, AARCH64_FL_FOR_ARCH8_6): Likewise. (AARCH64_FL_FOR_ARCH8_7, AARCH64_FL_FOR_ARCH8_8): Likewise. (AARCH64_FL_FOR_ARCH8_R, AARCH64_FL_FOR_ARCH9): Likewise. (AARCH64_FL_FOR_ARCH9_1, AARCH64_FL_FOR_ARCH9_2): Likewise. (AARCH64_FL_FOR_ARCH9_3, AARCH64_ISA_V8_2A, AARCH64_ISA_V8_3A) (AARCH64_ISA_V8_4A, AARCH64_ISA_V8_5A, AARCH64_ISA_V8_6A): Likewise. (AARCH64_ISA_V8R, AARCH64_ISA_V9A, AARCH64_ISA_V9_1A): Likewise. (AARCH64_ISA_V9_2A, AARCH64_ISA_V9_3A): Likewise.
2022-09-29aarch64: Rename AARCH64_ISA architecture-level macrosRichard Sandiford3-17/+17
All AARCH64_ISA_* architecture-level macros except AARCH64_ISA_V8_R are for the A profile: they cause __ARM_ARCH_PROFILE to be set to 'A' and they are associated with architecture names like armv8.4-a. It's convenient for later patches if we make this explicit by adding an "A" to the name. Also, rather than add an underscore (as for V8_R) it's more convenient to add the profile directly to the number, like we already do in the ARCH_IDENT field of the aarch64-arches.def entries. gcc/ * config/aarch64/aarch64.h (AARCH64_ISA_V8_2, AARCH64_ISA_V8_3) (AARCH64_ISA_V8_4, AARCH64_ISA_V8_5, AARCH64_ISA_V8_6) (AARCH64_ISA_V9, AARCH64_ISA_V9_1, AARCH64_ISA_V9_2) (AARCH64_ISA_V9_3): Add "A" to the end of the name. (AARCH64_ISA_V8_R): Rename to AARCH64_ISA_V8R. (TARGET_ARMV8_3, TARGET_JSCVT, TARGET_FRINT, TARGET_MEMTAG): Update accordingly. * common/config/aarch64/aarch64-common.cc (aarch64_get_extension_string_for_isa_flags): Likewise. * config/aarch64/aarch64-c.cc (aarch64_define_unconditional_macros): Likewise.
2022-09-29Add OPTIONS_H_EXTRA to GTFILESRichard Sandiford1-0/+1
I have a patch that adds a typedef to aarch64's <cpu>-opts.h. The typedef is used for a TargetVariable in the .opt file, which means that it is covered by PCH and so needs to be visible to gengtype. <cpu>-opts.h is not included directly in tm.h, but indirectly by target headers (in this case aarch64.h). There was therefore nothing that caused it to be added to GTFILES. gcc/ * Makefile.in (GTFILES): Add OPTIONS_H_EXTRA.
2022-09-29driver, cppdefault: Unbreak bootstrap on Debian/Ubuntu [PR107059]Jakub Jelinek2-0/+15
My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++ apparently broke bootstrap on some Debian/Ubuntu setups. Those multiarch targets put some headers into /usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of /usr/include/bits/. This is handled by /* /usr/include comes dead last. */ { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 }, { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 }, in cppdefault.cc, where the 2 in the last element of the first initializer means the entry is ignored on non-multiarch and suffixed by the multiarch dir otherwise, so installed gcc has search path like: /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed /usr/local/include /usr/include/x86_64-linux-gnu /usr/include (when installed with DESTDIR=/home/jakub/gcc/obj01inst). Now, when fixincludes is run, it is processing the whole /usr/include dir and all its subdirectories, so floatn{,-common.h} actually go into .../include-fixed/x86_64-linux-gnu/bits/floatn{,-common.h} because that is where they appear in /usr/include too. In some setups, /usr/include also contains /usr/include/bits -> x86_64-linux-gnu/bits symlink and after the r13-2896 tweak it works. In other setups there is no /usr/include/bits symlink and when one #include <bits/floatn.h> given the above search path, it doesn't find the fixincluded header, as /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/bits/floatn.h doesn't exist and /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu/bits/floatn.h isn't searched and so /usr/include/x86_64-linux-gnu/bits/floatn.h wins and we fail because of typedef whatever _Float128; and similar. The following patch ought to fix this. The first hunk by arranging that the installed search path actually looks like: /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu /home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed /usr/local/include /usr/include/x86_64-linux-gnu /usr/include and thus for include-fixed it treats it the same as /usr/include. The second FIXED_INCLUDE_DIR entry there is: { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, /* A multilib suffix needs adding if different multilibs use different headers. */ #ifdef SYSROOT_HEADERS_SUFFIX_SPEC 1 #else 0 #endif }, where SYSROOT_HEADERS_SUFFIX_SPEC is defined only on vxworks or mips*-mti-linux and arranges for multilib path to be appended there. Neither of those systems is multiarch. This isn't enough, because when using the -B option, the driver adds -isystem .../include-fixed in another place, so the second hunk modifies that spot the same. /home/jakub/gcc/obj01/gcc/xgcc -B /home/jakub/gcc/obj01/gcc/ then has search path: /home/jakub/gcc/obj01/gcc/include /home/jakub/gcc/obj01/gcc/include-fixed/x86_64-linux-gnu /home/jakub/gcc/obj01/gcc/include-fixed /usr/local/include /usr/include/x86_64-linux-gnu /usr/include which again is what I think we want to achieve. 2022-09-29 Jakub Jelinek <jakub@redhat.com> PR bootstrap/107059 * cppdefault.cc (cpp_include_defaults): If SYSROOT_HEADERS_SUFFIX_SPEC isn't defined, add FIXED_INCLUDE_DIR entry with multilib flag 2 before FIXED_INCLUDE_DIR entry with multilib flag 0. * gcc.cc (do_spec_1): If multiarch_dir, add include-fixed/multiarch_dir paths before include-fixed paths.
2022-09-29support -gz=zstd for both linker and assemblerMartin Liska4-5/+37
PR driver/106897 gcc/ChangeLog: * common.opt: Add -gz=zstd value. * configure.ac: Detect --compress-debug-sections=zstd for both linker and assembler. * configure: Regenerate. * gcc.cc (LINK_COMPRESS_DEBUG_SPEC): Handle -gz=zstd. (ASM_COMPRESS_DEBUG_SPEC): Likewise.
2022-09-29ada: Remove duplicated doc comment sectionRonan Desplanques1-37/+3
A documentation section was duplicated by mistake in r0-110752. This commit removes the copy that was added by r0-110752, but integrates the small editorial change that it brought to the original. gcc/ada/ * einfo.ads: remove documentation duplicate
2022-09-29ada: Further tweak new expansion of contractsEric Botcazou2-6/+48
The original extended return statement is mandatory for functions whose result type is limited in Ada 2005 and later. gcc/ada/ * contracts.adb (Build_Subprogram_Contract_Wrapper): Put back the extended return statement if the result type is built-in-place. * sem_attr.adb (Analyze_Attribute_Old_Result): Also expect an extended return statement.
2022-09-29ada: Improve efficiency of slice-of-component assignmentBob Duff1-24/+71
This patch improves the efficiency of slice assignment when the left- or right-hand side is a slice of a component or a slice of a slice. Previously, the optimization was disabled in these cases, just in case there might be a volatile or independent component lurking. Now we explicitly check all the relevant subcomponents of the prefix. The previous version said (in exp_ch5.adb): -- ...We could -- complicate this code by actually looking for such volatile and -- independent components. and that's exactly what we are doing here. gcc/ada/ * exp_ch5.adb (Expand_Assign_Array_Loop_Or_Bitfield): Make the checks for volatile and independent objects more precise.
2022-09-29ada: Fix checking of Refined_State with nested package renamingsPiotr Trojanek1-1/+4
When collecting package state declared in package body, we should only recursively examine the visible part of nested packages while ignoring other entities related to packages (e.g. package bodies or package renamings). gcc/ada/ * sem_util.adb (Collect_Visible_States): Ignore package renamings.
2022-09-29Merge branch 'master' into devel/sphinxMartin Liska416-5774/+10691
2022-09-29tree-optimization/105646 - re-interpret always executed in uninit diagRichard Biener2-2/+25
The following fixes PR105646, not diagnosing int f1(); int f3(){ auto const & a = f1(); bool v3{v3}; return a; } with optimization because the early uninit diagnostic pass only diagnoses always executed cases. The patch does this by re-interpreting what always executed means and choosing to ignore exceptional and abnormal control flow for this. At the same time it improves things as suggested in a comment - when the value-numbering run done without optimizing figures there's a fallthru path, consider blocks on it as always executed. PR tree-optimization/105646 * tree-ssa-uninit.cc (warn_uninitialized_vars): Pre-compute the set of fallthru reachable blocks from function entry and use that to determine wlims.always_executed. * g++.dg/uninit-pr105646.C: New testcase.
2022-09-29Check nonlinear iv in vect_can_advance_ivs_p.liuhongt4-35/+64
vectorizable_nonlinear_induction doesn't always guard vect_peel_nonlinear_iv_init when it's called by vect_update_ivs_after_vectorizer. It's supposed to be guarded by vect_can_advance_ivs_p. gcc/ChangeLog: PR tree-optimization/107055 * tree-vect-loop-manip.cc (vect_can_advance_ivs_p): Check for nonlinear induction variables. * tree-vect-loop.cc (vect_can_peel_nonlinear_iv_p): New functions. (vectorizable_nonlinear_induction): Put part codes into vect_can_peel_nonlinear_iv_p. * tree-vectorizer.h (vect_can_peel_nonlinear_iv_p): Declare. gcc/testsuite/ChangeLog: * gcc.target/i386/pr107055.c: New test.
2022-09-29Daily bump.GCC Administrator8-1/+254
2022-09-29libstdc++: Disable volatile-qualified std::bind for C++20Jonathan Wakely13-33/+87
LWG 2487 added a precondition to std::bind for C++17, making volatile-qualified uses undefined. We still support it, but with a deprecated warning. P1065R2 made it explicitly ill-formed for C++20, so we should no longer accept it as deprecated. This implements that change. libstdc++-v3/ChangeLog: * doc/xml/manual/evolution.xml: Document std::bind API changes. * doc/xml/manual/intro.xml: Document LWG 2487 status. * doc/xml/manual/using.xml: Clarify default value of _GLIBCXX_USE_DEPRECATED. * doc/html/*: Regenerate. * include/std/functional (_Bind::operator()(Args&&...) volatile) (_Bind::operator()(Args&&...) const volatile) (_Bind_result::operator()(Args&&...) volatile) (_Bind_result::operator()(Args&&...) const volatile): Replace with deleted overload for C++20 and later. * testsuite/20_util/bind/cv_quals.cc: Check for deprecated warnings in C++17. * testsuite/20_util/bind/cv_quals_2.cc: Likewise, and check for ill-formed in C++20.
2022-09-29libstdc++: Make INVOKE<R> refuse to create dangling references [PR70692]Jonathan Wakely7-28/+80
This is the next part of the library changes from P2255R2. This makes INVOKE<R> ill-formed if converting the INVOKE expression to R would bind a reference to a temporary object. The is_invocable_r trait is now false if the invocation would create a dangling reference. This is done by adding the dangling check to the __is_invocable_impl partial specialization used for INVOKE<R> expressions. This change also slightly simplifies the nothrow checking recently added to that partial specialization. This change also removes the is_invocable_r checks from the pre-C++17 implementation of std::__invoke_r, because there is no need for it to be SFINAE-friendly. None of our C++11 and C++14 uses of INVOKE<R> require those constraints. The std::function constructor needs to check is_invocable_r, but that's already done explicitly, so we don't need to recheck when calling __is_invoke_r in std::function::operator(). The other uses of std::__is_invoke_r do not need to be constrained and can just be ill-formed if the INVOKE<R> expression is ill-formed. libstdc++-v3/ChangeLog: PR libstdc++/70692 * include/bits/invoke.h [__cplusplus < 201703] (__invoke_r): Remove is_invocable and is_convertible constraints. * include/std/type_traits (__is_invocable_impl::_S_conv): Use non-deduced context for parameter. (__is_invocable_impl::_S_test): Remove _Check_noex template parameter and use deduced noexcept value in its place. Add bool parameter to detect dangling references. (__is_invocable_impl::type): Adjust call to _S_test to avoid deducing unnecessary noexcept property.. (__is_invocable_impl::__nothrow_type): Rename to ... (__is_invocable_impl::__nothrow_conv): ... this. Adjust call to _S_test to deduce noexcept property. * testsuite/20_util/bind/dangling_ref.cc: New test. * testsuite/20_util/function/cons/70692.cc: New test. * testsuite/20_util/function_objects/invoke/dangling_ref.cc: New test. * testsuite/20_util/is_invocable/dangling_ref.cc: New test. * testsuite/30_threads/packaged_task/cons/dangling_ref.cc: New test.
2022-09-28Add instruction level discriminator support.Eugene Rozenfeld21-55/+187
This is the first in a series of patches to enable discriminator support in AutoFDO. This patch switches to tracking discriminators per statement/instruction instead of per basic block. Tracking per basic block was problematic since not all statements in a basic block needed a discriminator and, also, later optimizations could move statements between basic blocks making correlation during AutoFDO compilation unreliable. Tracking per statement also allows us to assign different discriminators to multiple function calls in the same basic block. A subsequent patch will add that support. The idea of this patch is based on commit 4c311d95cf6d9519c3c20f641cc77af7df491fdf by Dehao Chen in vendors/google/heads/gcc-4_8 but uses a slightly different approach. In Dehao's work special (normally unused) location ids and side tables were used to keep track of locations with discriminators. Things have changed since then and I don't think we have unused location ids anymore. Instead, I made discriminators a part of ad-hoc locations. The difference from Dehao's work also includes support for discriminator reading/writing in lto streaming and in modules. Tested on x86_64-pc-linux-gnu. gcc/ChangeLog: * basic-block.h: Remove discriminator from basic blocks. * cfghooks.cc (split_block_1): Remove discriminator from basic blocks. * final.cc (final_start_function_1): Switch from per-bb to per statement discriminator. (final_scan_insn_1): Don't keep track of basic block discriminators. (compute_discriminator): Switch from basic block discriminators to instruction discriminators. (insn_discriminator): New function to return instruction discriminator. (notice_source_line): Use insn_discriminator. * gimple-pretty-print.cc (dump_gimple_bb_header): Remove dumping of basic block discriminators. * gimple-streamer-in.cc (input_bb): Remove reading of basic block discriminators. * gimple-streamer-out.cc (output_bb): Remove writing of basic block discriminators. * input.cc (make_location): Pass 0 discriminator to COMBINE_LOCATION_DATA. (location_with_discriminator): New function to combine locus with a discriminator. (has_discriminator): New function to check if a location has a discriminator. (get_discriminator_from_loc): New function to get the discriminator from a location. * input.h: Declarations of new functions. * lto-streamer-in.cc (cmp_loc): Use discriminators in location comparison. (apply_location_cache): Keep track of current discriminator. (input_location_and_block): Read discriminator from stream. * lto-streamer-out.cc (clear_line_info): Set current discriminator to UINT_MAX. (lto_output_location_1): Write discriminator to stream. * lto-streamer.h: Add discriminator to cached_location. Add current_discr to lto_location_cache. Add current_discr to output_block. * print-rtl.cc (print_rtx_operand_code_i): Print discriminator. * rtl.h: Add extern declaration of insn_discriminator. * tree-cfg.cc (assign_discriminator): New function to assign a unique discriminator value to all statements in a basic block that have the given line number. (assign_discriminators): Assign discriminators to statement locations. * tree-pretty-print.cc (dump_location): Dump discriminators. * tree.cc (set_block): Preserve discriminator when setting block. (set_source_range): Preserve discriminator when setting source range. gcc/cp/ChangeLog: * module.cc (write_location): Write discriminator. (read_location): Read discriminator. libcpp/ChangeLog: * include/line-map.h: Add discriminator to location_adhoc_data. (get_combined_adhoc_loc): Add discriminator parameter. (get_discriminator_from_adhoc_loc): Add external declaration. (get_discriminator_from_loc): Add external declaration. (COMBINE_LOCATION_DATA): Add discriminator parameter. * lex.cc (get_location_for_byte_range_in_cur_line) Pass 0 discriminator in a call to COMBINE_LOCATION_DATA. (warn_about_normalization): Pass 0 discriminator in a call to COMBINE_LOCATION_DATA. (_cpp_lex_direct): Pass 0 discriminator in a call to COMBINE_LOCATION_DATA. * line-map.cc (location_adhoc_data_hash): Use discriminator compute location_adhoc_data hash. (location_adhoc_data_eq): Use discriminator when comparing location_adhoc_data. (can_be_stored_compactly_p): Check discriminator to determine compact storage. (get_combined_adhoc_loc): Add discriminator parameter. (get_discriminator_from_adhoc_loc): New function to get the discriminator from an ad-hoc location. (get_discriminator_from_loc): New function to get the discriminator from a location. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/pr85213.c: Pass -gno-statement-frontiers.
2022-09-28c++: Add DECL_NTTP_OBJECT_P lang flagNathan Sidwell5-22/+26
VAR_DECLs for NTTPs need to be handled specially by module streaming, in the same manner to type info decls. This reworks their handling to allow that work to drop in. We use DECL_LANG_FLAG_5 to indicate such decls (I didn't notice template_parm_object_p, which looks at the mangled name -- anyway a bit flag on the node is better, IMHO). We break apart the creation routine, so there's now an entry point the module machinery can use directly. gcc/cp/ * cp-tree.h (DECL_NTTP_OBJECT_P): New. (template_parm_object_p): Delete. (build_template_parm_object): Declare. * cxx-pretty-print.cc (pp_cx_template_argument_list): Use DECL_NTTP_OBJECT_P. * error.cc (dump_simple_decl): Likewise. * mangle.cc (write_template_arg): Likewise. * pt.cc (template_parm_object_p): Delete. (create_template_parm_object): Separated out checking from ... (get_template_parm_object): ... this, new external entry point.
2022-09-28i386: Mark XMM4-XMM6 as clobbered by encodekey128/encodekey256H.J. Lu4-14/+12
encodekey128 and encodekey256 operations clear XMM4-XMM6. But it is documented that XMM4-XMM6 are reserved for future usages and software should not rely upon them being zeroed. Change encodekey128 and encodekey256 to clobber XMM4-XMM6. gcc/ PR target/107061 * config/i386/predicates.md (encodekey128_operation): Check XMM4-XMM6 as clobbered. (encodekey256_operation): Likewise. * config/i386/sse.md (encodekey128u32): Clobber XMM4-XMM6. (encodekey256u32): Likewise. gcc/testsuite/ PR target/107061 * gcc.target/i386/keylocker-encodekey128.c: Don't check XMM4-XMM6. * gcc.target/i386/keylocker-encodekey256.c: Likewise.
2022-09-29RISC-V: Add ABI-defined RVV types.Ju-Zhe Zhong17-1/+1317
gcc/ChangeLog: * config.gcc: Add riscv-vector-builtins.o. * config/riscv/riscv-builtins.cc (riscv_init_builtins): Add RVV builtin function. * config/riscv/riscv-protos.h (riscv_v_ext_enabled_vector_mode_p): New function. * config/riscv/riscv.cc (ENTRY): New macro. (riscv_v_ext_enabled_vector_mode_p): New function. (riscv_mangle_type): Add RVV mangle. (riscv_vector_mode_supported_p): Adjust RVV machine mode. (riscv_verify_type_context): Add context check for RVV. (riscv_vector_alignment): Add RVV alignment target hook support. (TARGET_VECTOR_MODE_SUPPORTED_P): New target hook support. (TARGET_VERIFY_TYPE_CONTEXT): Ditto. (TARGET_VECTOR_ALIGNMENT): Ditto. * config/riscv/t-riscv: Add riscv-vector-builtins.o * config/riscv/riscv-vector-builtins.cc: New file. * config/riscv/riscv-vector-builtins.def: New file. * config/riscv/riscv-vector-builtins.h: New file. * config/riscv/riscv-vector-switch.def: New file. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-1.c: New test. * gcc.target/riscv/rvv/base/abi-2.c: New test. * gcc.target/riscv/rvv/base/abi-3.c: New test. * gcc.target/riscv/rvv/base/abi-4.c: New test. * gcc.target/riscv/rvv/base/abi-5.c: New test. * gcc.target/riscv/rvv/base/abi-6.c: New test. * gcc.target/riscv/rvv/base/abi-7.c: New test. * gcc.target/riscv/rvv/rvv.exp: New test.
2022-09-28var-tracking: Add entry values up to max register modeStefan Schulze Frielinghaus1-0/+17
For parameter of type integer which do not consume a whole register (modulo sign/zero extension) this patch adds entry values up to maximal register mode. gcc/ChangeLog: * var-tracking.cc (vt_add_function_parameter): Add entry values up to maximal register mode.