summaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)Author
2022-07-30openmp: Fix up handling of non-rectangular simd loops with pointer type ↵Jakub Jelinek
iterators [PR106449] There were 2 issues visible on this new testcase, one that we didn't have special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer part in sizetype, for non-rectangular loop on the other side we can rely on multiplication factor 1, pointers can't be multiplied, without those changes we'd ICE. The other issue was that we put n2 expression directly into a comparison in a condition and regimplified that, for the &a[512] case that and with gimplification being destructed that unfortunately meant modification of original fd->loops[?].n2. Fixed by unsharing the expression. This was causing a runtime failure on the testcase. 2022-07-29 Jakub Jelinek <jakub@redhat.com> PR middle-end/106449 * omp-expand.cc (expand_omp_simd): Fix up handling of pointer iterators in non-rectangular simd loops. Unshare fd->loops[i].n2 or n2 before regimplifying it inside of a condition. * testsuite/libgomp.c-c++-common/pr106449.c: New test. (cherry picked from commit 97d32048c04e9787fccadc4bae1c042754503e34)
2022-07-30cgraphunit: Don't emit asm thunks for -dx [PR106261]Jakub Jelinek
When -dx option is used (didn't know we have it and no idea what is it useful for), we just expand functions to RTL and then omit all further RTL passes, so the normal functions aren't actually emitted into assembly, just variables. The following testcase ICEs, because we don't emit the methods, but do emit thunks pointing to that and those thunks have unwind info and rely on at least some real functions to be emitted (which is normally the case, thunks are only emitted for locally defined functions) because otherwise there are no CIEs, only FDEs and dwarf2out is upset about it. The following patch fixes that by not emitting assembly thunks for -dx either. 2022-07-27 Jakub Jelinek <jakub@redhat.com> PR debug/106261 * cgraphunit.cc (cgraph_node::assemble_thunks_and_aliases): Don't output asm thunks for -dx. * g++.dg/debug/pr106261.C: New test. (cherry picked from commit f9671b60f9395cb1dca128b92f5dd215f5aeaae1)
2022-07-30wide-int: Fix up wi::shifted_mask [PR106144]Jakub Jelinek
As the following self-test testcase shows, wi::shifted_mask sometimes doesn't create canonicalized wide_ints, which then fail to compare equal to canonicalized wide_ints with the same value. In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec 128, while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2 and prec 128. The problem is that the code is written with the assumption that there are 3 bit blocks (or 2 if start is 0), but doesn't consider the possibility where there are 2 bit blocks (or 1 if start is 0) where the highest block isn't present. In that case, there is the optional block of negate ? 0 : -1 elts, followed by just one elt (either one from the if (shift) or just negate ? -1 : 0) and the rest is implicit sign-extension. Only if end < prec there is 1 or more bits above it that have different bit value and so we need to emit all the elts till end and then one more elt. if (end == prec) would work too, because we have: if (width > prec - start) width = prec - start; unsigned int end = start + width; so end is guaranteed to be end <= prec, dunno what is preferred. 2022-07-01 Jakub Jelinek <jakub@redhat.com> PR middle-end/106144 * wide-int.cc (wi::shifted_mask): If end >= prec, return right after emitting element for shift or if shift is 0 first element after start. (wide_int_cc_tests): Add tests for equivalency of wi::mask and wi::shifted_mask with 0 start. (cherry picked from commit e52592073f6df3d7a3acd9f0436dcc32a8b7493d)
2022-07-30Daily bump.GCC Administrator
2022-07-29Daily bump.GCC Administrator
2022-07-28Daily bump.linaro-local/ci/tcwg_bmk_llvm_sq/llvm-release-aarch64-spec2k6-OsGCC Administrator
2022-07-27analyzer: fix stray get_element declsDavid Malcolm
(cherry picked from r13-1847-g0460ba622e833d) These were copy&paste errors. gcc/analyzer/ChangeLog: * region.h (code_region::get_element): Remove stray decl. (function_region::get_element): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]David Malcolm
(cherry picked from r13-1562-g897b3b31f0a94b) gcc/analyzer/ChangeLog: PR analyzer/106225 * sm-taint.cc (taint_state_machine::on_stmt): Move handling of assignments from division to... (taint_state_machine::check_for_tainted_divisor): ...this new function. Reject warning when the divisor is known to be non-zero. * sm.cc: Include "analyzer/program-state.h". (sm_context::get_old_region_model): New. * sm.h (sm_context::get_old_region_model): New decl. gcc/testsuite/ChangeLog: PR analyzer/106225 * gcc.dg/analyzer/taint-divisor-1.c: Add test coverage for various correct and incorrect checks against zero. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: fix uninit false positive with -ftrivial-auto-var-init= [PR106204]David Malcolm
(cherry picked from r13-1517-gb33dd7874523af) -fanalyzer handles -ftrivial-auto-var-init= by special-casing IFN_DEFERRED_INIT to be a no-op, so that e.g.: len_2 = .DEFERRED_INIT (4, 2, &"len"[0]); is treated as a no-op, so that len_2 is still uninitialized after the stmt. PR analyzer/106204 reports that -fanalyzer gives false positives from -Wanalyzer-use-of-uninitialized-value on locals that have their address taken, due to e.g.: _1 = .DEFERRED_INIT (4, 2, &"len"[0]); len = _1; where -fanalyzer leaves _1 uninitialized, and then complains about the assignment to "len". Fixed thusly by suppressing the warning when assigning from such SSA names. gcc/analyzer/ChangeLog: PR analyzer/106204 * region-model.cc (within_short_circuited_stmt_p): Move extraction of assign_stmt to caller. (due_to_ifn_deferred_init_p): New. (region_model::check_for_poison): Move extraction of assign_stmt from within_short_circuited_stmt_p to here. Share logic with call to due_to_ifn_deferred_init_p. gcc/testsuite/ChangeLog: PR analyzer/106204 * gcc.dg/analyzer/torture/uninit-pr106204.c: New test. * gcc.dg/analyzer/uninit-pr106204.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: show saved diagnostics as nodes in .eg.dot dumpsDavid Malcolm
(cherry picked from r13-1117-gc540077a3bf600) I've been using this tweak to the output of -fdump-analyzer-exploded-graph in my working copies for a while; the extra red nodes make it *much* easier to find the places where diagnostics are being emitted (or rejected by the diagnostic_manager). gcc/analyzer/ChangeLog: * diagnostic-manager.cc (saved_diagnostic::dump_dot_id): New. (saved_diagnostic::dump_as_dot_node): New. * diagnostic-manager.h (saved_diagnostic::dump_dot_id): New decl. (saved_diagnostic::dump_as_dot_node): New decl. * engine.cc (exploded_node::dump_dot): Add nodes for saved diagnostics. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: add more uninit test coverageDavid Malcolm
(cherry picked from r13-1116-g44681d45473883) gcc/testsuite/ChangeLog: * gcc.dg/analyzer/uninit-1.c: Add test coverage of attempts to jump through an uninitialized function pointer, and of attempts to pass an uninitialized value to a function call. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27json: fix escaping of '\'David Malcolm
(cherry picked from r13-965-g4f9ad0b4b0a8c7) gcc/ChangeLog: * json.cc (string::print): Fix escaping of '\'. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: fix memory leaksDavid Malcolm
(cherry picked from r13-334-g99988b0e8b57b3) These leaks all relate to logging within -fdump-analyzer[-stderr] or are one-time leaks; seen with valgrind. gcc/analyzer/ChangeLog: * checker-path.cc (state_change_event::get_desc): Call maybe_free on label_text temporaries. * diagnostic-manager.cc (diagnostic_manager::prune_for_sm_diagnostic): Likewise. * engine.cc (exploded_graph::~exploded_graph): Fix leak of m_per_point_data and m_per_call_string_data values. Simplify cleanup of m_per_function_stats and m_per_point_data values. (feasibility_state::maybe_update_for_edge): Fix leak of result of superedge::get_description. * region-model-manager.cc (region_model_manager::~region_model_manager): Move cleanup of m_setjmp_values to match the ordering of the fields within region_model_manager. Fix leak of values within m_repeated_values_map, m_bits_within_values_map, m_asm_output_values_map, and m_const_fn_result_values_map. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: handle repeated accesses after init of unknown size [PR105285]David Malcolm
(cherry-picked from r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3) PR analyzer/105285 reports a false positive from -Wanalyzer-null-dereference on git.git's reftable/reader.c. A reduced version of the problem can be seen in test_1a of gcc.dg/analyzer/symbolic-12.c in the following: void test_1a (void *p, unsigned next_off) { struct st_1 *r = p; external_fn(); if (next_off >= r->size) return; if (next_off >= r->size) /* We should have already returned if this is the case. */ __analyzer_dump_path (); /* { dg-bogus "path" } */ } where the analyzer erroneously considers this path, where (next_off >= r->size) is both false and then true: symbolic-12.c: In function ‘test_1a’: symbolic-12.c:22:5: note: path 22 | __analyzer_dump_path (); /* { dg-bogus "path" } */ | ^~~~~~~~~~~~~~~~~~~~~~~ ‘test_1a’: events 1-5 | | 17 | if (next_off >= r->size) | | ^ | | | | | (1) following ‘false’ branch... |...... | 20 | if (next_off >= r->size) | | ~ ~~~~~~~ | | | | | | | (2) ...to here | | (3) following ‘true’ branch... | 21 | /* We should have already returned if this is the case. */ | 22 | __analyzer_dump_path (); /* { dg-bogus "path" } */ | | ~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (4) ...to here | | (5) here | The root cause is that, at the call to the external function, the analyzer considers the cluster for *p to have been touched, binding it to a conjured_svalue, but because p is void * no particular size is known for the write, and so the cluster is bound using a symbolic key covering the base region. Later, the accesses to r->size are handled by binding_cluster::get_any_binding, but binding_cluster::get_binding fails to find a match for the concrete field lookup, due to the key for the binding being symbolic, and reaching this code: 1522 /* If this cluster has been touched by a symbolic write, then the content 1523 of any subregion not currently specifically bound is "UNKNOWN". */ 1524 if (m_touched) 1525 { 1526 region_model_manager *rmm_mgr = mgr->get_svalue_manager (); 1527 return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ()); 1528 } Hence each access to r->size is an unknown svalue, and thus the condition (next_off >= r->size) isn't tracked, leading to the path with contradictory conditions being treated as satisfiable. In the original reproducer in git's reftable/reader.c, the call to the external fn is: reftable_record_type(rec) which is considered to possibly write to *rec, which is *tab, where tab is the void * argument to reftable_reader_seek_void, and thus after the call to reftable_record_type some arbitrary amount of *rec could have been written to. This patch fixes things by detecting the "this cluster has been 'filled' with a conjured value of unknown size" case, and handling get_any_binding on it by returning a sub_svalue of the conjured_svalue, so that repeated accesses to r->size give the same symbolic value, so that the constraint manager rejects the bogus execution path, fixing the false positive. gcc/analyzer/ChangeLog: PR analyzer/105285 * store.cc (binding_cluster::get_any_binding): Handle accessing sub_svalues of clusters where the base region has a symbolic binding. gcc/testsuite/ChangeLog: PR analyzer/105285 * gcc.dg/analyzer/symbolic-12.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibilityDavid Malcolm
(cherry picked from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074) I found this extension to -fdump-analyzer-feasibility very helpful when debugging PR analyzer/105285. gcc/analyzer/ChangeLog: * diagnostic-manager.cc (epath_finder::process_worklist_item): Call dump_feasible_path when a path that reaches the the target enode is found. (epath_finder::dump_feasible_path): New. * engine.cc (feasibility_state::dump_to_pp): New. * exploded-graph.h (feasibility_state::dump_to_pp): New decl. * feasible-graph.cc (feasible_graph::dump_feasible_path): New. * feasible-graph.h (feasible_graph::dump_feasible_path): New decls. * program-point.cc (function_point::print): Fix missing trailing newlines. * program-point.h (program_point::print_source_line): Remove unimplemented decl. gcc/ChangeLog: * doc/invoke.texi (-fdump-analyzer-feasibility): Mention the fpath.txt output. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-07-27RISC-V: Remove duplicate backslashes from `stack_protect_set_<mode>'Maciej W. Rozycki
Remove redundant duplicate backslash characters from \t sequences in the output pattern of the `stack_protect_set_<mode>' RTL insn. gcc/ * config/riscv/riscv.md (stack_protect_set_<mode>): Remove duplicate backslashes. (cherry picked from commit 3cf07cc5e51c833f39f5bad5ca6fbe23c853a214)
2022-07-27tree-optimization/106189 - avoid division by zero exceptionRichard Biener
The diagnostic code can end up with zero sized array elements with T[][0] and the wide-int code nicely avoids exceptions when dividing by zero in one codepath but not in another. The following fixes the exception by using wide-int in both paths. PR tree-optimization/106189 * gimple-array-bounds.cc (array_bounds_checker::check_mem_ref): Divide using offset_ints. * gcc.dg/pr106189.c: New testcase. (cherry picked from commit bb04f9f23ac0dee2c003118c85372ece50a52220)
2022-07-27lto: Fix option merging [PR106129]Joseph Myers
The LTO merging of options from different input files was broken by: commit 227a2ecf663d69972b851f51f1934d18927b62cd Author: Martin Liska <mliska@suse.cz> Date: Fri Mar 12 11:53:47 2021 +0100 lto-wrapper: Use vec<cl_decoded_option> data type. Previously, find_and_merge_options would merge options it read into those in *opts. After this commit, options in *opts on entry to find_and_merge_options are ignored; the only merging that takes place is between multiple sets of options in the same input file that are read in the same call to this function (not sure how that case can occur at all). The effects include, for example, that if some objects are built with PIC enabled and others with it disabled, and the last LTO object processed has PIC enabled, the choice of PIC for the last object will result in the whole program being built as PIC, when the merging logic is intended to ensure that a mixture of PIC and non-PIC objects results in the whole program being built as non-PIC. Fix this with an extra argument to find_and_merge_options to determine whether merging should take place. This shows up a second issue with that commit (which I think wasn't actually intended to change code semantics at all): once merging is enabled again, the check for -Xassembler options became an infinite loop in the case where both inputs had -Xassembler options, with the same first option, so fix that loop to restore the previous semantics. Note that I'm not sure how LTO option merging might be tested in the testsuite (clearly there wasn't sufficient, if any, coverage to detect these bugs). Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR lto/106129 * lto-wrapper.cc (find_option): Add argument start. (merge_and_complain): Loop over existing_opt_index and existing_opt2_index for Xassembler check. Update calls to find_option. (find_and_merge_options): Add argument first to determine whether to merge options with those passed in *opts. (run_gcc): Update calls to find_and_merge_options. (cherry picked from commit 8a8ee37a3325f1009034245676ef4e482c0444a2)
2022-07-27Fix tree-opt/PR106087: ICE with inline-asm with multiple output and assigned ↵Andrew Pinski
only static vars The problem here is that when we mark the ssa name that was referenced in the now removed dead store (to a write only static variable), the inline-asm would also be removed even though it was defining another ssa name. This fixes the problem by checking to make sure that the statement was only defining one ssa name. Committed as approved after a bootstrapped and tested on x86_64 with no regressions. PR tree-optimization/106087 gcc/ChangeLog: * tree-ssa-dce.cc (simple_dce_from_worklist): Check to make sure the statement is only defining one operand. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/inline-asm-1.c: New test. (cherry picked from commit 71e3daa31cfa35ee58e5899cb00767be92227fd2)
2022-07-27testsuite: Require int128 for gcc.dg/pr106063.cDimitar Dimitrov
Require effective target int128 for gcc.dg/pr106063.c. PR tree-optimization/106063 gcc/testsuite/ChangeLog: * gcc.dg/pr106063.c: Require effective target int128. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu> (cherry picked from commit 4ebbf3906895bcb40d7ff2729cf46deae66bc268)
2022-07-27middle-end: don't lower past veclower [PR106063]Tamar Christina
Hi All, My previous patch can cause a problem if the pattern matches after veclower as it may replace the construct with a vector sequence which the target may not directly support. As such don't perform the rewriting if after veclower unless the target supports the operation. If before veclower do the rewriting as well if the target didn't support the original operation either. gcc/ChangeLog: PR tree-optimization/106063 * match.pd: Do not apply pattern after veclower is not supported. gcc/testsuite/ChangeLog: PR tree-optimization/106063 * gcc.dg/pr106063.c: New test. (cherry picked from commit f7854e2faf7640230062dec3596e71773ca500ed)
2022-07-27[PR105665] ivopts: check defs of names in base for undefsAlexandre Oliva
The patch for PR 100810 tested for undefined SSA_NAMEs appearing directly in the base expression of the potential IV candidate, but that's not enough. The testcase for PR105665 shows an undefined SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg in the referenced SSA_NAME. The variant of that test shows it can be further removed from the referenced SSA_NAME. To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start from known-undefined nonvirtual default defs, and propagate them to any PHI nodes reached by a maybe-undefined arg, as long as there aren't intervening non-PHI uses, that would imply the maybe-undefined name must be defined at that point, otherwise it would invoke undefined behavior. Also test for intervening non-PHI uses of DEFs in the base expr. The test for intervening uses implemented herein relies on dominance; this could be further extended, regarding conditional uses in every path leading to a point as an unconditional use dominating that point, but I haven't implemented that. for gcc/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New. (ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New. (find_ssa_undef): Check precomputed flag and intervening uses. (tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs. for gcc/testsuite/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * gcc.dg/torture/pr105665.c: New. (cherry picked from commit be2861fe8c527a5952257462ceca899bb43b1452)
2022-07-27Daily bump.GCC Administrator
2022-07-26d: Merge upstream dmd 76e3b41375, druntime 1462ebd1, phobos 5fef0d28f.Iain Buclaw
Updates D language version to v2.100.1. D front-end changes: - Fix delegate literal with inferred return value that requires following alias-this to not use class cast. - Fix internal error on variadic template type instantiated with two arrays of classes. - `scope(failure)' blocks that contain `return' statements are now deprecated. - Fix regression where wrong cast was inserted for ternary operator and non-int enums. - Fix internal error in code generation trying to reference _d_arraysetctor. - Fix memory corruption when array literal is passed to map in lambda, then returned from nested function. - Generate invariant id on the basis of location rather than a global counter. - Make `noreturn' conversions work. - Fix segfault when `.stringof' of template alias overloaded with function accessed by trait. - Empty array literal passed to scope param not 'falsey' anymore. Phobos changes: - Avoid copying ranges in std.algorithm.comparison.equal. gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 76e3b41375. * dmd/VERSION: Bump version to v2.100.1. * decl.cc (DeclVisitor::visit (VarDeclaration *)): Evaluate RHS of noreturn declaration expressions first. * expr.cc (ExprVisitor::visit (AssignExp *)): Don't generate assignment for noreturn types. libphobos/ChangeLog: * libdruntime/MERGE: Merge upstream druntime 1462ebd1. * src/MERGE: Merge upstream phobos 5fef0d28f.
2022-07-26Fortran: error recovery from calculation of storage size of a symbol [PR103504]Harald Anlauf
gcc/fortran/ChangeLog: PR fortran/103504 * interface.cc (get_sym_storage_size): Array bounds and character length can only be of integer type. gcc/testsuite/ChangeLog: PR fortran/103504 * gfortran.dg/pr103504.f90: New test. (cherry picked from commit 600956c81c784f4a0cc9d10f6e03e01847afd961)
2022-07-26c++: ICE with erroneous template redeclaration [PR106311]Marek Polacek
Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens to be error_mark_node in this ill-formed test. I kept running into this while reducing code, so it'd be good to have it fixed. PR c++/106311 gcc/cp/ChangeLog: * pt.cc (redeclare_class_template): Check DECL_P before accessing DECL_SOURCE_LOCATION. gcc/testsuite/ChangeLog: * g++.dg/template/redecl5.C: New test. (cherry picked from commit 2333b58c9892667545d0c2c3ecd2d7b947197511)
2022-07-25c++: aggregate prvalue as for range [PR106230]Jason Merrill
Since my PR94041 work on temporary lifetime in aggregate initialization, we end up calling build_vec_init to initialize the reference-extended temporary for the artificial __for_range variable. And build_vec_init uses finish_for_stmt to implement its loop. That function assumes that if __for_range is in current_binding_level, we're finishing a range-for, and we should fix up the variable as it goes out of scope. But when called from build_vec_init we aren't finishing a range-for, and do_poplevel doesn't remove the variable from scope because stmts_are_full_exprs_p is false. So let's check that here as well, and leave the DECL_NAME alone. PR c++/106230 gcc/cp/ChangeLog: * semantics.cc (finish_for_stmt): Check stmts_are_full_exprs_p. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/range-for38.C: New test.
2022-07-26Daily bump.GCC Administrator
2022-07-25RTEMS: Do not define _GNU_SOURCE by defaultSebastian Huber
gcc/ChangeLog: * config/rs6000/rtems.h (CPLUSPLUS_CPP_SPEC): Undef. (cherry picked from commit 556b816b820f6749910784cbaca8bb0bb822a970)
2022-07-25Daily bump.GCC Administrator
2022-07-24Daily bump.GCC Administrator
2022-07-23Daily bump.GCC Administrator
2022-07-22Daily bump.linaro-local/ci/tcwg_bmk_llvm_apm/llvm-release-aarch64-spec2k6-OsGCC Administrator
2022-07-21c++: defaulted friend op== [PR106361]Jason Merrill
Now non-member functions can be defaulted, so this assert is wrong. move_signature_fn_p already checks for ctor or op=. PR c++/106361 gcc/cp/ChangeLog: * decl.cc (move_fn_p): Remove assert. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-eq14.C: New test.
2022-07-21c++: non-dependent call to consteval operator [PR105912]Patrick Palka
Here we're crashing when substituting a non-dependent call to a consteval operator, whose CALL_EXPR_OPERATOR_SYNTAX flag we try to propagate to the result, but the result isn't a CALL_EXPR since the selected function is consteval. This patch fixes this by checking the result of extract_call_expr accordingly. (Note that we can't check DECL_IMMEDIATE_FUNCTION_P here because we don't know which function was selected by overload resolution from here.) PR c++/105912 gcc/cp/ChangeLog: * call.cc (extract_call_expr): Return a NULL_TREE on failure instead of asserting. * pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Guard against NULL_TREE extract_call_expr result. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/consteval31.C: New test. (cherry picked from commit f70c18524221dcefa6cd26cee7b55503181bd912)
2022-07-21c++: dependence of constrained memfn from current inst [PR105842]Patrick Palka
Here we incorrectly deem the calls to func1, func2 and tmpl2 as ambiguous ahead of time ultimately because we mishandle dependence of a constrained member function from the current instantiation. In type_dependent_expression_p, we already consider dependence of a TEMPLATE_DECL's constraints (via uses_outer_template_parms), but neglect to do the same for a FUNCTION_DECL (such as that for func1). And in satisfy_declaration_constraints, we give up if _any_ template argument is dependent, but for non-dependent member functions from the current instantiation (such as func2 and tmpl2), we can and must check constraints as long as the innermost arguments aren't dependent. PR c++/105842 gcc/cp/ChangeLog: * constraint.cc (satisfy_declaration_constraints): Refine early exit test for argument dependence. * cp-tree.h (uses_outer_template_parms_in_constraints): Declare. * pt.cc (template_class_depth): Handle TI_TEMPLATE being a FIELD_DECL. (usse_outer_template_parms): Factor out constraint dependence test into ... (uses_outer_template_parms_in_constraints): ... here. (type_dependent_expression_p): Use it for FUNCTION_DECL. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl6.C: New test. (cherry picked from commit f07778f6f92111aa0abfd0f669b148a0bda537a9)
2022-07-21c++: function NTTP argument considered unused [PR53164, PR105848]Patrick Palka
Here at parse time the template argument f (an OVERLOAD) in A<f> gets resolved ahead of time to the FUNCTION_DECL f<int>, and we defer marking f<int> as used until instantiation (of g) as usual. Later when instantiating g the type A<f> (where f has already been resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its template arguments, and we end up never actually marking f<int> as used (which means we never instantiate it) even though A<f>::h() later calls it, leading to a link error. This patch works around this issue by looking through ADDR_EXPR when calling mark_used on the substituted callee of a CALL_EXPR. PR c++/53164 PR c++/105848 gcc/cp/ChangeLog: * pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Look through an ADDR_EXPR callee when calling mark_used. gcc/testsuite/ChangeLog: * g++.dg/template/fn-ptr3.C: New test. (cherry picked from commit 733a792a2b2e1662e738fa358b45a2720a8618a7)
2022-07-21c++: cv-quals of dummy obj for non-dep memfn call [PR105637]Patrick Palka
In non-dependent23.C below we expect the Base::foo calls to resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first overload at instantiation time. This happens because the calls to Base::foo are all deemed non-dependent (ever since r7-755-g23cb72663051cd made us ignore 'this' dependence when considering the dependence of a non-static memfn call), hence we end up checking the call ahead of time, using as the object argument a dummy object of type Base. Since this object argument is cv-unqualified, the calls in turn resolve to the unqualified overload of baseDevice. Before r12-6075 this incorrect result would just get silently discarded and we'd end up redoing OR at instantiation time using 'this' as the object argument. But after r12-6075 we now reuse this incorrect result at instantiation time. This patch fixes this by making maybe_dummy_object respect the cv-quals of (the non-lambda) 'this' when returning a dummy object. Thus, ahead of time OR using a dummy object will give us the right answer that's consistent with the instantiation time answer. An earlier version of this patch didn't handle 'this'-capturing lambdas correctly, which broke lambda-this22.C below. PR c++/105637 gcc/cp/ChangeLog: * tree.cc (maybe_dummy_object): When returning a dummy object, respect the cv-quals of 'this' if available. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-this22.C: New test. * g++.dg/template/non-dependent23.C: New test. (cherry picked from commit 44a5bd6d933d86ed988fc4695aa00f122cf83eb4)
2022-07-21c++: don't substitute TEMPLATE_PARM_CONSTRAINTS [PR100374]Patrick Palka
This patch makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINTS of each template parameter except as necessary for declaration matching, like we already do for the other constituent constraints of a declaration. This patch also improves the CA104 implementation of explicit specialization matching of a constrained function template inside a class template, by considering the function's combined constraints instead of just its trailing constraints. This allows us to correctly handle the first three explicit specializations in concepts-spec2.C below, but because we compare the constraints as a whole, it means we incorrectly accept the fourth explicit specialization which writes #3's constraints in a different way. For complete correctness here, determine_specialization should use tsubst_each_template_parm_constraints and template_parameter_heads_equivalent_p. PR c++/100374 gcc/cp/ChangeLog: * pt.cc (determine_specialization): Compare overall constraints not just the trailing constraints. (tsubst_each_template_parm_constraints): Define. (tsubst_friend_function): Use it. (tsubst_friend_class): Use it. (tsubst_template_parm): Don't substitute TEMPLATE_PARM_CONSTRAINTS. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-spec2.C: New test. * g++.dg/cpp2a/concepts-template-parm11.C: New test. (cherry picked from commit 43c013df02fdb07f9b7a5e7e6669e6d69769d451)
2022-07-21c++: non-dep call with empty TYPE_BINFO [PR105758]Patrick Palka
Here the out-of-line definition of Z<T>::z causes duplicate_decls to change z's type from using the primary template type Z<T> (which is also the type of the injected class name) to the implicit instantiation Z<T>, and this latter type lacks a TYPE_BINFO (although its TYPE_CANONICAL was set by a special case in lookup_template_class to point to the former). Later, when processing the non-dependent call z->foo(0), build_over_call relies on the object argument's TYPE_BINFO to build the templated form for this call, which fails because the object argument type has empty TYPE_BINFO due to the above. It seems weird that the implicit instantiation Z<T> doesn't have the same TYPE_BINFO as the primary template type Z<T>, despite them being proclaimed equivalent via TYPE_CANONICAL. So I tried also setting TYPE_BINFO in the special case in lookup_template_class, but that led to some problems with constrained partial specializations of the form Z<T>. I'm not sure what, if anything, we ought to do about the subtle differences between these two versions of the same type. Fortunately it seems we don't need to rely on TYPE_BINFO at all in build_over_call here -- the z_candidate struct already contains the exact binfos we need to rebuild the BASELINK for the templated form. PR c++/105758 gcc/cp/ChangeLog: * call.cc (build_over_call): Use z_candidate::conversion_path and ::access_path instead of TYPE_BINFO when building the BASELINK for the templated form. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent24.C: New test. (cherry picked from commit 4f84f12066953186cce4328b7f178d3daa2fe96e)
2022-07-21c++: constrained partial spec forward decl [PR96363]Patrick Palka
Here during cp_parser_single_declaration for #2, we were calling associate_classtype_constraints for TPL<T> (the primary template type) before maybe_process_partial_specialization could get a chance to notice that we're in fact declaring a distinct constrained partial spec and not redeclaring the primary template. This caused us to emit a bogus error about differing constraints b/t the primary template and #2's constraints. This patch fixes this by moving the call to associate_classtype_constraints after the call to shadow_tag (which calls maybe_process_partial_specialization) and adjusting shadow_tag to use the return value of m_p_p_s. Moreover, if we later try to define a constrained partial specialization that's been declared earlier (as in the third testcase), then maybe_new_partial_specialization correctly notices it's a redeclaration and returns NULL_TREE. But in this case we also need to update TYPE to point to the redeclared partial spec (it'll otherwise continue pointing to the primary template type, eventually leading to a bogus error). PR c++/96363 gcc/cp/ChangeLog: * decl.cc (shadow_tag): Use the return value of maybe_process_partial_specialization. * parser.cc (cp_parser_single_declaration): Call shadow_tag before associate_classtype_constraints. * pt.cc (maybe_new_partial_specialization): Change return type to bool. Take 'type' argument by mutable reference. Set 'type' to point to the correct constrained specialization when appropriate. (maybe_process_partial_specialization): Adjust accordingly. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-partial-spec12.C: New test. * g++.dg/cpp2a/concepts-partial-spec12a.C: New test. * g++.dg/cpp2a/concepts-partial-spec13.C: New test. (cherry picked from commit 97dc78d705a90c1ae83c78a7f2e24942cc3a6257)
2022-07-21Daily bump.GCC Administrator
2022-07-20Fortran: fix parsing of omp task affinity iterator clause [PR101330]Harald Anlauf
gcc/fortran/ChangeLog: PR fortran/101330 * openmp.cc (gfc_match_iterator): Remove left-over code from development that could lead to a crash on invalid input. gcc/testsuite/ChangeLog: PR fortran/101330 * gfortran.dg/gomp/affinity-clause-7.f90: New test. (cherry picked from commit 26bbe78f77f73bb66af1ac13d0deec888a3c6510)
2022-07-20Daily bump.GCC Administrator
2022-07-19c++: fix SIGFPE with -Wclass-memaccess [PR105634]Marek Polacek
Here we crash because we attempt to % by 0. Thus fixed. PR c++/105634 gcc/cp/ChangeLog: * call.cc (maybe_warn_class_memaccess): Avoid % by zero. gcc/testsuite/ChangeLog: * g++.dg/warn/Wclass-memaccess-7.C: New test.
2022-07-19middle-end/106331 - fix mem attributes for string op argumentsRichard Biener
get_memory_rtx tries hard to come up with a MEM_EXPR to record in the memory attributes but in the last fallback fails to properly account for an unknown offset and thus, as visible in this testcase, incorrect alignment computed from set_mem_attributes. The following rectifies both parts. PR middle-end/106331 * builtins.cc (get_memory_rtx): Compute alignment from the original address and set MEM_OFFSET to unknown when we create a MEM_EXPR from the base object of the address. * gfortran.dg/pr106331.f90: New testcase. (cherry picked from commit e4ff11a8f2e80adb8ada69bf35ee6a1ab18a9c85)
2022-07-19tree-optimization/106131 - wrong code with FRE rewritingRichard Biener
The following makes sure to not use the original TBAA type for looking up a value across an aggregate copy when we had to offset the read. 2022-06-30 Richard Biener <rguenther@suse.de> PR tree-optimization/106131 * tree-ssa-sccvn.cc (vn_reference_lookup_3): Force alias-set zero when offsetting the read looking through an aggregate copy. * g++.dg/torture/pr106131.C: New testcase. (cherry picked from commit 9701432ff79926a5dd3303be3417e0bd0c24140b)
2022-07-19tree-optimization/106112 - fix CSE from wider operationRichard Biener
The following fixes a mistake in looking up an extended operand in the CSE of a truncated operation. 2022-06-28 Richard Biener <rguenther@suse.de> PR tree-optimization/106112 * tree-ssa-sccvn.cc (valueized_wider_op): Properly extend a constant operand according to its type. * gcc.dg/torture/pr106112.c: New testcase. (cherry picked from commit 2dbb45d6dc0d20dc159b3d8e27ebb6825074827a)
2022-07-19middle-end/106027 - fix types in needle foldingRichard Biener
The fold_to_nonsharp_ineq_using_bound folding ends up creating invalid typed IL which confuses later foldings. The following fixes that. 2022-06-20 Richard Biener <rguenther@suse.de> PR middle-end/106027 * fold-const.cc (fold_to_nonsharp_ineq_using_bound): Use the type of the prevailing comparison for the new comparison type. (fold_binary_loc): Use proper types for the A < X && A + 1 > Y to A < X && A >= Y folding. * gcc.dg/pr106027.c: New testcase. (cherry picked from commit 713f2fd923442b1be620a44240ddf786ae0ab476)
2022-07-19tree-optimization/105971 - less surprising refs_may_alias_p_2Richard Biener
When DSE asks whether __real a is using __imag a it gets a surprising result when a is a FUNCTION_DECL. The following makes sure this case is less surprising to callers but keeping the bail-out for the non-decl case where it is true that PTA doesn't track aliases to code correctly. 2022-06-15 Richard Biener <rguenther@suse.de> PR tree-optimization/105971 * tree-ssa-alias.cc (refs_may_alias_p_2): Put bail-out for FUNCTION_DECL and LABEL_DECL refs after decl-decl disambiguation to leak less surprising alias results. * gcc.dg/torture/pr106971.c: New testcase. (cherry picked from commit 8c2733e16ec1c0cdda3db4cdc5ad158a96a658e8)