aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2022-03-21c++: initialized array of vla [PR58646]Jason Merrill2-0/+8
We went into build_vec_init because we're dealing with a VLA, but then build_vec_init thought it was safe to just build an INIT_EXPR because the outer dimension is constant. Nope. PR c++/58646 gcc/cp/ChangeLog: * init.cc (build_vec_init): Check for vla element type. gcc/testsuite/ChangeLog: * g++.dg/ext/vla24.C: New test.
2022-03-21x86: Disable AVX on pr86722.c and pr90356.cH.J. Lu2-3/+2
SSE/SSE2 are enabled explicitly on pr86722.c and pr90356.c. Disable AVX to avoid AVX with -march=native. PR target/86722 PR tree-optimization/90356 * gcc.target/i386/pr86722.c: Add -mno-avx. * gcc.target/i386/pr90356.c: Likewise.
2022-03-21x86: Properly check FEATURE_AESKLEH.J. Lu1-2/+2
1. Pass 0x19 to __cpuid for bit_AESKLE. 2. Enable FEATURE_AESKLE only if bit_AESKLE is set. PR target/104998 * common/config/i386/cpuinfo.h (get_available_features): Pass 0x19 to __cpuid for bit_AESKLE. Enable FEATURE_AESKLE only if bit_AESKLE is set.
2022-03-21c++: designated init and aggregate members [PR103337]Jason Merrill7-9/+101
Our C++20 designated initializer handling was broken with members of class type; we would find the relevant member and then try to find a member of the member with the same name. Or we would sometimes ignore the designator entirely. The former problem is fixed by the change to reshape_init_class, the latter by the change to reshape_init_r. PR c++/103337 PR c++/102740 PR c++/103299 PR c++/102538 gcc/cp/ChangeLog: * decl.cc (reshape_init_class): Avoid looking for designator after we found it. (reshape_init_r): Keep looking for designator. gcc/testsuite/ChangeLog: * g++.dg/ext/flexary3.C: Remove one error. * g++.dg/parse/pr43765.C: Likewise. * g++.dg/cpp2a/desig22.C: New test. * g++.dg/cpp2a/desig23.C: New test. * g++.dg/cpp2a/desig24.C: New test. * g++.dg/cpp2a/desig25.C: New test.
2022-03-21c++: designator and anon struct [PR101767]Jason Merrill2-0/+26
We found .x in the anonymous struct, but then didn't find .y there; we should decide that means we're done with the struct rather than that the code is wrong. PR c++/101767 gcc/cp/ChangeLog: * decl.cc (reshape_init_class): Back out of anon struct if a designator doesn't match. gcc/testsuite/ChangeLog: * g++.dg/ext/anon-struct10.C: New test.
2022-03-21Update gcc sv.poJoseph Myers1-519/+341
* sv.po: Update.
2022-03-21d: Fix internal compiler error: in build_complex, at tree.c:2358Iain Buclaw2-1/+15
The conversion from the special _Complex enum to native complex used build_complex, however the input value isn't necessarily a literal. PR d/105004 gcc/d/ChangeLog: * d-codegen.cc (build_struct_literal): Use complex_expr to build complex expressions from __c_complex types. gcc/testsuite/ChangeLog: * gdc.dg/pr105004.d: New test.
2022-03-21d: Merge upstream dmd 2503f17e5, phobos a74fa63e6.Iain Buclaw73-725/+1001
D front-end changes: - Import dmd mainline development. - Removed internal d_intN and d_unsN aliases to stdint types, which caused a regression on Solaris where int8_t is a char (PR104911). Phobos changes: - Import phobos mainline development. PR d/104911 gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 2503f17e5. * d-convert.cc (convert_expr): Replace d_uns64 with dinteger_t. * d-lang.cc: Remove dmd/root/file.h include. (d_handle_option): Update for new front-end interface. (d_parse_file): Likewise. libphobos/ChangeLog: * src/MERGE: Merge upstream phobos a74fa63e6.
2022-03-21rtl-ssa: Fix prev/next_def confusion [PR104869]Richard Sandiford5-15/+155
rtl-ssa chains definitions into an RPO list. It also groups sequences of clobbers together into a single node, so that it's possible to skip over the clobbers in constant time in order to get the next or previous set. When adding a clobber to an insn, the main DF barriers for that clobber are the last use of the previous set (if any) and the next set (if any); adding a new clobber to a sea of clobbers is fine. def_lookup provided the basis for these barriers as prev_def () and next_def (). But of course, in hindsight, those were bad names, since they implied that the returned values were literally the previous definition (of any kind) or the next definition (of any kind). And function_info::make_use_available was using the same routines assuming that they had that meaning. :-( This made a difference for the case where the start of a BB occurs in the middle of an (RPO) clobber group: we then want the previous and next clobbers in the group, rather than the set before the clobber group and the set after the clobber group. This patch renames the existing routines to something that's hopefully clearer (though also more long-winded). It then adds routines that really do provide the previous and next definitions. This complication is supposed to be internal to rtl-ssa and, as mentioned above, is part of trying to reduce time complexity. gcc/ PR middle-end/104869 * rtl-ssa/accesses.h (clobber_group::prev_clobber): Declare. (clobber_group::next_clobber): Likewise. (def_lookup::prev_def): Rename to... (def_lookup::last_def_of_prev_group): ...this. (def_lookup::next_def): Rename to... (def_lookup::first_def_of_next_group): ...this. (def_lookup::matching_or_prev_def): Rename to... (def_lookup::matching_set_or_last_def_of_prev_group): ...this. (def_lookup::matching_or_next_def): Rename to... (def_lookup::matching_set_or_first_def_of_next_group): ...this. (def_lookup::prev_def): New function, taking the lookup insn as argument. (def_lookup::next_def): Likewise. * rtl-ssa/member-fns.inl (def_lookup::prev_def): Rename to... (def_lookup::last_def_of_prev_group): ...this. (def_lookup::next_def): Rename to... (def_lookup::first_def_of_next_group): ...this. (def_lookup::matching_or_prev_def): Rename to... (def_lookup::matching_set_or_last_def_of_prev_group): ...this. (def_lookup::matching_or_next_def): Rename to... (def_lookup::matching_set_or_first_def_of_next_group): ...this. * rtl-ssa/movement.h (restrict_movement_for_dead_range): Update after above renaming. * rtl-ssa/accesses.cc (clobber_group::prev_clobber): New function. (clobber_group::next_clobber): Likewise. (def_lookup::prev_def): Likewise. (def_lookup::next_def): Likewise. (function_info::make_use_available): Pass the lookup insn to def_lookup::prev_def and def_lookup::next_def. gcc/testsuite/ PR middle-end/104869 * g++.dg/pr104869.C: New test.
2022-03-21Avoid a warning of overflowQian Jianhua1-1/+1
This patch avoid a warning of "c-ada-spec.cc:1660:34: warning: 'sprintf' may write a terminating nul past the end of the destination [-Wformat-overflow=]" when build GCC. gcc/c-family/ChangeLog: * c-ada-spec.cc: Change array length
2022-03-21docs: Document min-pagesize parameter.Martin Liska1-0/+3
gcc/ChangeLog: * doc/invoke.texi: Document min-pagesize parameter.
2022-03-21Dump when estimating the number of iterations of a loopRichard Biener1-0/+3
Currently the dumps are somewhat inter-mangled, not showing the (possibly bad) recursion between niter estimation and number of iteration computation. The following tries to improve deciphering a little bit by dumping when we do niter estimation. 2022-03-21 Richard Biener <rguenther@suse.de> * tree-ssa-loop-niter.cc (estimate_numbers_of_iterations): Dump we are estimating niter of loop.
2022-03-21RISC-V: Implement misc macro for vector extensions.Kito Cheng10-13/+319
See also: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21 gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_ext_flag_table): Update flag name and mask name. * config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Define misc macro for vector extensions. * config/riscv/riscv-opts.h (MASK_VECTOR_EEW_32): Rename to ... (MASK_VECTOR_ELEN_32): ... this. (MASK_VECTOR_EEW_64): Rename to ... (MASK_VECTOR_ELEN_64): ... this. (MASK_VECTOR_EEW_FP_32): Rename to ... (MASK_VECTOR_ELEN_FP_32): ... this. (MASK_VECTOR_EEW_FP_64): Rename to ... (MASK_VECTOR_ELEN_FP_64): ... this. (TARGET_VECTOR_ELEN_32): New. (TARGET_VECTOR_ELEN_64): Ditto. (TARGET_VECTOR_ELEN_FP_32): Ditto. (TARGET_VECTOR_ELEN_FP_64): Ditto. (TARGET_MIN_VLEN): Ditto. * config/riscv/riscv.opt (riscv_vector_eew_flags): Rename to ... (riscv_vector_elen_flags): ... this. gcc/testsuite/ChangeLog: * gcc.target/riscv/arch-13.c: New. * gcc.target/riscv/arch-14.c: Ditto. * gcc.target/riscv/arch-15.c: Ditto. * gcc.target/riscv/predef-18.c: Ditto. * gcc.target/riscv/predef-19.c: Ditto. * gcc.target/riscv/predef-20.c: Ditto.
2022-03-21AVX512FP16: Fix masm=intel output for vfc?(madd|mul)csh [PR 104977]Hongyu Wang2-1/+14
Fix typo in subst for scalar complex mask_round operand. gcc/ChangeLog: PR target/104977 * config/i386/sse.md (avx512fp16_fma<complexopname>sh_v8hf<mask_scalarcz_name><round_scalarcz_name>): Correct round operand for intel dialect. gcc/testsuite/ChangeLog: PR target/104977 * gcc.target/i386/pr104977.c: New test.
2022-03-21Daily bump.GCC Administrator2-1/+5
2022-03-20Fix testsuite fallout from pr104960 changeJeff Law1-2/+2
Recent changes twiddled the output for s390/arch13/sel-1.c causing testsuite failures. As far as I can tell both sequences are equivalent from a performance standpoint. This patch changes the test to accept both forms. gcc/testsuite * gcc.target/s390/arch13/sel-1.c: Adjust expected output.
2022-03-20Daily bump.GCC Administrator5-1/+67
2022-03-19fortran: Separate associate character lengths earlier [PR104570]Mikael Morin3-3/+45
This change workarounds an ICE in the evaluation of the character length of an array expression referencing an associate variable; the code is not prepared to see a non-scalar expression as it doesn’t initialize the scalarizer. Before this change, associate length symbols get a new gfc_charlen at resolution stage to unshare them from the associate expression, so that at translation stage it is a decl specific to the associate symbol that is initialized, not the decl of some other symbol. This reinitialization of gfc_charlen happens after expressions referencing the associate symbol have been parsed, so that those expressions retain the original gfc_charlen they have copied from the symbol. At translation stage, the gfc_charlen for the associate symbol is setup with the decl holding the actual length value, but the expressions have retained the original gfc_charlen without any decl. So they need to evaluate the character length, and this is where the ICE happens. This change moves the reinitialization of gfc_charlen earlier at parsing stage, so that at resolution stage the gfc_charlen can be retained as it’s already not shared with any other symbol, and the expressions which now share their gfc_charlen with the symbol are automatically updated when the length decl is setup at translation stage. There is no need any more to evaluate the character length as it has all the required information, and the ICE doesn’t happen. The first resolve.cc hunk is necessary to avoid regressing on the associate_35.f90 testcase. PR fortran/104228 PR fortran/104570 gcc/fortran/ChangeLog: * parse.cc (parse_associate): Use a new distinct gfc_charlen if the copied type has one whose length is not known to be constant. * resolve.cc (resolve_assoc_var): Reset charlen if it’s shared with the associate target regardless of the expression type. Don’t reinitialize charlen if it’s deferred. gcc/testsuite/ChangeLog: * gfortran.dg/associate_58.f90: New test.
2022-03-19selftest: Move C-specific tests to c_familyArthur Cohen6-6/+6
When trying to make use of the selftest framework over on the rust frontend, we ran into issues where rust1 was expected to produce errors containing C-like type names such as `int`. I had gotten in contact with David Malcolm on the gcc mailing list [1], who advised moving some test functions to a better location. The offending functions have also been renamed in order to better fit the C family of tests, and are thus not called when performing general selftests anymore. Kindly, [1]: https://gcc.gnu.org/pipermail/gcc/2021-November/237703.html 2022-02-16 Arthur Cohen <arthur.cohen@embecosm.com> gcc/c-family/ * c-common.cc (c_family_tests): Call the new tests. * c-common.h (c_diagnostic_tests): Declare. (c_opt_problem_cc_tests): Likewise. gcc/ * diagnostic.cc (diagnostic_cc_tests): Rename to... (c_diagnostic_cc_tests): ...this. * opt-problem.cc (opt_problem_cc_tests): Rename to... (c_opt_problem_cc_tests): ...this. * selftest-run-tests.cc (selftest::run_tests): No longer run opt_problem_cc_tests or diagnostic_cc_tests. * selftest.h (diagnostic_cc_tests): Remove declaration. (opt_problem_cc_tests): Likewise.
2022-03-19[PATCH] gcc: pass-manager: Fix memory leak. [PR jit/63854]Marc Nieper-Wißkirchen3-4/+21
Before the patch, compiling the hello world example of libgccjit with the external driver under Valgrind shows a loss of 12,611 (48 direct) bytes. After the patch, no memory leaks are reported anymore. (Memory leaks occurring when using the internal driver are mostly in the driver code in gcc/gcc.c and have to be fixed separately.) The patch has been tested by fully bootstrapping the compiler with the frontends C, C++, Fortran, LTO, ObjC, JIT and running the test suite under a x86_64-pc-linux-gnu host. gcc/ChangeLog: PR jit/63854 * hash-traits.h (struct typed_const_free_remove): New. (struct free_string_hash): New. * pass_manager.h: Use free_string_hash. * passes.cc (pass_manager::register_pass_name): Use free_string_hash. (pass_manager::~pass_manager): Delete allocated m_name_to_pass_map.
2022-03-19i386: Don't emit pushf;pop for __builtin_ia32_readeflags_u* with unused lhs ↵Jakub Jelinek2-0/+21
[PR104971] __builtin_ia32_readeflags_u* aren't marked const or pure I think intentionally, so that they aren't CSEd from different regions of a function etc. because we don't and can't easily track all dependencies between it and surrounding code (if somebody looks at the condition flags, it is dependent on the vast majority of instructions). But the builtin itself doesn't have any side-effects, so if we ignore the result of the builtin, there is no point to emit anything. There is a LRA bug that miscompiles the testcase which this patch makes latent, which is certainly worth fixing too, but IMHO this change (and maybe ix86_gimple_fold_builtin too which would fold it even earlier when it looses lhs) is worth it as well. 2022-03-19 Jakub Jelinek <jakub@redhat.com> PR middle-end/104971 * config/i386/i386-expand.cc (ix86_expand_builtin) <case IX86_BUILTIN_READ_FLAGS>: If ignore, don't push/pop anything and just return const0_rtx. * gcc.target/i386/pr104971.c: New test.
2022-03-19c-family: Fix up ICE during pretty-printing of PMF related expression [PR101515]Jakub Jelinek2-0/+24
The intent of r11-6729 is that it prints something that helps user to figure out what exactly is being accessed. When we find a unique non-static data member that is being accessed, even when we can't fold it nicely, IMNSHO it is better to print ((sometype *)&var)->field or (*(sometype *)&var).field instead of *(fieldtype *)((char *)&var + 56) because the user doesn't know what is at offset 56, we shouldn't ask user to decipher structure layout etc. One question is if we could return something better for the TYPE_PTRMEMFUNC_FLAG RECORD_TYPE members here (something that would print it more naturally/readably in a C++ way), though the fact that the routine is in c-family makes it harder. Another one is whether we shouldn't punt for FIELD_DECLs that don't have nicely printable name of its containing scope, something like: if (tree scope = get_containing_scope (field)) if (TYPE_P (scope) && TYPE_NAME (scope) == NULL_TREE) break; return cop; or so. This patch implements that. Note the returned cop is a COMPONENT_REF where the first argument has a nicely printable type name (x with type sp), but sp's TYPE_MAIN_VARIANT is the unnamed TYPE_PTRMEMFUNC_FLAG. So another possibility would be if we see such a problem for the FIELD_DECL's scope, check if TYPE_MAIN_VARIANT of the first COMPONENT_REF's argument is equal to that scope and in that case use TREE_TYPE of the first COMPONENT_REF's argument as the scope instead. 2022-03-19 Jakub Jelinek <jakub@redhat.com> PR c++/101515 * c-pretty-print.cc (c_fold_indirect_ref_for_warn): For C++ don't return COMPONENT_REFs with FIELD_DECLs whose containing scope can't be printed. * g++.dg/warn/pr101515.C: New test.
2022-03-19Daily bump.GCC Administrator6-1/+266
2022-03-18analyzer: extend state-purging to locals [PR104943]David Malcolm11-82/+853
The existing analyzer code attempts to purge the state of SSA names where it can in order to minimize the size of program_state instances, and to increase the chances of being able to reuse exploded_node instances whilst exploring the user's code. PR analyzer/104943 identifies that we fail to purge state of local variables, based on behavior seen in PR analyzer/104954 when attempting to profile slow performance of -fanalyzer on a particular file in the Linux kernel, where that testcase has many temporary "boxed" values of structs containing ints, which are never cleaned up, leading to bloat of the program_state instances (specifically, of the store objects). This patch generalizes the state purging from just being on SSA names to also work on local variables. Doing so requires that we detect where addresses to a local variable (or within them) are taken; we assume that once a pointer has been taken, it's not longer safe to purge the value of that decl at any successor point within the function. Doing so speeds up the PR analyzer/104954 Linux kernel analyzer testcase from taking 254 seconds to "just" 186 seconds (and I have a followup patch in development that seems to further reduce this to 37 seconds). The patch may also help with scaling up taint-detection so that it can eventually be turned on by default, but we're not quite there (this is PR analyzer/103533). gcc/analyzer/ChangeLog: PR analyzer/104943 PR analyzer/104954 PR analyzer/103533 * analyzer.h (class state_purge_per_decl): New forward decl. * engine.cc (impl_run_checkers): Pass region_model_manager to state_purge_map ctor. * program-point.cc (function_point::final_stmt_p): New. (function_point::get_next): New. * program-point.h (function_point::final_stmt_p): New decl. (function_point::get_next): New decl. * program-state.cc (program_state::prune_for_point): Generalize to purge local decls as well as SSA names. (program_state::can_purge_base_region_p): New. * program-state.h (program_state::can_purge_base_region_p): New decl. * region-model.cc (struct append_ssa_names_cb_data): Rename to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename to... (region_model::get_regions_for_current_frame): ...this, updating for other renamings. (region_model::append_ssa_names_cb): Rename to... (region_model::append_regions_cb): ...this, and drop the requirement that the subregion be a SSA name. * region-model.h (struct append_ssa_names_cb_data): Rename decl to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename decl to... (region_model::get_regions_for_current_frame): ...this. (region_model::append_ssa_names_cb): Rename decl to... (region_model::append_regions_cb): ...this. * state-purge.cc: Include "tristate.h", "selftest.h", "analyzer/store.h", "analyzer/region-model.h", and "gimple-walk.h". (get_candidate_for_purging): New. (class gimple_op_visitor): New. (my_load_cb): New. (my_store_cb): New. (my_addr_cb): New. (state_purge_map::state_purge_map): Add "mgr" param. Update for renamings. Find uses of local variables. (state_purge_map::~state_purge_map): Update for renaming of m_map to m_ssa_map. Clean up m_decl_map. (state_purge_map::get_or_create_data_for_decl): New. (state_purge_per_ssa_name::state_purge_per_ssa_name): Update for inheriting from state_purge_per_tree. (state_purge_per_ssa_name::add_to_worklist): Likewise. (state_purge_per_decl::state_purge_per_decl): New. (state_purge_per_decl::add_needed_at): New. (state_purge_per_decl::add_pointed_to_at): New. (state_purge_per_decl::process_worklists): New. (state_purge_per_decl::add_to_worklist): New. (same_binding_p): New. (fully_overwrites_p): New. (state_purge_per_decl::process_point_backwards): New. (state_purge_per_decl::process_point_forwards): New. (state_purge_per_decl::needed_at_point_p): New. (state_purge_annotator::print_needed): Generalize to print local decls as well as SSA names. * state-purge.h (class state_purge_map): Update leading comment. (state_purge_map::map_t): Rename to... (state_purge_map::ssa_map_t): ...this. (state_purge_map::iterator): Rename to... (state_purge_map::ssa_iterator): ...this. (state_purge_map::decl_map_t): New typedef. (state_purge_map::decl_iterator): New typedef. (state_purge_map::state_purge_map): Add "mgr" param. (state_purge_map::get_data_for_ssa_name): Update for renaming. (state_purge_map::get_any_data_for_decl): New. (state_purge_map::get_or_create_data_for_decl): New decl. (state_purge_map::begin): Rename to... (state_purge_map::begin_ssas): ...this. (state_purge_map::end): Rename to... (state_purge_map::end_ssa): ...this. (state_purge_map::begin_decls): New. (state_purge_map::end_decls): New. (state_purge_map::m_map): Rename to... (state_purge_map::m_ssa_map): ...this. (state_purge_map::m_decl_map): New field. (class state_purge_per_tree): New class. (class state_purge_per_ssa_name): Inherit from state_purge_per_tree. (state_purge_per_ssa_name::get_function): Move to base class. (state_purge_per_ssa_name::point_set_t): Likewise. (state_purge_per_ssa_name::m_fun): Likewise. (class state_purge_per_decl): New. gcc/testsuite/ChangeLog: PR analyzer/104943 PR analyzer/104954 PR analyzer/103533 * gcc.dg/analyzer/torture/boxed-ptr-1.c: Update expected number of exploded nodes to reflect improvements in state purging. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-03-18analyzer: add tests of boxed values [PR104943]David Malcolm5-0/+785
This patch adds various regression tests as preparatory work for purging irrelevant local decls from state (PR analyzer/104943) gcc/testsuite/ChangeLog: PR analyzer/104943 * gcc.dg/analyzer/boxed-malloc-1-29.c: New test. * gcc.dg/analyzer/boxed-malloc-1.c: New test. * gcc.dg/analyzer/taint-alloc-5.c: New test. * gcc.dg/analyzer/torture/boxed-int-1.c: New test. * gcc.dg/analyzer/torture/boxed-ptr-1.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-03-18[PR104961] LRA: split hard reg for reload pseudo with clobber.Vladimir N. Makarov2-14/+34
Splitting hard register live range did not work for subreg of a multi-reg reload pseudo. Reload insns for such pseudo contain clobber of the pseudo and splitting did not take this into account. The patch fixes it. gcc/ChangeLog: PR rtl-optimization/104961 * lra-assigns.cc (find_reload_regno_insns): Process reload pseudo clobber. gcc/testsuite/ChangeLog: PR rtl-optimization/104961 * gcc.target/i386/pr104961.c: New.
2022-03-18tree: Add comment.Jason Merrill1-0/+1
gcc/ChangeLog: * tree.h (IDENTIFIER_LENGTH): Add comment.
2022-03-18c++: using lookup within class defn [PR104476]Jason Merrill7-63/+142
The problem in both PR92918 and PR104476 is overloading of base member functions brought in by 'using' with direct member functions during parsing of the class body. To this point they've had a troublesome coexistence which was resolved by set_class_bindings when the class is complete, but we also need to handle lookup within the class body, such as in a trailing return type. The problem was that push_class_level_binding would either clobber the using-decl with the direct members or vice-versa. In older versions of GCC we only pushed dependent usings, and preferring the dependent using made sense, as it expresses a type-dependent overload set that we can't do anything useful with. But when we started keeping non-dependent usings around, push_class_level_binding in particular wasn't adjusted accordingly. This patch makes that adjustment, and pushes the functions imported by a non-dependent using immediately from finish_member_declaration. This made diagnosing redundant using-decls a bit awkward, since we no longer push the using-decl itself; I handle that by noticing when we try to add the same function again and searching TYPE_FIELDS for the previous using-decl. PR c++/92918 PR c++/104476 gcc/cp/ChangeLog: * class.cc (add_method): Avoid adding the same used function twice. (handle_using_decl): Don't add_method. (finish_struct): Don't using op= if we have one already. (maybe_push_used_methods): New. * semantics.cc (finish_member_declaration): Call it. * name-lookup.cc (diagnose_name_conflict): No longer static. (push_class_level_binding): Revert 92918 patch, limit to dependent using. * cp-tree.h: Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/pr85070.C: Remove expected error. * g++.dg/lookup/using66a.C: New test. * g++.dg/lookup/using67.C: New test.
2022-03-18Allow (void *) 0xdeadbeef accesses without warnings [PR99578]Jakub Jelinek8-7/+173
Starting with GCC11 we keep emitting false positive -Warray-bounds or -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000 style accesses (or memory/string routines to such pointers). This is a standard programming style supported by all C/C++ compilers I've ever tried, used mostly in kernel or DSP programming, but sometimes also together with mmap MAP_FIXED when certain things, often I/O registers but could be anything else too are known to be present at fixed addresses. Such INTEGER_CST addresses can appear in code either because a user used it like that (in which case it is fine) or because somebody used pointer arithmetics (including &((struct whatever *)NULL)->field) on a NULL pointer. The middle-end warning code wrongly assumes that the latter case is what is very likely, while the former is unlikely and users should change their code. The following patch adds a min-pagesize param defaulting to 4KB, and treats INTEGER_CST addresses smaller than that as assumed results of pointer arithmetics from NULL while addresses equal or larger than that as expected user constant addresses. For GCC 13 we can represent results from pointer arithmetics on NULL using &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs. 2022-03-18 Jakub Jelinek <jakub@redhat.com> PR middle-end/99578 PR middle-end/100680 PR tree-optimization/100834 * params.opt (--param=min-pagesize=): New parameter. * pointer-query.cc (compute_objsize_r) <case ARRAY_REF>: Formatting fix. (compute_objsize_r) <case INTEGER_CST>: Use maximum object size instead of zero for pointer constants equal or larger than min-pagesize. * gcc.dg/tree-ssa/pr99578-1.c: New test. * gcc.dg/pr99578-1.c: New test. * gcc.dg/pr99578-2.c: New test. * gcc.dg/pr99578-3.c: New test. * gcc.dg/pr100680.c: New test. * gcc.dg/pr100834.c: New test.
2022-03-18c++: Fix up constexpr evaluation of new with zero sized types [PR104568]Jakub Jelinek3-26/+149
The new expression constant expression evaluation right now tries to deduce how many elts the array it uses for the heap or heap [] vars should have (or how many elts should its trailing array have if it has cookie at the start). As new is lowered at that point to (some_type *) ::operator new (size) or so, it computes it by subtracting cookie size if any from size, then divides the result by sizeof (some_type). This works fine for most types, except when sizeof (some_type) is 0, then we divide by zero; size is then equal to cookie_size (or if there is no cookie, to 0). The following patch special cases those cases so that we don't divide by zero and also recover the original outer_nelts from the expression by forcing the size not to be folded in that case but be explicit 0 * outer_nelts or cookie_size + 0 * outer_nelts. Note, we have further issues, we accept-invalid various cases, for both zero sized elt_type and even non-zero sized elts, we aren't able to diagnose out of bounds POINTER_PLUS_EXPR like: constexpr bool foo () { auto p = new int[2]; auto q1 = &p[0]; auto q2 = &p[1]; auto q3 = &p[2]; auto q4 = &p[3]; delete[] p; return true; } constexpr bool a = foo (); That doesn't look like a regression so I think we should resolve that for GCC 13, but there are 2 problems. Figure out why cxx_fold_pointer_plus_expression doesn't deal with the &heap [] etc. cases, and for the zero sized arrays, I think we really need to preserve whether user wrote an array ref or pointer addition, because in the &p[3] case if sizeof(p[0]) == 0 we know that if it has 2 elements it is out of bounds, while if we see p p+ 0 the information if it was p + 2 or p + 3 in the source is lost. clang++ seems to handle it fine even in the zero sized cases or with new expressions. 2022-03-18 Jakub Jelinek <jakub@redhat.com> PR c++/104568 * init.cc (build_new_constexpr_heap_type): Remove FULL_SIZE argument and its handling, instead add ITYPE2 argument. Only support COOKIE_SIZE != NULL. (build_new_1): If size is 0, change it to 0 * outer_nelts if outer_nelts is non-NULL. Pass type rather than elt_type to maybe_wrap_new_for_constexpr. * constexpr.cc (build_new_constexpr_heap_type): New function. (cxx_eval_constant_expression) <case CONVERT_EXPR>: If elt_size is zero sized type, try to recover outer_nelts from the size argument to operator new/new[] and pass that as arg_size to build_new_constexpr_heap_type. Pass ctx, non_constant_p and overflow_p to that call too. * g++.dg/cpp2a/constexpr-new22.C: New test.
2022-03-18testsuite: Add missing <vector> header to testJonathan Wakely1-0/+1
gcc/testsuite/ChangeLog: * g++.dg/torture/pr104601.C: Include <vector>.
2022-03-18c++: alias template and empty parameter packs [PR104008]Marek Polacek3-1/+105
Zero-length pack expansions are treated as if no list were provided at all, that is, with template<typename...> struct S { }; template<typename T, typename... Ts> void g() { S<std::is_same<T, Ts>...>; } g<int> will result in S<>. In the following test we have something similar: template <typename T, typename... Ts> using IsOneOf = disjunction<is_same<T, Ts>...>; and then we have "IsOneOf<OtherHolders>..." where OtherHolders is an empty pack. Since r11-7931, we strip_typedefs in TYPE_PACK_EXPANSION. In this test that results in "IsOneOf<OtherHolders>" being turned into "disjunction<>". So the whole expansion is now "disjunction<>...". But then we error in make_pack_expansion because find_parameter_packs_r won't find the pack OtherHolders. We strip the alias template because dependent_alias_template_spec_p says it's not dependent. It it not dependent because this alias is not TEMPLATE_DECL_COMPLEX_ALIAS_P. My understanding is that currently we consider an alias complex if it 1) expands a pack from the enclosing class, as in template<template<typename... U> typename... TT> struct S { template<typename... Args> using X = P<TT<Args...>...>; }; where the alias expands TT; or 2) the expansion does *not* name all the template parameters, as in template<typename...> struct R; template<typename T, typename... Ts> using U = R<X<Ts>...>; where T is not named in the expansion. But IsOneOf is neither. And it can't know how it's going to be used. Therefore I think we cannot make it complex (and in turn dependent) to fix this bug. After much gnashing of teeth, I think we simply want to avoid stripping the alias if the new pattern doesn't have any parameter packs to expand. PR c++/104008 gcc/cp/ChangeLog: * tree.cc (strip_typedefs): Don't strip an alias template when doing so would result in losing a parameter pack. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias3.C: New test. * g++.dg/cpp0x/variadic-alias4.C: New test.
2022-03-18Fortran/OpenMP: Fix privatization of associated namesTobias Burnus1-0/+10
gfc_omp_predetermined_sharing cases the associate-name pointer variable to be OMP_CLAUSE_DEFAULT_FIRSTPRIVATE, which is fine. However, the associated selector is shared. Thus, the target of associate-name pointer should not get copied. (It was before but because of gfc_omp_privatize_by_reference returning false, the selector was not only wrongly copied but this was also not done properly.) gcc/fortran/ChangeLog: PR fortran/103039 * trans-openmp.cc (gfc_omp_clause_copy_ctor, gfc_omp_clause_dtor): Only privatize pointer for associate names. libgomp/ChangeLog: PR fortran/103039 * testsuite/libgomp.fortran/associate4.f90: New test.
2022-03-18testsuite, modules, Darwin: Adjust expected output for older OS versions.Iain Sandoe1-1/+4
Darwin versions <= 10 (macOS 10.6) emit different diagnostics for the failure case being tested by bad-mapper-1.C. Adjust the dg- expressions to reflect this. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/testsuite/ChangeLog: * g++.dg/modules/bad-mapper-1.C: Make dg- expressions that match the diagnostics output by earlier Darwin too.
2022-03-18Fix "[openmp] Set location for taskloop stmts"Tom de Vries1-2/+2
I accidentally committed an outdated version of patch "[openmp] Set location for taskloop stmts". Fix this by adding the missing changes. gcc/ChangeLog: 2022-03-18 Tom de Vries <tdevries@suse.de> * gimplify.cc (gimplify_omp_for): Set location using 'input_location'. Set gfor location only when dealing with a OMP_TASKLOOP.
2022-03-18[openmp] Set location for taskloop stmtsTom de Vries2-0/+16
The test-case included in this patch contains: ... #pragma omp taskloop simd shared(a) lastprivate(myId) ... This is translated to 3 taskloop statements in gimple, visible with -fdump-tree-gimple: ... #pragma omp taskloop private(D.2124) #pragma omp taskloop shared(a) shared(myId) private(i.0) firstprivate(a_h) #pragma omp taskloop lastprivate(myId) ... But when exposing the gimple statement locations using -fdump-tree-gimple-lineno, we find that only the first one has location information. Fix this by adding the missing location information. Tested gomp.exp on x86_64. Tested libgomp testsuite on x86_64 with nvptx accelerator. gcc/ChangeLog: 2022-03-18 Tom de Vries <tdevries@suse.de> * gimplify.cc (gimplify_omp_for): Set taskloop location. gcc/testsuite/ChangeLog: 2022-03-18 Tom de Vries <tdevries@suse.de> * c-c++-common/gomp/pr104968.c: New test.
2022-03-18[openmp] Fix SIMT reduction using TRUTH_{AND,OR}IF_EXPRTom de Vries1-1/+4
Consider test-case pr104952-1.c, included in this commit, containing: ... #pragma omp target map(tofrom:result) map(to:arr) #pragma omp simd reduction(||: result) ... When run on x86_64 with nvptx accelerator, the test-case either aborts or hangs. The reduction clause is translated by the SIMT code (active for nvptx) as a butterfly reduction loop with this butterfly shuffle / update pair: ... D.2163 = D.2163 || .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164) ... in the loop body. The problem is that the butterfly shuffle is possibly not executed, while it needs to be executed unconditionally. Fix this by translating instead as: ... D.tmp_bfly = .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164) D.2163 = D.2163 || D.tmp_bfly ... Tested on x86_64-linux with nvptx accelerator. gcc/ChangeLog: 2022-03-17 Tom de Vries <tdevries@suse.de> PR target/104952 * omp-low.cc (lower_rec_input_clauses): Make sure GOMP_SIMT_XCHG_BFLY is executed unconditionally. libgomp/ChangeLog: 2022-03-17 Tom de Vries <tdevries@suse.de> PR target/104952 * testsuite/libgomp.c/pr104952-1.c: New test. * testsuite/libgomp.c/pr104952-2.c: New test.
2022-03-18Fortran/OpenMP: Improve associate-name diagnostic [PR103039]Tobias Burnus3-24/+104
gcc/fortran/ChangeLog: PR fortran/103039 * openmp.cc (resolve_omp_clauses): Improve associate-name diagnostic for select type/rank. gcc/testsuite/ChangeLog: PR fortran/103039 * gfortran.dg/gomp/associate1.f90: Update dg-error. * gfortran.dg/gomp/associate2.f90: New test.
2022-03-18Refine HImode movement for "v" to "v".liuhongt2-1/+13
Set attr from HImode to HFmode which uses vmovsh instead of vmovw for movment between sse registers. gcc/ChangeLog: PR target/104974 * config/i386/i386.md (*movhi_internal): Set attr type from HI to HF for alternative 12 under TARGET_AVX512FP16. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104974.c: New test.
2022-03-18x86: Correct march=sapphirerapids to base on icelake serverCui,Lili3-7/+21
march=sapphirerapids should be based on icelake server not cooperlake. gcc/ChangeLog: PR target/104963 * config/i386/i386.h (PTA_SAPPHIRERAPIDS): change it to base on ICX. * doc/invoke.texi: Update documents for Intel sapphirerapids. gcc/testsuite/ChangeLog: PR target/104963 * gcc.target/i386/pr104963.c: New test case.
2022-03-18Daily bump.GCC Administrator4-1/+77
2022-03-17analyzer: fixes to -fdump-analyzer-state-purgeDavid Malcolm1-1/+2
gcc/analyzer/ChangeLog: * state-purge.cc (state_purge_annotator::add_node_annotations): Avoid duplicate before-supernode annotations when returning from an interprocedural call. Show after-supernode annotations. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-03-17analyzer: fix program_point::get_next for PK_BEFORE_STMTDavid Malcolm1-1/+1
gcc/analyzer/ChangeLog: * program-point.cc (program_point::get_next): Fix missing increment of index. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-03-17PR 90356: Use xor to load const_double 0.0 on SSE (always)Roger Sayle3-11/+30
Implementations of the x87 floating point instruction set have always had some pretty strange characteristics. For example on the original Intel Pentium the FLDPI instruction (to load 3.14159... into a register) took 5 cycles, and the FLDZ instruction (to load 0.0) took 2 cycles, when a regular FLD (load from memory) took just 1 cycle!? Given that back then memory latencies were much lower (relatively) than they are today, these instructions were all but useless except when optimizing for size (impressively FLDZ/FLDPI require only two bytes). Such was the world back in 2006 when Uros Bizjak first added support for fldz https://gcc.gnu.org/pipermail/gcc-patches/2006-November/202589.html and then shortly after sensibly disabled them for !optimize_size with https://gcc.gnu.org/pipermail/gcc-patches/2006-November/204405.html Alas this vestigial logic still persists in the compiler today, so for example on x86_64 for the following function: double foo(double x) { return x + 0.0; } generates with -O2 foo: addsd .LC0(%rip), %xmm0 ret .LC0: .long 0 .long 0 preferring to read the constant 0.0 from memory [the constant pool], except when optimizing for size. With -Os we get: foo: xorps %xmm1, %xmm1 addsd %xmm1, %xmm0 ret Which is not only smaller (the two instructions require seven bytes vs. eight for the original addsd from mem, even without considering the constant pool) but is also faster on modern hardware. The latter code sequence is generated by both clang and msvc with -O2. Indeed Agner Fogg documents the set of floating point/SSE constants that it's cheaper to materialize than to load from memory. This patch shuffles the conditions on the i386 backend's *movtf_internal, *movdf_internal and *movsf_internal define_insns to untangle the newer TARGET_SSE_MATH clauses from the historical standard_80387_constant_p conditions. Amongst the benefits of this are that it improves the code generated for PR tree-optimization/90356 and resolves PR target/86722. 2022-03-17 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog PR target/86722 PR tree-optimization/90356 * config/i386/i386.md (*movtf_internal): Don't guard standard_sse_constant_p clause by optimize_function_for_size_p. (*movdf_internal): Likewise. (*movsf_internal): Likewise. gcc/testsuite/ChangeLog PR target/86722 PR tree-optimization/90356 * gcc.target/i386/pr86722.c: New test case. * gcc.target/i386/pr90356.c: New test case.
2022-03-17Always use dominators in the cache when available.Andrew MacLeod1-28/+75
This patch adjusts range_from_dom to follow the dominator tree through the cache until value is found, then apply any outgoing ranges encountered along the way. This reduces the amount of cache storage required. PR tree-optimization/102943 * gimple-range-cache.cc (ranger_cache::range_from_dom): Find range via dominators and apply intermediary outgoing edge ranges.
2022-03-17tree-optimization/104960 - unsplit edges after late sinkingRichard Biener3-5/+14
Something went wrong when testing the earlier patch to move the late sinking to before the late phiopt for PR102008. The following makes sure to unsplit edges after the late sinking since the split edges confuse the following phiopt leading to missed optimizations. I've went for a new pass parameter for this to avoid changing the CFG after the early sinking pass at this point. 2022-03-17 Richard Biener <rguenther@suse.de> PR tree-optimization/104960 * passes.def: Add pass parameter to pass_sink_code, mark last one to unsplit edges. * tree-ssa-sink.cc (pass_sink_code::set_pass_param): New. (pass_sink_code::execute): Always execute TODO_cleanup_cfg when we need to unsplit edges. * gcc.dg/gimplefe-37.c: Adjust to allow either the true or false edge to have a forwarder.
2022-03-17gimplify: Emit clobbers for TARGET_EXPR_SLOT vars later [PR103984]Jakub Jelinek2-18/+47
As mentioned in the PR, we emit a bogus uninitialized warning but easily could emit wrong-code for it or similar testcases too. The bug is that we emit clobber for a TARGET_EXPR_SLOT too early: D.2499.e = B::qux (&h); [return slot optimization] D.2516 = 1; try { B::B (&D.2498, &h); try { _2 = baz (&D.2498); D.2499.f = _2; D.2516 = 0; try { try { bar (&D.2499); } finally { C::~C (&D.2499); } } finally { D.2499 = {CLOBBER(eol)}; } } finally { D.2498 = {CLOBBER(eol)}; } } catch { if (D.2516 != 0) goto <D.2517>; else goto <D.2518>; <D.2517>: A::~A (&D.2499.e); goto <D.2519>; <D.2518>: <D.2519>: } The CLOBBER for D.2499 is essentially only emitted on the non-exceptional path, if B::B or baz throws, then there is no CLOBBER for it but there is a conditional destructor A::~A (&D.2499.e). Now, ehcleanup1 sink_clobbers optimization assumes that clobbers in the EH cases are emitted after last use and so sinks the D.2499 = {CLOBBER(eol)}; later, so we then have # _3 = PHI <1(3), 0(9)> <L2>: D.2499 ={v} {CLOBBER(eol)}; D.2498 ={v} {CLOBBER(eol)}; if (_3 != 0) goto <bb 11>; [INV] else goto <bb 15>; [INV] <bb 11> : _35 = D.2499.a; if (&D.2499.b != _35) where that _35 = D.2499.a comes from inline expansion of the A::~A dtor, and that is a load from a clobbered memory. Now, what the gimplifier sees in this case is a CLEANUP_POINT_EXPR with somewhere inside of it a TARGET_EXPR for D.2499 (with the C::~C (&D.2499) cleanup) which in its TARGET_EXPR_INITIAL has another TARGET_EXPR for D.2516 bool flag which has CLEANUP_EH_ONLY which performs that conditional A::~A (&D.2499.e) call. The following patch ensures that CLOBBERs (and asan poisoning) are emitted after even those gimple_push_cleanup pushed cleanups from within the TARGET_EXPR_INITIAL gimplification (i.e. the last point where the slot could be in theory used). In my first version of the patch I've done it by just moving the /* Add a clobber for the temporary going out of scope, like gimplify_bind_expr. */ if (gimplify_ctxp->in_cleanup_point_expr && needs_to_live_in_memory (temp)) { ... } block earlier in gimplify_target_expr, but that regressed a couple of tests where temp is marked TREE_ADDRESSABLE only during (well, very early during that) the gimplification of TARGET_EXPR_INITIAL, so we didn't emit e.g. on pr80032.C or stack2.C tests any clobbers for the slots and thus stack slot reuse wasn't performed. So that we don't regress those tests, this patch gimplifies TARGET_EXPR_INITIAL as before, but doesn't emit it directly into pre_p, emits it into a temporary sequence. Then emits the CLOBBER cleanup into pre_p, then asan poisoning if needed, then appends the TARGET_EXPR_INITIAL temporary sequence and finally adds TARGET_EXPR_CLEANUP gimple_push_cleanup. The earlier a GIMPLE_WCE appears in the sequence, the outer try/finally or try/catch it is. So, with this patch the part of the testcase in gimple dump cited above looks instead like: try { D.2499.e = B::qux (&h); [return slot optimization] D.2516 = 1; try { try { B::B (&D.2498, &h); _2 = baz (&D.2498); D.2499.f = _2; D.2516 = 0; try { bar (&D.2499); } finally { C::~C (&D.2499); } } finally { D.2498 = {CLOBBER(eol)}; } } catch { if (D.2516 != 0) goto <D.2517>; else goto <D.2518>; <D.2517>: A::~A (&D.2499.e); goto <D.2519>; <D.2518>: <D.2519>: } } finally { D.2499 = {CLOBBER(eol)}; } 2022-03-17 Jakub Jelinek <jakub@redhat.com> PR middle-end/103984 * gimplify.cc (gimplify_target_expr): Gimplify type sizes and TARGET_EXPR_INITIAL into a temporary sequence, then push clobbers and asan unpoisioning, then append the temporary sequence and finally the TARGET_EXPR_CLEANUP clobbers. * g++.dg/opt/pr103984.C: New test.
2022-03-17Enhance further testcases to verify Openacc 'kernels' decompositionThomas Schwinge6-11/+67
gcc/testsuite/ * c-c++-common/goacc-gomp/nesting-1.c: Enhance. * c-c++-common/goacc/kernels-loop-g.c: Likewise. * c-c++-common/goacc/nesting-1.c: Likewise. * gcc.dg/goacc/nested-function-1.c: Likewise. * gfortran.dg/goacc/common-block-3.f90: Likewise. * gfortran.dg/goacc/nested-function-1.f90: Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c: Enhance. * testsuite/libgomp.oacc-c-c++-common/kernels-loop-g.c: Likewise. * testsuite/libgomp.oacc-fortran/if-1.f90: Likewise.
2022-03-17Enhance further testcases to verify handling of OpenACC privatization level ↵Thomas Schwinge2-6/+16
[PR90115] As originally introduced in commit 11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC privatization] Largely extend diagnostics and corresponding testsuite coverage [PR90115]". PR middle-end/90115 gcc/testsuite/ * c-c++-common/goacc-gomp/nesting-1.c: Enhance. * gfortran.dg/goacc/common-block-3.f90: Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c: Enhance. * testsuite/libgomp.oacc-fortran/if-1.f90: Likewise.
2022-03-17Daily bump.GCC Administrator6-1/+240