aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2022-08-17Reset root oracle from path_oracle::reset_path.Aldy Hernandez3-6/+10
When we cross a backedge in the path solver, we reset the path relations and nuke the root oracle. However, we forget to reset it for the next path. This is causing us to miss threads because subsequent paths will have no root oracle to use. With this patch we get 201 more threads in the threadfull passes in my .ii files and 118 more overall (DOM gets less because threadfull runs before). Normally, I'd recommend this for the GCC 12 branch, but considering how sensitive other passes are to jump threading, and that there is no PR associated with this, perhaps we should leave this out. Up to the release maintainers of course. gcc/ChangeLog: * gimple-range-path.cc (path_range_query::compute_ranges_in_block): Remove set_root_oracle call. (path_range_query::compute_ranges): Pass ranger oracle to reset_path. * value-relation.cc (path_oracle::reset_path): Set root oracle. * value-relation.h (path_oracle::reset_path): Add root oracle argument.
2022-08-17c++: Extend -Wredundant-move for const-qual objects [PR90428]Marek Polacek4-60/+162
In this PR, Jon suggested extending the -Wredundant-move warning to warn when the user is moving a const object as in: struct T { }; T f(const T& t) { return std::move(t); } where the std::move is redundant, because T does not have a T(const T&&) constructor (which is very unlikely). Even with the std::move, T(T&&) would not be used because it would mean losing the const. Instead, T(const T&) will be called. I had to restructure the function a bit, but it's better now. This patch depends on my other recent patches to maybe_warn_pessimizing_move. PR c++/90428 gcc/cp/ChangeLog: * typeck.cc (can_do_rvo_p): Rename to ... (can_elide_copy_prvalue_p): ... this. (maybe_warn_pessimizing_move): Extend the -Wredundant-move warning to warn about std::move on a const-qualified object. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wredundant-move1.C: Adjust dg-warning. * g++.dg/cpp0x/Wredundant-move9.C: Likewise. * g++.dg/cpp0x/Wredundant-move10.C: New test.
2022-08-17c++: Tweak for -Wpessimizing-move in templates [PR89780]Marek Polacek7-8/+114
In my previous patches I've been extending our std::move warnings, but this tweak actually dials it down a little bit. As reported in bug 89780, it's questionable to warn about expressions in templates that were type-dependent, but aren't anymore because we're instantiating the template. As in, template <typename T> Dest withMove() { T x; return std::move(x); } template Dest withMove<Dest>(); // #1 template Dest withMove<Source>(); // #2 Saying that the std::move is pessimizing for #1 is not incorrect, but it's not useful, because removing the std::move would then pessimize #2. So the user can't really win. At the same time, disabling the warning just because we're in a template would be going too far, I still want to warn for template <typename> Dest withMove() { Dest x; return std::move(x); } because the std::move therein will be pessimizing for any instantiation. So I'm using the suppress_warning machinery to that effect. Problem: I had to add a new group to nowarn_spec_t, otherwise suppressing the -Wpessimizing-move warning would disable a whole bunch of other warnings, which we really don't want. PR c++/89780 gcc/cp/ChangeLog: * pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Maybe suppress -Wpessimizing-move. * typeck.cc (maybe_warn_pessimizing_move): Don't issue warnings if they are suppressed. (check_return_expr): Disable -Wpessimizing-move when returning a dependent expression. gcc/ChangeLog: * diagnostic-spec.cc (nowarn_spec_t::nowarn_spec_t): Handle OPT_Wpessimizing_move and OPT_Wredundant_move. * diagnostic-spec.h (nowarn_spec_t): Add NW_REDUNDANT enumerator. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wpessimizing-move3.C: Remove dg-warning. * g++.dg/cpp0x/Wredundant-move2.C: Likewise.
2022-08-17c++: Extend -Wpessimizing-move to other contextsMarek Polacek6-28/+120
In my recent patch which enhanced -Wpessimizing-move so that it warns about class prvalues too I said that I'd like to extend it so that it warns in more contexts where a std::move can prevent copy elision, such as: T t = std::move(T()); T t(std::move(T())); T t{std::move(T())}; T t = {std::move(T())}; void foo (T); foo (std::move(T())); This patch does that by adding two maybe_warn_pessimizing_move calls. These must happen before we've converted the initializers otherwise the std::move will be buried in a TARGET_EXPR. PR c++/106276 gcc/cp/ChangeLog: * call.cc (build_over_call): Call maybe_warn_pessimizing_move. * cp-tree.h (maybe_warn_pessimizing_move): Declare. * decl.cc (build_aggr_init_full_exprs): Call maybe_warn_pessimizing_move. * typeck.cc (maybe_warn_pessimizing_move): Handle TREE_LIST and CONSTRUCTOR. Add a bool parameter and use it. Adjust a diagnostic message. (check_return_expr): Adjust the call to maybe_warn_pessimizing_move. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wpessimizing-move7.C: Add dg-warning. * g++.dg/cpp0x/Wpessimizing-move8.C: New test.
2022-08-17fortran: Add -static-libquadmath support [PR46539]Jakub Jelinek6-3/+35
The following patch is a revival of the https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg00771.html patch. While trunk configured against recent glibc and with linker --as-needed support doesn't really need to link against -lquadmath anymore, there are still other targets where libquadmath is still in use. As has been discussed, making -static-libgfortran imply statically linking both libgfortran and libquadmath is undesirable because of the significant licensing differences between the 2 libraries. Compared to the 2014 patch, this one doesn't handle -lquadmath addition in the driver, which to me looks incorrect, libgfortran configure determines where in libgfortran.spec -lquadmath should be present if at all and with what it should be wrapped, but analyzes gfortran -### -static-libgfortran stderr and based on that figures out what gcc/configure.ac determined. 2022-08-17 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org> Jakub Jelinek <jakub@redhat.com> PR fortran/46539 gcc/ * common.opt (static-libquadmath): New option. * gcc.cc (driver_handle_option): Always accept -static-libquadmath. * config/darwin.h (LINK_SPEC): Handle -static-libquadmath. gcc/fortran/ * lang.opt (static-libquadmath): New option. * invoke.texi (-static-libquadmath): Document it. * options.cc (gfc_handle_option): Error out if -static-libquadmath is passed but we do not support it. libgfortran/ * acinclude.m4 (LIBQUADSPEC): From $FC -static-libgfortran -### output determine -Bstatic/-Bdynamic, -bstatic/-bdynamic, -aarchive_shared/-adefault linker support or Darwin remapping of -lgfortran to libgfortran.a%s and use that around or instead of -lquadmath in LIBQUADSPEC. * configure: Regenerated. Co-Authored-By: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
2022-08-17Fortran: OpenMP fix declare simd inside modules and absent linear step ↵Tobias Burnus4-3/+140
[PR106566] gcc/fortran/ChangeLog: PR fortran/106566 * openmp.cc (gfc_match_omp_clauses): Fix setting linear-step value to 1 when not specified. (gfc_match_omp_declare_simd): Accept module procedures. gcc/testsuite/ChangeLog: PR fortran/106566 * gfortran.dg/gomp/declare-simd-4.f90: New test. * gfortran.dg/gomp/declare-simd-5.f90: New test. * gfortran.dg/gomp/declare-simd-6.f90: New test.
2022-08-17OpenMP requires: Fix diagnostic filename corner caseTobias Burnus1-0/+5
The issue occurs when there is, e.g., main._omp_fn.0 in two files with different OpenMP requires clauses. The function entries in the offload table ends up having the same decl tree and, hence, the diagnostic showed the same filename for both. Solution: Use the .o filename in this case. Note that the issue does not occur with same-named 'static' functions and without the fatal error from the requires diagnostic, there would be later a linker error due to having two 'main'. gcc/ * lto-cgraph.cc (input_offload_tables): Improve requires diagnostic when filenames come out identically.
2022-08-17OpenMP: Fix var replacement with 'simd' and linear-step vars [PR106548]Tobias Burnus1-0/+2
gcc/ChangeLog: PR middle-end/106548 * omp-low.cc (lower_rec_input_clauses): Use build_outer_var_ref for 'simd' linear-step values that are variable. libgomp/ChangeLog: PR middle-end/106548 * testsuite/libgomp.c/linear-2.c: New test.
2022-08-17OpenMP/C++: Allow classes with static members to be mappable [PR104493]Tobias Burnus15-100/+61
As this is the last lang-specific user of the omp_mappable_type hook, the hook is removed, keeping only a generic omp_mappable_type for incomplete types (or error_node). PR c++/104493 gcc/c/ChangeLog: * c-decl.cc (c_decl_attributes, finish_decl): Call omp_mappable_type instead of removed langhook. * c-typeck.cc (c_finish_omp_clauses): Likewise. gcc/cp/ChangeLog: * cp-objcp-common.h (LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. * cp-tree.h (cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. * decl2.cc (cp_omp_mappable_type_1, cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. (cplus_decl_attributes): Call omp_mappable_type instead of removed langhook. * decl.cc (cp_finish_decl): Likewise; call cxx_incomplete_type_inform in lieu of cp_omp_emit_unmappable_type_notes. * semantics.cc (finish_omp_clauses): Likewise. gcc/ChangeLog: * gimplify.cc (omp_notice_variable): Call omp_mappable_type instead of removed langhook. * omp-general.h (omp_mappable_type): New prototype. * omp-general.cc (omp_mappable_type): New; moved from ... * langhooks.cc (lhd_omp_mappable_type): ... here. * langhooks-def.h (lhd_omp_mappable_type, LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Remote the latter. * langhooks.h (struct lang_hooks_for_types): Remove omp_mappable_type. gcc/testsuite/ChangeLog: * g++.dg/gomp/unmappable-1.C: Remove dg-error; remove dg-note no longer shown as TYPE_MAIN_DECL is NULL. * c-c++-common/gomp/map-incomplete-type.c: New test. Co-authored-by: Chung-Lin Tang <cltang@codesourcery.com>
2022-08-17arm: Define with_float to hard when target name ends with hfChristophe Lyon1-0/+7
On arm, the --with-float= configure option is used to define include files search path (among other things). However, when targeting arm-linux-gnueabihf, one would expect to automatically default to the hard-float ABI, but this is not the case. As a consequence, GCC bootstrap fails on an arm-linux-gnueabihf target if --with-float=hard is not used. This patch checks if the target name ends with 'hf' and defines with_float to hard if not already defined. This is achieved in gcc/config.gcc, just before selecting the default CPU depending on the $with_float value. 2022-08-17 Christophe Lyon <christophe.lyon@arm.com> gcc/ * config.gcc (arm): Define with_float to hard if target name ends with 'hf'.
2022-08-17Refactor back_threader_profitabilityRichard Biener1-158/+199
The following refactors profitable_path_p in the backward threader, splitting out parts that can be computed once the exit block is known, parts that contiguously update and that can be checked allowing for the path to be later identified as FSM with larger limits, possibly_profitable_path_p, and final checks done when the whole path is known, profitable_path_p. I've removed the back_threader_profitability instance from the back_threader class and instead instantiate it once per path discovery. I've kept the size compute non-incremental to simplify the patch and not worry about unwinding. There's key changes to previous behavior - namely we apply the param_max_jump_thread_duplication_stmts early only when we know the path cannot become an FSM one (multiway + thread through latch) but make sure to elide the path query when we we didn't yet discover that but are over this limit. Similarly the speed limit is now used even when we did not yet discover a hot BB on the path. Basically the idea is to only stop path discovery when we know the path will never become profitable but avoid the expensive path range query when we know it's currently not. I've done a few cleanups, merging functions, on the way. * tree-ssa-threadbackward.cc (back_threader_profitability): Split profitable_path_p into possibly_profitable_path_p and itself, keep state as new members. (back_threader::m_profit): Remove. (back_threader::find_paths): Likewise. (back_threader::maybe_register_path): Take profitability instance as parameter. (back_threader::find_paths_to_names): Likewise. Use possibly_profitable_path_p and avoid the path range query when the path is currently too large. (back_threader::find_paths): Fold into ... (back_threader::maybe_thread_block): ... this. (get_gimple_control_stmt): Remove. (back_threader_profitability::possibly_profitable_path_p): Split out from profitable_path_p, do early profitability checks. (back_threader_profitability::profitable_path_p): Do final profitability path after the taken edge has been determined.
2022-08-17LoongArch: Provide fmin/fmax RTL patternXi Ruoyao2-0/+48
We already had smin/smax RTL pattern using fmin/fmax instruction. But for smin/smax, it's unspecified what will happen if either operand is NaN. So we would generate calls to libc fmin/fmax functions with -fno-finite-math-only (the default for all optimization levels expect -Ofast). But, LoongArch fmin/fmax instruction is IEEE-754-2008 conformant so we can also use the instruction for fmin/fmax pattern and avoid the library function call. gcc/ChangeLog: * config/loongarch/loongarch.md (fmax<mode>3): New RTL pattern. (fmin<mode>3): Likewise. gcc/testsuite/ChangeLog: * gcc.target/loongarch/fmax-fmin.c: New test.
2022-08-16Abstract interesting ssa-names from GORI.Andrew MacLeod3-28/+49
Provide a routine to pick out the ssa-names from interesting statements. * gimple-range-fold.cc (gimple_range_ssa_names): New. * gimple-range-fold.h (gimple_range_ssa_names): New prototype. * gimple-range-gori.cc (range_def_chain::get_def_chain): Move code to new routine.
2022-08-17Daily bump.GCC Administrator8-1/+236
2022-08-16c++: remove some xfailsJason Merrill2-3/+3
These tests are now passing. gcc/testsuite/ChangeLog: * g++.dg/warn/Wstringop-overflow-4.C: Only xfail for C++98. * g++.target/i386/bfloat_cpp_typecheck.C: Remove xfail.
2022-08-16c++: Fix pragma suppression of -Wc++20-compat diagnostics [PR106423]Tom Honermann5-2/+41
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode" (see handle_pragma_diagnostic_early) for the C++ frontend and, as such, require that the target diagnostic option be enabled for the preprocessor (see c_option_is_from_cpp_diagnostics). This change modifies the -Wc++20-compat option definition to register it as a preprocessor option so that its associated diagnostics can be suppressed. The changes also implicitly disable the option in C++20 and later modes. These changes are consistent with the definition of the -Wc++11-compat option. This support is motivated by the need to suppress the following diagnostic otherwise issued in C++17 and earlier modes due to the char8_t typedef present in the uchar.h header file in glibc 2.36. warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat] Tests are added to validate suppression of both -Wc++11-compat and -Wc++20-compat related diagnostics (fixes were only needed for the C++20 case). PR c++/106423 gcc/c-family/ChangeLog: * c-opts.cc (c_common_post_options): Disable -Wc++20-compat diagnostics in C++20 and later. * c.opt (Wc++20-compat): Enable hooks for the preprocessor. gcc/cp/ChangeLog: * parser.cc (cp_lexer_saving_tokens): Add comment regarding diagnostic requirements. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/keywords2.C: New test. * g++.dg/cpp2a/keywords2.C: New test. libcpp/ChangeLog: * include/cpplib.h (cpp_warning_reason): Add CPP_W_CXX20_COMPAT. * init.cc (cpp_create_reader): Add cpp_warn_cxx20_compat.
2022-08-16docs: remove link to www.bullfreeware.com from installMartin Liska1-4/+0
As mentioned at https://gcc.gnu.org/PR106637#c2, the discontinued providing binaries. PR target/106637 gcc/ChangeLog: * doc/install.texi: Remove link to www.bullfreeware.com
2022-08-16RISC-V: Support zfh and zfhmin extensionKito Cheng15-9/+279
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified in Jan. 2022[1]: - Zfh has full set of operation like F or D for single or double precision. - Zfhmin has only provide minimal support for half precision operation, like conversion, load, store and move instructions. [1] https://github.com/riscv/riscv-isa-manual/commit/b35a54079e0da11740ce5b1e6db999d1d5172768 gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add zfh and zfhmin. (riscv_ext_version_table): Ditto. (riscv_ext_flag_table): Ditto. * config/riscv/riscv-opts.h (MASK_ZFHMIN): New. (MASK_ZFH): Ditto. (TARGET_ZFHMIN): Ditto. (TARGET_ZFH): Ditto. * config/riscv/riscv.cc (riscv_output_move): Handle HFmode move for zfh and zfhmin. (riscv_emit_float_compare): Handle HFmode. * config/riscv/riscv.md (ANYF): Add HF. (SOFTF): Add HF. (load): Ditto. (store): Ditto. (truncsfhf2): New. (truncdfhf2): Ditto. (extendhfsf2): Ditto. (extendhfdf2): Ditto. (*movhf_hardfloat): Ditto. (*movhf_softfloat): Make sure not ZFHMIN. * config/riscv/riscv.opt (riscv_zf_subext): New. gcc/testsuite/ChangeLog: * gcc.target/riscv/_Float16-zfh-1.c: New. * gcc.target/riscv/_Float16-zfh-2.c: Ditto. * gcc.target/riscv/_Float16-zfh-3.c: Ditto. * gcc.target/riscv/_Float16-zfhmin-1.c: Ditto. * gcc.target/riscv/_Float16-zfhmin-2.c: Ditto. * gcc.target/riscv/_Float16-zfhmin-3.c: Ditto. * gcc.target/riscv/arch-16.c: Ditto. * gcc.target/riscv/arch-17.c: Ditto. * gcc.target/riscv/predef-21.c: Ditto. * gcc.target/riscv/predef-22.c: Ditto.
2022-08-16RISC-V: Support _Float16 type.Kito Cheng10-18/+291
RISC-V decide use _Float16 as primary IEEE half precision type, and this already become part of psABI, this patch has added folloing support for _Float16: - Soft-float support for _Float16. - Make sure _Float16 available on C++ mode. - Name mangling for _Float16 on C++ mode. gcc/ChangeLog * config/riscv/riscv-builtins.cc: include stringpool.h (riscv_float16_type_node): New. (riscv_init_builtin_types): Ditto. (riscv_init_builtins): Call riscv_init_builtin_types. * config/riscv/riscv-modes.def (HF): New. * config/riscv/riscv.cc (riscv_output_move): Handle HFmode. (riscv_mangle_type): New. (riscv_scalar_mode_supported_p): Ditto. (riscv_libgcc_floating_mode_supported_p): Ditto. (riscv_excess_precision): Ditto. (riscv_floatn_mode): Ditto. (riscv_init_libfuncs): Ditto. (TARGET_MANGLE_TYPE): Ditto. (TARGET_SCALAR_MODE_SUPPORTED_P): Ditto. (TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Ditto. (TARGET_INIT_LIBFUNCS): Ditto. (TARGET_C_EXCESS_PRECISION): Ditto. (TARGET_FLOATN_MODE): Ditto. * config/riscv/riscv.md (mode): Add HF. (softload): Add HF. (softstore): Ditto. (fmt): Ditto. (UNITMODE): Ditto. (movhf): New. (*movhf_softfloat): New. libgcc/ChangeLog: * config/riscv/sfp-machine.h (_FP_NANFRAC_H): New. (_FP_NANFRAC_H): Ditto. (_FP_NANSIGN_H): Ditto. * config/riscv/t-softfp32 (softfp_extensions): Add HF related routines. (softfp_truncations): Ditto. (softfp_extras): Ditto. * config/riscv/t-softfp64 (softfp_extras): Add HF related routines. gcc/testsuite/ChangeLog: * g++.target/riscv/_Float16.C: New. * gcc.target/riscv/_Float16-soft-1.c: Ditto. * gcc.target/riscv/_Float16-soft-2.c: Ditto. * gcc.target/riscv/_Float16-soft-3.c: Ditto. * gcc.target/riscv/_Float16-soft-4.c: Ditto. * gcc.target/riscv/_Float16.c: Ditto.
2022-08-16Stop backwards thread discovery when leaving a loopRichard Biener1-0/+6
The backward threader copier cannot deal with the situation of copying blocks belonging to different loops and will reject those paths late. The following uses this to prune path discovery, saving on compile-time. Note the off-loop block is still considered as entry edge origin. * tree-ssa-threadbackward.cc (back_threader::find_paths_to_names): Do not walk further if we are leaving the current loop.
2022-08-16driver: fix environ corruption after putenv() [PR106624]Sergei Trofimovich1-1/+1
The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out jobserver_active_p" slightly changed `putenv()` use from allocating to non-allocating: -xputenv (concat ("MAKEFLAGS=", dup, NULL)); +xputenv (jinfo.skipped_makeflags.c_str ()); `xputenv()` (and `putenv()`) don't copy strings and only store the pointer in the `environ` global table. As a result `environ` got corrupted as soon as `jinfo.skipped_makeflags` store got deallocated. This started causing bootstrap crashes in `execv()` calls: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address The change restores memory allocation for `xputenv()` argument. gcc/ PR driver/106624 * gcc.cc (driver::detect_jobserver): Allocate storage xputenv() argument using xstrdup().
2022-08-16c++: Implement P2327R1 - De-deprecating volatile compound operationsJakub Jelinek5-14/+28
From what I can see, this has been voted in as a DR and as it means we warn less often than before in -std={gnu,c}++2{0,3} modes or with -Wvolatile, I wonder if it shouldn't be backported to affected release branches as well. 2022-08-16 Jakub Jelinek <jakub@redhat.com> * typeck.cc (cp_build_modify_expr): Implement P2327R1 - De-deprecating volatile compound operations. Don't warn for |=, &= or ^= with volatile lhs. * expr.cc (mark_use) <case MODIFY_EXPR>: Adjust warning wording, leave out simple. * g++.dg/cpp2a/volatile1.C: Adjust for de-deprecation of volatile compound |=, &= and ^= operations. * g++.dg/cpp2a/volatile3.C: Likewise. * g++.dg/cpp2a/volatile5.C: Likewise.
2022-08-16d: Update DIP links in gdc documentation to point at upstream repositoryIain Buclaw1-6/+10
The wiki links probably worked at some point in the distant past, but now the official location of tracking all D Improvement Proposals is on the upstream dlang/DIPs GitHub repository. PR d/106638 gcc/d/ChangeLog: * gdc.texi: Update DIP links to point at upstream dlang/DIPs repository.
2022-08-16Rename imports nomenclature in path_range_query to exit_dependencies.Aldy Hernandez2-47/+51
The purpose of this change is to disambiguate the imports name with its use in GORI. gcc/ChangeLog: * gimple-range-path.cc (path_range_query::import_p): Rename to... (path_range_query::exit_dependency_p): ...this. (path_range_query::dump): Rename imports to exit dependencies. (path_range_query::compute_ranges_in_phis): Same. (path_range_query::compute_ranges_in_block): Same. (path_range_query::adjust_for_non_null_uses): Same. (path_range_query::compute_ranges): Same. (path_range_query::compute_phi_relations): Same. (path_range_query::add_to_imports): Rename to... (path_range_query::add_to_exit_dependencies): ...this. (path_range_query::compute_imports): Rename to... (path_range_query::compute_exit_dependencies): ...this. * gimple-range-path.h (class path_range_query): Rename imports to exit dependencies.
2022-08-16VR: mitigate -Wfinal-dtor-non-final-class clang warningsMartin Liska1-2/+2
Fixes: gcc/value-range-storage.h:129:40: warning: class with destructor marked 'final' cannot be inherited from [-Wfinal-dtor-non-final-class] gcc/value-range-storage.h:146:36: warning: class with destructor marked 'final' cannot be inherited from [-Wfinal-dtor-non-final-class] gcc/ChangeLog: * value-range-storage.h (class obstack_vrange_allocator): Mark the class as final. (class ggc_vrange_allocator): Likewise.
2022-08-16VR: add more virtual dtorsMartin Liska2-0/+4
Add 2 virtual destructors in order to address: gcc/alloc-pool.h:522:5: warning: destructor called on non-final 'value_range_equiv' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor] gcc/ggc.h:166:3: warning: destructor called on non-final 'int_range<1>' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor] gcc/ChangeLog: * value-range-equiv.h (class value_range_equiv): Add virtual destructor. * value-range.h: Likewise.
2022-08-16middle-end/106630 - avoid ping-pong between extract_muldiv and match.pdRichard Biener2-1/+14
The following avoids ping-pong between the match.pd pattern changing (sizetype) ((a_9 + 1) * 48) to (sizetype)(a_9 + 1) * 48 and extract_muldiv performing the reverse transform by restricting the match.pd pattern to narrowing conversions as the comment indicates. PR middle-end/106630 * match.pd ((T)(x * CST) -> (T)x * CST): Restrict to narrowing conversions. * gcc.dg/torture/pr106630.c: New testcase.
2022-08-16VR: add missing override keyworksMartin Liska1-2/+2
Address: gcc/value-range-equiv.h:57:8: warning: 'set_undefined' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] gcc/value-range-equiv.h:58:8: warning: 'set_varying' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] gcc/ChangeLog: * value-range-equiv.h (class value_range_equiv):
2022-08-16analyzer: add more final override keywordsMartin Liska2-3/+4
gcc/analyzer/ChangeLog: * region-model.cc: Fix -Winconsistent-missing-override clang warning. * region.h: Likewise.
2022-08-16i386: add 'final' and 'override' to scalar_chainMartin Liska1-2/+2
In c3ed9e0d6e96d8697e4bab994f8acbc5506240ee, David added some "final override" and since that there are 2 new warnings that need the same treatment: gcc/config/i386/i386-features.h:186:8: warning: 'convert_op' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] gcc/config/i386/i386-features.h:186:8: warning: 'convert_op' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] gcc/config/i386/i386-features.h:199:8: warning: 'convert_op' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] gcc/config/i386/i386-features.h:199:8: warning: 'convert_op' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] gcc/ChangeLog: * config/i386/i386-features.h (class general_scalar_chain): Add final override for a method. (class timode_scalar_chain): Likewise.
2022-08-16docs: fix link destinationMartin Liska1-3/+3
gcc/fortran/ChangeLog: * gfortran.texi: Fix link destination to a valid URL.
2022-08-16Adjust max-jump-thread-paths docsRichard Biener1-3/+3
The following fixes spelling and changes edge degree for number of incoming edges. * doc/invoke.texi (max-jump-thread-paths): Adjust.
2022-08-16jobserver: fix fifo mode by opening pipe in proper modeMartin Liska1-1/+1
The current jobserver_info relies on non-blocking FDs, thus one the pipe in such mode. gcc/ChangeLog: * opts-common.cc (jobserver_info::connect): Open fifo in non-blocking mode.
2022-08-16rs6000: Adjust mov optabs for opaque modes [PR103353]Kewen.Lin2-6/+55
As PR103353 shows, we may want to continue to expand built-in function __builtin_vsx_lxvp, even if we have already emitted error messages about some missing required conditions. As shown in that PR, without one explicit mov optab on OOmode provided, it would call emit_move_insn recursively. So this patch is to allow the mov pattern to be generated during expanding phase if compiler has already seen errors. PR target/103353 gcc/ChangeLog: * config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition check to preparation statements and add handlings for !TARGET_MMA. (define_expand movxo): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr103353.c: New test.
2022-08-16vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]Kewen Lin3-0/+109
As PR106322 shows, in some cases for some vector type whose TYPE_MODE is a scalar integral mode instead of a vector mode, it's possible to obtain wrong target support information when querying with the scalar integral mode. For example, for the test case in PR106322, on ppc64 32bit vectorizer gets vector type "vector(2) short unsigned int" for scalar type "short unsigned int", its mode is SImode instead of V2HImode. The target support querying checks umul_highpart optab with SImode and considers it's supported, then vectorizer further generates .MULH IFN call for that vector type. Unfortunately it's wrong to use SImode support for that vector type multiply highpart here. This patch is to teach vectorizable_call analysis not to allow vect_emulated_vector_p type for both vectype_in and vectype_out as Richi suggested. PR tree-optimization/106322 gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_call): Don't allow vect_emulated_vector_p type for both vectype_in and vectype_out. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106322.c: New test. * gcc.target/powerpc/pr106322.c: New test.
2022-08-15xtensa: Turn on -fsplit-wide-types-early by defaultTakayuki 'January June' Suwa1-0/+2
Since GCC10, the "subreg2" optimization pass was no longer tied to enabling "subreg1" unless -fsplit-wide-types-early was turned on (PR88233). However on the Xtensa port, the lack of "subreg2" can degrade the quality of the output code, especially for those that produce many D[FC]mode pseudos. This patch turns on -fsplit-wide-types-early by default in order to restore the previous behavior. gcc/ChangeLog: * common/config/xtensa/xtensa-common.cc (xtensa_option_optimization_table): Add OPT_fsplit_wide_types_early for OPT_LEVELS_ALL in order to restore pre-GCC10 behavior.
2022-08-16Daily bump.GCC Administrator6-1/+301
2022-08-15d: Defer compiling inline definitions until after the module has finished.Iain Buclaw3-11/+32
This is to prevent the case of when generating the methods of a struct type, we don't accidentally emit an inline function that references it, as the outer struct itself would still be incomplete. gcc/d/ChangeLog: * d-tree.h (d_defer_declaration): Declare. * decl.cc (function_needs_inline_definition_p): Defer checking DECL_UNINLINABLE and DECL_DECLARED_INLINE_P. (maybe_build_decl_tree): Call d_defer_declaration instead of build_decl_tree. * modules.cc (deferred_inline_declarations): New variable. (build_module_tree): Set deferred_inline_declarations and a handle declarations pushed to it. (d_defer_declaration): New function.
2022-08-15d: Fix internal compiler error: Segmentation fault at gimple-expr.cc:88Iain Buclaw4-1/+64
Because complex types are deprecated in the language, the new way to expose native complex types is by defining an enum with a basetype of a library-defined struct that is implicitly treated as-if it is native. As casts are not implicitly added by the front-end when downcasting from enum to its underlying type, we must insert an explicit cast during the code generation pass. PR d/106623 gcc/d/ChangeLog: * d-codegen.cc (underlying_complex_expr): New function. (d_build_call): Handle passing native complex objects as the library-defined equivalent. * d-tree.h (underlying_complex_expr): Declare. * expr.cc (ExprVisitor::visit (DotVarExp *)): Call underlying_complex_expr instead of build_vconvert. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr106623.d: New test.
2022-08-15d: Build internal TypeInfo types when module name is "object"Iain Buclaw2-2/+13
If for whatever reason the module declaration doesn't exist in the object file, ensure that the internal definitions for TypeInfo and TypeInfo_Class are still created, otherwise an ICE could occur later if they are required for a run-time helper call. gcc/d/ChangeLog: * d-compiler.cc (Compiler::onParseModule): Call create_tinfo_types when module name is object. * typeinfo.cc (create_tinfo_types): Add guard for multiple invocations.
2022-08-15d: Field names of anonymous delegates should be same as regular delegate types.Iain Buclaw1-2/+2
Doesn't change anything in the code generation or ABI, but makes it consistent with regular delegates as names would match up when inspecting tree dumps. gcc/d/ChangeLog: * d-codegen.cc (build_delegate_cst): Give anonymous delegate field names same as per ABI spec.
2022-08-15analyzer: fix direction of -Wanalyzer-out-of-bounds note [PR106626]David Malcolm5-2/+220
Fix a read/write typo. Also, add more test coverage of -Wanalyzer-out-of-bounds to help establish a baseline for experiments on tweaking the wording of the warning (PR analyzer/106626). gcc/analyzer/ChangeLog: PR analyzer/106626 * region-model.cc (buffer_overread::emit): Fix copy&paste error in direction of the access in the note. gcc/testsuite/ChangeLog: PR analyzer/106626 * gcc.dg/analyzer/out-of-bounds-read-char-arr.c: New test. * gcc.dg/analyzer/out-of-bounds-read-int-arr.c: New test. * gcc.dg/analyzer/out-of-bounds-write-char-arr.c: New test. * gcc.dg/analyzer/out-of-bounds-write-int-arr.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-08-15analyzer: better fix for -Wanalyzer-use-of-uninitialized-value [PR106573]David Malcolm1-3/+1
gcc/analyzer/ChangeLog: PR analyzer/106573 * region-model.cc (region_model::on_call_pre): Use check_call_args when ensuring that we call get_arg_svalue on all args. Remove redundant call from handling for stdio builtins. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-08-15Check for undefined and varying first.Andrew MacLeod2-19/+46
Rearrange order in irange:set to ensure all POLY_INTs map to varying. PR tree-optimization/106621 gcc/ * value-range.cc (irange::set): Check for POLY_INT_CST early. gcc/testsuite/ * gcc.dg/pr106621.c
2022-08-15analyzer: fix for ICE in sm-fd.cc [PR106551]Immad Mir2-2/+12
This patch fixes the ICE caused by valid_to_unchecked_state in sm-fd.cc by exiting early if first argument of any "dup" functions is invalid. gcc/analyzer/ChangeLog: PR analyzer/106551 * sm-fd.cc (check_for_dup): exit early if first argument is invalid for all dup functions. gcc/testsuite/ChangeLog: PR analyzer/106551 * gcc.dg/analyzer/fd-dup-1.c: New testcase. Signed-off-by: Immad Mir <mirimmad@outlook.com>
2022-08-15Support shifts and rotates by integer constants in TImode STV on x86_64.Roger Sayle2-6/+156
This patch adds support for converting 128-bit TImode shifts and rotates to SSE equivalents using V1TImode during the TImode STV pass. Previously, only logical shifts by multiples of 8 were handled (from my patch earlier this month). As an example of the benefits, the following rotate by 32-bits: unsigned __int128 a, b; void rot32() { a = (b >> 32) | (b << 96); } when compiled on x86_64 with -O2 previously generated: movq b(%rip), %rax movq b+8(%rip), %rdx movq %rax, %rcx shrdq $32, %rdx, %rax shrdq $32, %rcx, %rdx movq %rax, a(%rip) movq %rdx, a+8(%rip) ret with this patch, now generates: movdqa b(%rip), %xmm0 pshufd $57, %xmm0, %xmm0 movaps %xmm0, a(%rip) ret [which uses a V4SI permutation for those that don't read SSE]. This should help 128-bit cryptography codes, that interleave XORs with rotations (but that don't use additions or subtractions). 2022-08-15 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * config/i386/i386-features.cc (timode_scalar_chain::compute_convert_gain): Provide costs for shifts and rotates. (timode_scalar_chain::convert_insn): Handle ASHIFTRT, ROTATERT and ROTATE just like existing ASHIFT and LSHIFTRT cases. (timode_scalar_to_vector_candidate_p): Handle all shifts and rotates by integer constants between 0 and 127. gcc/testsuite/ChangeLog * gcc.target/i386/sse4_1-stv-9.c: New test case.
2022-08-15Improved gain calculation for COMPARE to 0 or -1 in TImode STV on x86_64.Roger Sayle1-0/+17
This patch tweaks timode_scalar_chain::compute_convert_gain to provide more accurate costs for converting TImode comparisons against zero or minus 1 to V1TImode equivalents. 2022-08-15 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * config/i386/i386-features.cc (timode_scalar_chain::compute_convert_gain): Provide gains for comparisons against 0/-1, including "*testti" patterns.
2022-08-15PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean.Roger Sayle2-0/+27
This patch resolves both PR tree-optimization/64992 and PR tree-optimization/98956 which are missed optimization enhancement request, for which Andrew Pinski already has a proposed solution (related to a fix for PR tree-optimization/98954). Yesterday, I proposed an alternate improved patch for PR98954, which although superior in most respects, alas didn't address this case [which doesn't include a BIT_AND_EXPR], hence this follow-up fix. For many functions, F(B), of a (zero-one) Boolean value B, the expression F(B) != 0 can often be simplified to just B. Hence "(B * 5) != 0" is B, "-B != 0" is B, "bswap(B) != 0" is B, "(B >>r 3) != 0" is B. These are all currently optimized by GCC, with the strange exception of left shifts by a constant (possibly due to the undefined/implementation defined behaviour when the shift constant is larger than the first operand's precision). This patch adds support for this particular case, when the shift constant is valid. 2022-08-15 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog PR tree-optimization/64992 PR tree-optimization/98956 * match.pd (ne (lshift @0 @1) 0): Simplify (X << C) != 0 to X when X is zero_one_valued_p and the shift constant C is valid. (eq (lshift @0 @1) 0): Likewise, simplify (X << C) == 0 to !X when X is zero_one_valued_p and the shift constant C is valid. gcc/testsuite/ChangeLog PR tree-optimization/64992 * gcc.dg/pr64992.c: New test case.
2022-08-15PR tree-optimization/71343: Optimize (X<<C)&(Y<<C) as (X&Y)<<C.Roger Sayle2-0/+76
This patch is the first part of a solution to PR tree-optimization/71343, a missed-optimization enhancement request where GCC fails to see that (a<<2)+(b<<2) == a*4+b*4. This piece is that (X<<C) op (Y<<C) can be simplified to (X op Y) << C, for many binary operators, including AND, IOR, XOR, and (if overflow isn't an issue) PLUS and MINUS. Likewise, the right shifts (both logical and arithmetic) and bit-wise logical operators can be simplified in a similar fashion. These all reduce the number of GIMPLE binary operations from 3 to 2, by combining/eliminating a shift operation. 2022-08-15 Roger Sayle <roger@nextmovesoftware.com> Richard Biener <rguenther@suse.de> gcc/ChangeLog PR tree-optimization/71343 * match.pd (op (lshift @0 @1) (lshift @2 @1)): Optimize the expression (X<<C) + (Y<<C) to (X+Y)<<C for multiple operators. (op (rshift @0 @1) (rshift @2 @1)): Likewise, simplify (X>>C)^(Y>>C) to (X^Y)>>C for binary logical operators, AND, IOR and XOR. gcc/testsuite/ChangeLog PR tree-optimization/71343 * gcc.dg/pr71343-1.c: New test case.
2022-08-15c++: Fix module line no testcaseNathan Sidwell1-2/+2
Not all systems have the same injected headers, leading to line location table differences that are immaterial to the test. Fix the regexp more robustly. gcc/testsuite/ * g++.dg/modules/loc-prune-4.C: Adjust regexp
generated by cgit v1.1 at 2025-08-07 17:08:57 +0000