aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2021-03-31Update prefixed attribute for Power10.Pat Haugen4-25/+52
This patch creates a new attribute, "maybe_prefixed", which is used to mark those instructions that may have a prefixed form. The existing "prefixed" attribute is now used to mark all instructions that are prefixed form. 2021-03-31 Pat Haugen <pthaugen@linux.ibm.com> gcc/ PR target/99133 * config/rs6000/altivec.md (xxspltiw_v4si, xxspltiw_v4sf_inst, xxspltidp_v2df_inst, xxsplti32dx_v4si_inst, xxsplti32dx_v4sf_inst, xxblend_<mode>, xxpermx_inst, xxeval): Mark prefixed. * config/rs6000/mma.md (mma_<vvi4i4i8>, mma_<avvi4i4i8>, mma_<vvi4i4i2>, mma_<avvi4i4i2>, mma_<vvi4i4>, mma_<avvi4i4>, mma_<pvi4i2>, mma_<apvi4i2>, mma_<vvi4i4i4>, mma_<avvi4i4i4>): Likewise. * config/rs6000/rs6000.c (rs6000_final_prescan_insn): Adjust test. * config/rs6000/rs6000.md (define_attr "maybe_prefixed"): New. (define_attr "prefixed"): Update initializer.
2021-03-31dwarf2out: Fix up ranges for -gdwarf-5 -gsplit-dwarf [PR99490]Jakub Jelinek1-44/+211
For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section (so in the binaries/shared libraries) with DW_AT_ranges from skeleton units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset (and DW_AT_GNU_ranges_base pointing into section, not sure for what reason exactly). When DWARF5 support was being added, we've started using .debug_rnglists section, added DW_AT_rnglists_base to the DW_TAG_skeleton_unit, kept DW_AT_ranges with DW_FORM_sec_offset in the skeleton and switched over to DW_FORM_rnglistx for DW_AT_ranges in .debug_info.dwo. But the DWARF5 spec actually means for the ranges section (at least everything for those DW_AT_ranges in .debug_info.dwo) to sit in .debug_rnglists.dwo section next to the .debug_info.dwo, rather than having consumers look it up in the binary/shared library instead. Based on some discussions in the DWARF discuss mailing list: http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-March/thread.html#4765 this patch mostly follows what LLVM emits for that right now: 1) small .debug_rnglists section (when needed) just to cover the skeleton DW_AT_ranges (if present); the content of the section uses the Split DWARFy DW_RLE_* codes with addrx encodings where possible 2) DW_AT_ranges in the skeleton uses DW_FORM_sec_offset (difference from LLVM which uses DW_FORM_rnglistx, which makes it larger and ambiguous) 3) DW_AT_rnglists_base attribute is gone from the skeleton (again, unlike LLVM where it is just confusing what exactly it means because it is inherited; it would make sense if we emitted DW_FORM_rnglistx in non-split DWARF, but unless ranges are shared, I'm afraid we'd make DWARF larger with fewer relocations by that) 4) usually big .debug_rnglists.dwo section again with using DW_RLE_*x* where possible 5) DW_AT_ranges with DW_FORM_rnglistx from .debug_info.dwo referring to that .debug_rnglists.dwo ranges 2021-03-31 Jakub Jelinek <jakub@redhat.com> PR debug/99490 * dwarf2out.c (debug_ranges_dwo_section): New variable. (DW_RANGES_IDX_SKELETON): Define. (struct dw_ranges): Add begin_entry and end_entry members. (DEBUG_DWO_RNGLISTS_SECTION): Define. (add_ranges_num): Adjust r initializer for addition of *_entry members. (add_ranges_by_labels): For -gsplit-dwarf and force_direct, set idx to DW_RANGES_IDX_SKELETON. (use_distinct_base_address_for_range): New function. (index_rnglists): Don't set r->idx if it is equal to DW_RANGES_IDX_SKELETON. Initialize r->begin_entry and r->end_entry for -gsplit-dwarf if those will be needed by output_rnglists. (output_rnglists): Add DWO argument. If true, switch to debug_ranges_dwo_section rather than debug_ranges_section. Adjust l1/l2 label indexes. Only output the offset table when dwo is true and don't include in there the skeleton range entry if present. For -gsplit-dwarf, skip ranges that belong to the other rnglists section. Change return type from void to bool and return true if there are any range entries for the other section. For dwarf_split_debug_info use DW_RLE_startx_endx, DW_RLE_startx_length and DW_RLE_base_addressx entries instead of DW_RLE_start_end, DW_RLE_start_length and DW_RLE_base_address. Use use_distinct_base_address_for_range. (init_sections_and_labels): Initialize debug_ranges_dwo_section if -gsplit-dwarf and DWARF >= 5. Adjust ranges_section_label and range_base_label indexes. (dwarf2out_finish): Call index_rnglists earlier before finalizing .debug_addr. Never emit DW_AT_rnglists_base attribute. For -gsplit-dwarf and DWARF >= 5 call output_rnglists up to twice with different dwo arguments. (dwarf2out_c_finalize): Clear debug_ranges_dwo_section.
2021-03-31gimple-fold: Recompute ADDR_EXPR flags after folding a TMR [PR98268]Richard Sandiford3-0/+23
The gimple verifier picked up that an ADDR_EXPR of a MEM_REF was not marked TREE_CONSTANT even though the address was in fact invariant. This came from folding a &TARGET_MEM_REF with constant operands to a &MEM_REF; &TARGET_MEM_REF is never treated as TREE_CONSTANT but &MEM_REF can be. gcc/ PR tree-optimization/98268 * gimple-fold.c (maybe_canonicalize_mem_ref_addr): Call recompute_tree_invariant_for_addr_expr after successfully folding a TARGET_MEM_REF that occurs inside an ADDR_EXPR. gcc/testsuite/ PR tree-optimization/98268 * gcc.target/aarch64/sve/pr98268-1.c: New test. * gcc.target/aarch64/sve/pr98268-2.c: Likewise.
2021-03-31data-ref: Tighten index-based alias checks [PR99726]Richard Sandiford2-117/+143
create_intersect_range_checks_index tries to create a runtime alias check based on index comparisons. It looks through the access functions for the two DRs to find a SCEV for the loop that is being versioned and converts a DR_STEP-based check into an index-based check. However, there isn't any reliable sign information in the types, so the code expects the value of the IV step (when interpreted as signed) to be negative iff the DR_STEP (when interpreted as signed) is negative. r10-4762 added another assert related to this assumption and the assert fired for the testcase in the PR. The sign of the IV step didn't match the sign of the DR_STEP. I think this is actually showing what was previously a wrong-code bug. The signs didn't match because the DRs contained *two* access function SCEVs for the loop being versioned. It doesn't look like the code is set up to deal with this, since it checks each access function independently and treats it as the sole source of DR_STEP. The patch therefore moves the main condition out of the loop. This also has the advantage of not building a tree for one access function only to throw it away if we find an inner function that makes the comparison invalid. gcc/ PR tree-optimization/99726 * tree-data-ref.c (create_intersect_range_checks_index): Bail out if there is more than one access function SCEV for the loop being versioned. gcc/testsuite/ PR tree-optimization/99726 * gcc.target/i386/pr99726.c: New test.
2021-03-31Handle CONST_POLY_INTs in CONST_VECTORs [PR97141, PR98726]Richard Sandiford9-18/+68
This PR is caused by POLY_INT_CSTs being (necessarily) valid in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid in RTL CONST_VECTORs. I can't tell/remember how deliberate that was, but I'm guessing not very. In particular, valid_for_const_vector_p was added to guard against symbolic constants rather than CONST_POLY_INTs. I did briefly consider whether we should maintain the current status anyway. However, that would then require a way of constructing variable-length vectors from individiual elements if, say, we have: { [2, 2], [3, 2], [4, 2], … } So I'm chalking this up to an oversight. I think the intention (and certainly the natural thing) is to have the same rules for both trees and RTL. The SVE CONST_VECTOR code should already be set up to handle CONST_POLY_INTs. However, we need to add support for Advanced SIMD CONST_VECTORs that happen to contain SVE-based values. The patch does that by expanding such CONST_VECTORs in the same way as variable vectors. gcc/ PR rtl-optimization/97141 PR rtl-optimization/98726 * emit-rtl.c (valid_for_const_vector_p): Return true for CONST_POLY_INT_P. * rtx-vector-builder.h (rtx_vector_builder::step): Return a poly_wide_int instead of a wide_int. (rtx_vector_builder::apply_set): Take a poly_wide_int instead of a wide_int. * rtx-vector-builder.c (rtx_vector_builder::apply_set): Likewise. * config/aarch64/aarch64.c (aarch64_legitimate_constant_p): Return false for CONST_VECTORs that cannot be forced to memory. * config/aarch64/aarch64-simd.md (mov<mode>): If a CONST_VECTOR is too complex to force to memory, build it up from individual elements instead. gcc/testsuite/ PR rtl-optimization/97141 PR rtl-optimization/98726 * gcc.c-torture/compile/pr97141.c: New test. * gcc.c-torture/compile/pr98726.c: Likewise. * gcc.target/aarch64/sve/pr97141.c: Likewise. * gcc.target/aarch64/sve/pr98726.c: Likewise.
2021-03-31Fix overvactive check in cgraph_node::release_bodyJan Hubicka1-1/+9
gcc/ChangeLog: PR lto/99447 * cgraph.c (cgraph_node::release_body): Fix overactive check.
2021-03-31PR middle-end/65182 - -Wuninitialized fails when pointer to variable later ↵Martin Sebor1-0/+44
passed to function gcc/testsuite: PR middle-end/65182 * gcc.dg/uninit-pr65182.c: New test.
2021-03-31c++: Alias template in pack expansion [PR99445]Jason Merrill2-0/+23
In this testcase, iterative_hash_template_arg checks alias_template_specialization_p to determine whether to treat a type as a dependent alias, and structural_comptypes checks dependent_alias_template_spec_p. Normally that difference isn't a problem because canonicalizing template arguments strips non-dependent aliases, but that wasn't happening for the pack expansion. Fixed thus. gcc/cp/ChangeLog: PR c++/99445 * tree.c (strip_typedefs): Handle TYPE_PACK_EXPANSION. gcc/testsuite/ChangeLog: PR c++/99445 * g++.dg/cpp0x/alias-decl-variadic1.C: New test.
2021-03-31testsuite/aarch64: Skip SLP diagnostic under ILP32 (PR target/96974)Christophe Lyon1-1/+1
The vectorizer has a very different effect with -mabi=ilp32, and doesn't emit the expecte diagnostic, so this patch expects it only under lp64. 2021-03-29 Christophe Lyon <christophe.lyon@linaro.org> gcc/testsuite/ PR target/96974 * g++.target/aarch64/sve/pr96974.C: Expect SLP diagnostic only under lp64.
2021-03-31arm: Fix mult autovectorization patterm for iwmmxt (PR target/99786)Christophe Lyon2-1/+34
Similarly to other recently-added autovectorization patterns, mult has been erroneously enabled for iwmmxt. However, V4HI and V2SI modes are supported, so we make an exception for them. The new testcase is derived from gcc.dg/ubsan/pr79904.c, with additional modes added. I kept dg-do compile because 'assemble' results in error messages from the assembler, which are not related to this PR: Error: selected processor does not support `tmcrr wr0,r4,r5' in ARM mode Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode Error: selected processor does not support `wldrd wr0,[r0]' in ARM mode Error: selected processor does not support `wldrd wr2,.L5' in ARM mode Error: selected processor does not support `wmulul wr0,wr0,wr2' in ARM mode Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode Error: selected processor does not support `wldrd wr0,[r0]' in ARM mode Error: selected processor does not support `wldrd wr2,.L8' in ARM mode Error: selected processor does not support `wmulwl wr0,wr0,wr2' in ARM mode Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode 2021-03-29 Christophe Lyon <christophe.lyon@linaro.org> PR target/99786 gcc/ * config/arm/vec-common.md (mul<mode>3): Disable on iwMMXT, expect for V4HI and V2SI. gcc/testsuite/ * gcc.target/arm/pr99786.c: New test.
2021-03-31x86: Update memcpy/memset inline strategies for Ice LakeH.J. Lu13-7/+259
Simply memcpy and memset inline strategies to avoid branches for -mtune=icelake: 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector load and store for up to 16 * 16 (256) bytes when the data size is fixed and known. 2. Inline only if data size is known to be <= 256. a. Use "rep movsb/stosb" with simple code sequence if the data size is a constant. b. Use loop if data size is not a constant. 3. Use memcpy/memset libray function if data size is unknown or > 256. On Ice Lake processor with -march=native -Ofast -flto, 1. Performance impacts of SPEC CPU 2017 rate are: 500.perlbench_r -0.93% 502.gcc_r 0.36% 505.mcf_r 0.31% 520.omnetpp_r -0.07% 523.xalancbmk_r -0.53% 525.x264_r -0.09% 531.deepsjeng_r -0.19% 541.leela_r 0.16% 548.exchange2_r 0.22% 557.xz_r -1.64% Geomean -0.24% 503.bwaves_r -0.01% 507.cactuBSSN_r 0.00% 508.namd_r 0.12% 510.parest_r 0.07% 511.povray_r 0.29% 519.lbm_r 0.00% 521.wrf_r -0.38% 526.blender_r 0.16% 527.cam4_r 0.18% 538.imagick_r 0.76% 544.nab_r -0.84% 549.fotonik3d_r -0.07% 554.roms_r -0.01% Geomean 0.02% 2. Significant impacts on eembc benchmarks are: eembc/nnet_test 9.90% eembc/mp2decoddata2 16.42% eembc/textv2data3 -4.86% eembc/qos 12.90% gcc/ * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep): For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode to SImode. (decide_alg): For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, use "rep movsb/stosb" only for known sizes. * config/i386/i386-options.c (processor_cost_table): Use Ice Lake cost for Cannon Lake, Ice Lake, Tiger Lake, Sapphire Rapids and Alder Lake. * config/i386/i386.h (TARGET_PREFER_KNOWN_REP_MOVSB_STOSB): New. * config/i386/x86-tune-costs.h (icelake_memcpy): New. (icelake_memset): Likewise. (icelake_cost): Likewise. * config/i386/x86-tune.def (X86_TUNE_PREFER_KNOWN_REP_MOVSB_STOSB): New. gcc/testsuite/ * gcc.target/i386/memcpy-strategy-5.c: New test. * gcc.target/i386/memcpy-strategy-6.c: Likewise. * gcc.target/i386/memcpy-strategy-7.c: Likewise. * gcc.target/i386/memcpy-strategy-8.c: Likewise. * gcc.target/i386/memset-strategy-3.c: Likewise. * gcc.target/i386/memset-strategy-4.c: Likewise. * gcc.target/i386/memset-strategy-5.c: Likewise. * gcc.target/i386/memset-strategy-6.c: Likewise.
2021-03-31aarch64: Fix target alignment for SVE [PR98119]Richard Sandiford2-3/+17
The vectoriser supports peeling for alignment using predication: we move back to the previous aligned boundary and make the skipped elements inactive in the first loop iteration. As it happens, the costs for existing CPUs give an equal cost to aligned and unaligned accesses, so this feature is rarely used. However, the PR shows that when the feature was forced on, we were still trying to align to a full-vector boundary even when using partial vectors. gcc/ PR target/98119 * config/aarch64/aarch64.c (aarch64_vectorize_preferred_vector_alignment): Query the size of the provided SVE vector; do not assume that all SVE vectors have the same size. gcc/testsuite/ PR target/98119 * gcc.target/aarch64/sve/pr98119.c: New test.
2021-03-31Small refactoring of cgraph_node::release_bodyJan Hubicka3-9/+4
PR lto/99447 * cgraph.c (cgraph_node::release_body): Remove all callers and references. * cgraphclones.c (cgraph_node::materialize_clone): Do not do it here. * cgraphunit.c (cgraph_node::expand): And here.
2021-03-31Fix coding style in IPA modref.Martin Liska1-3/+3
gcc/ChangeLog: * ipa-modref.c (analyze_ssa_name_flags): Fix coding style and one negated condition.
2021-03-31aarch64: Fix up *add<mode>3_poly_1 [PR99813]Jakub Jelinek2-2/+29
As mentioned in the PR, Uai constraint stands for aarch64_sve_scalar_inc_dec_immediate while Uav for aarch64_sve_addvl_addpl_immediate. Both *add<mode>3_aarch64 and *add<mode>3_poly_1 patterns use * return aarch64_output_sve_scalar_inc_dec (operands[2]); * return aarch64_output_sve_addvl_addpl (operands[2]); in that order, but the former with Uai,Uav order, while the latter with Uav,Uai instead. This patch swaps the constraints so that they match the output. Co-authored-by: Richard Sandiford <richard.sandiford@arm.com> 2021-03-31 Jakub Jelinek <jakub@redhat.com> Richard Sandiford <richard.sandiford@arm.com> PR target/99813 * config/aarch64/aarch64.md (*add<mode>3_poly_1): Swap Uai and Uav constraints on operands[2] and similarly 0 and rk constraints on operands[1] corresponding to that. * g++.target/aarch64/sve/pr99813.C: New test.
2021-03-31i386, debug: Default to -gdwarf-4 on Windows targets with broken ld.bfd ↵Jakub Jelinek4-13/+69
[PR98860] As mentioned in the PR, before the https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0 fix from March 1st, PECOFF ld.bfd didn't know about .debug_loclists, .debug_rnglists and other debug sections new in DWARF 5. Unfortunately, unlike for ELF linkers, that means the sections were placed in wrong ordering with wrong VMA/LMA, so the resulting executables are apparently unusable. As that is pretty new change, newer than 2.35.2 or 2.36 binutils releases, the following patch adds a workaround that turns -gdwarf-4 by default instead of -gdwarf-5 if a broken linker is found at configure time. Users can still explicitly play with -gdwarf-5 and either use a non-broken linker or use custom linker scripts for the broken one, but at least by default it should work. 2021-03-31 Jakub Jelinek <jakub@redhat.com> PR bootstrap/98860 * configure.ac (HAVE_LD_BROKEN_PE_DWARF5): New AC_DEFINE if PECOFF linker doesn't support DWARF sections new in DWARF5. * config/i386/i386-options.c (ix86_option_override_internal): Default to dwarf_version 4 if HAVE_LD_BROKEN_PE_DWARF5 for TARGET_PECOFF targets. * config.in: Regenerated. * configure: Regenerated.
2021-03-31testsuite: Disable zero-scratch-regs-{8, 9, 10, 11}.c on all but ... [PR97680]Jakub Jelinek6-5/+6
Seems the target hook is only defined on config/i386/i386.c:#undef TARGET_ZERO_CALL_USED_REGS config/i386/i386.c:#define TARGET_ZERO_CALL_USED_REGS ix86_zero_call_used_regs config/sparc/sparc.c:#undef TARGET_ZERO_CALL_USED_REGS config/sparc/sparc.c:#define TARGET_ZERO_CALL_USED_REGS sparc_zero_call_used_regs but apparently many of the tests actually succeed on various targets that don't define those hooks. E.g. I haven't seen them to fail on aarch64, on arm only the -10.c fails, on powerpc*/s390* all {8,9,10,11} fail (plus 5 is skipped on power*-aix*). On ia64 according to testresults {6,7,8,9,10,11} fail, some with ICEs. On mipsel according to testresults {9,10,11} fail, some with ICEs. On nvptx at least 1-9 succeed, 10-11 don't know, don't have assert.h around. I've kept {5,6,7} with aix,ia64,ia64 skipped because those seems like outliers, it works pretty much everywhere but on those. The rest have known good targets. 2021-03-31 Jakub Jelinek <jakub@redhat.com> PR testsuite/97680 * c-c++-common/zero-scratch-regs-6.c: Skip on ia64. * c-c++-common/zero-scratch-regs-7.c: Likewise. * c-c++-common/zero-scratch-regs-8.c: Change from dg-skip-if of selected unsupported triplets to all targets but selected triplets of supported targets. * c-c++-common/zero-scratch-regs-9.c: Likewise. * c-c++-common/zero-scratch-regs-10.c: Likewise. * c-c++-common/zero-scratch-regs-11.c: Likewise.
2021-03-30c++: Adjust mangling of __alignof__ [PR88115]Patrick Palka2-7/+5
r11-4926 made __alignof__ get mangled differently from alignof, encoding __alignof__ as a vendor extended operator. But this mangling is problematic for the reasons mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6. This patch changes our mangling of __alignof__ to instead use the new "vendor extended expression" syntax that's proposed in https://github.com/itanium-cxx-abi/cxx-abi/issues/112. Clang does the same thing already, so after this patch Clang and GCC agree about the mangling of __alignof__(type) and __alignof__(expr). gcc/cp/ChangeLog: PR c++/88115 * mangle.c (write_expression): Adjust the mangling of __alignof__. include/ChangeLog: PR c++/88115 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_VENDOR_EXPR. libiberty/ChangeLog: PR c++/88115 * cp-demangle.c (d_dump, d_make_comp, d_expression_1) (d_count_templates_scopes): Handle DEMANGLE_COMPONENT_VENDOR_EXPR. (d_print_comp_inner): Likewise. <case DEMANGLE_COMPONENT_EXTENDED_OPERATOR>: Revert r11-4926 change. <case DEMANGLE_COMPONENT_UNARY>: Likewise. * testsuite/demangle-expected: Adjust __alignof__ tests. gcc/testsuite/ChangeLog: PR c++/88115 * g++.dg/cpp0x/alignof7.C: Adjust expected mangling.
2021-03-30c++: placeholder type constraint and argument pack [PR99815]Patrick Palka2-0/+37
When checking dependence of a placeholder type constraint, if the first template argument of the constraint is an argument pack, we need to expand it in order to properly separate the implicit 'auto' argument from the rest. gcc/cp/ChangeLog: PR c++/99815 * pt.c (placeholder_type_constraint_dependent_p): Expand argument packs to separate the first non-pack argument from the rest. gcc/testsuite/ChangeLog: PR c++/99815 * g++.dg/cpp2a/concepts-placeholder5.C: New test.
2021-03-31Daily bump.GCC Administrator5-1/+176
2021-03-30analyzer: remove old decl of region::dump_to_ppDavid Malcolm1-5/+0
This was made redundant in the GCC 11 rewrite of state (808f4dfeb3a95f50f15e71148e5c1067f90a126d). gcc/analyzer/ChangeLog: * region.h (region::dump_to_pp): Remove old decl.
2021-03-30analyzer: only call get_diagnostic_tree when it's neededDavid Malcolm4-8/+16
impl_sm_context::get_diagnostic_tree could be expensive, and I find myself needing to put a breakpoint on it to debug PR analyzer/99771, so only call it if we're about to use the result. gcc/analyzer/ChangeLog: * sm-file.cc (fileptr_state_machine::on_stmt): Only call get_diagnostic_tree if the result will be used. * sm-malloc.cc (malloc_state_machine::on_stmt): Likewise. (malloc_state_machine::on_deallocator_call): Likewise. (malloc_state_machine::on_realloc_call): Likewise. (malloc_state_machine::on_realloc_call): Likewise. * sm-sensitive.cc (sensitive_state_machine::warn_for_any_exposure): Likewise. * sm-taint.cc (taint_state_machine::on_stmt): Likewise.
2021-03-30analyzer testsuite: fix typoDavid Malcolm1-1/+1
gcc/testsuite/ChangeLog: * gcc.dg/analyzer/symbolic-1.c: Fix typo.
2021-03-30c++: duplicate const static members [PR 99283]Nathan Sidwell5-8/+54
This is the bug that keeps on giving. Reducing it has been successful at hitting other defects. In this case, some more specialization hash table fun, plus an issue with reading in a definition of a duplicated declaration. At least I discovered a null context check is no longer needed. PR c++/99283 gcc/cp/ * module.cc (dumper::operator): Make less brittle. (trees_out::core_bools): VAR_DECLs always have a context. (trees_out::key_mergeable): Use same_type_p for asserting. (trees_in::read_var_def): Propagate DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P. gcc/testsuite/ * g++.dg/modules/pr99283-5.h: New. * g++.dg/modules/pr99283-5_a.H: New. * g++.dg/modules/pr99283-5_b.H: New. * g++.dg/modules/pr99283-5_c.C: New.
2021-03-30c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790]Jakub Jelinek2-0/+17
The following testcase ICEs (since the addition of inline var support), because the lambda contains PTRMEM_CST but finish_function is called for the lambda quite early during parsing it (from finish_lambda_function) when the containing class is still incomplete. That means that during genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but later nothing lowers it when the class is finalized. Using sizeof etc. on the class in such contexts is rejected by both g++ and clang++, and when the PTRMEM_CST appears e.g. in static var initializers rather than in functions, we handle it correctly because c_parse_final_cleanups -> lower_var_init will handle those cplus_expand_constant when all classes are already finalized. The following patch fixes it by calling cplus_expand_constant again during gimplification, as we are now unconditionally unit at a time, I'd think everything that could be completed will be before we start gimplification. 2021-03-30 Jakub Jelinek <jakub@redhat.com> PR c++/99790 * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST. * g++.dg/cpp1z/pr99790.C: New test.
2021-03-30aarch64: PR target/99820: Guard on available SVE issue info before usingKyrylo Tkachov1-1/+3
This fixes a simple segfault ICE when using the use_new_vector_costs tunable with a CPU tuning that it wasn't intended for. I'm not adding a testcase here as we intend to remove the tunable for GCC 12 anyway (the new costing logic will remain and will benefit from this extra check, but the -moverride option will no longer exist). gcc/ChangeLog: PR target/99820 * config/aarch64/aarch64.c (aarch64_analyze_loop_vinfo): Check for available issue_info before using it.
2021-03-30aarch64: PR target/99822 Don't allow zero register in first operand of ↵Kyrylo Tkachov2-1/+42
SUBS/ADDS-immediate In this PR we end up generating an invalid instruction: adds x1,xzr,#2 because the pattern accepts zero as an operand in the comparison, but the instruction doesn't. Fix it by adjusting the predicate and constraints. gcc/ChangeLog: PR target/99822 * config/aarch64/aarch64.md (sub<mode>3_compare1_imm): Do not allow zero in operand 1. gcc/testsuite/ChangeLog: PR target/99822 * gcc.c-torture/compile/pr99822.c: New test.
2021-03-30rs6000: Enable 32bit variable vec_insert [PR99718]luoxhu@cn.ibm.com21-72/+170
32bit and P7 VSX could also benefit a lot from the variable vec_insert implementation with shift/insert/shift back method. 2011-03-29 Xionghu Luo <luoxhu@linux.ibm.com> PR target/99718 * config/rs6000/altivec.md (altivec_lvsl_reg): Change to ... (altivec_lvsl_reg_<mode>): ... this. (altivec_lvsr_reg): Change to ... (altivec_lvsr_reg_<mode>): ... this. * config/rs6000/predicates.md (vec_set_index_operand): New. * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Enable 32bit variable vec_insert for all TARGET_VSX. * config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9): Enable 32bit variable vec_insert for p9 and above. (rs6000_expand_vector_set_var_p8): Rename to ... (rs6000_expand_vector_set_var_p7): ... this. (rs6000_expand_vector_set): Use TARGET_VSX and adjust assert position. * config/rs6000/vector.md (vec_set<mode>): Use vec_set_index_operand. * config/rs6000/vsx.md (xl_len_r): Use gen_altivec_lvsl_reg_di and gen_altivec_lvsr_reg_di. gcc/testsuite/ PR target/99718 * gcc.target/powerpc/fold-vec-insert-char-p8.c: Update instruction counts. * gcc.target/powerpc/fold-vec-insert-char-p9.c: Likewise. * gcc.target/powerpc/fold-vec-insert-double.c: Likewise. * gcc.target/powerpc/fold-vec-insert-float-p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-float-p9.c: Likewise. * gcc.target/powerpc/fold-vec-insert-int-p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-int-p9.c: Likewise. * gcc.target/powerpc/fold-vec-insert-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-insert-short-p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-short-p9.c: Likewise. * gcc.target/powerpc/pr79251.p8.c: Likewise. * gcc.target/powerpc/pr79251.p9.c: Likewise. * gcc.target/powerpc/vsx-builtin-7.c: Likewise. * gcc.target/powerpc/pr79251-run.p7.c: New test. * gcc.target/powerpc/pr79251.p7.c: New test.
2021-03-30x86: Define __rdtsc and __rdtscp as macrosH.J. Lu2-12/+27
Define __rdtsc and __rdtscp as macros for callers with general-regs-only target attribute to avoid inline failure with always_inline attribute. gcc/ PR target/99744 * config/i386/ia32intrin.h (__rdtsc): Defined as macro. (__rdtscp): Likewise. gcc/testsuite/ PR target/99744 * gcc.target/i386/pr99744-1.c: New test.
2021-03-30slp: reject non-multiple of 2 laned SLP trees (PR99825)Tamar Christina2-1/+17
TWO_OPERANDS allows any order or number of combinations of + and - operations but the pattern matcher only supports pairs of operations. This patch has the pattern matcher for complex numbers reject SLP trees where the lanes are not a multiple of 2. gcc/ChangeLog: PR tree-optimization/99825 * tree-vect-slp-patterns.c (vect_check_evenodd_blend): Reject non-mult 2 lanes. gcc/testsuite/ChangeLog: PR tree-optimization/99825 * gfortran.dg/vect/pr99825.f90: New test.
2021-03-30arm: Fix emission of Tag_ABI_VFP_args with MVE and -mfloat-abi=hard (PR ↵Christophe Lyon1-7/+4
target/99773) When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we want to emit Tag_ABI_VFP_args even though we are not emitting floating-point instructions (we need "+mve.fp" for that), because we use MVE registers to pass FP arguments. This patch removes the condition on (! TARGET_SOFT_FLOAT) because this is a case where TARGET_SOFT_FLOAT is true, and TARGET_HARD_FLOAT_ABI is true too. 2021-03-30 Richard Earnshaw <rearnsha@arm.com> gcc/ PR target/99773 * config/arm/arm.c (arm_file_start): Fix emission of Tag_ABI_VFP_args attribute.
2021-03-30aarch64: Fix gcc.target/aarch64/pr99808.c for ILP32Kyrylo Tkachov1-2/+2
Fix test for -mabi=ilp32 gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: Use ULL constant suffix.
2021-03-30tree-optimization/99824 - avoid excessive integer type precision in VNRichard Biener3-10/+49
VN sometimes builds new integer types to handle accesss where precision of the access type does not match the access size. The way ao_ref_init_from_vn_reference is computing the access size ignores the access type in case the ref operands have an outermost COMPONENT_REF which, in case it is an array for example, can be way larger than the access size. This can cause us to try building an integer type with precision larger than WIDE_INT_MAX_PRECISION eventually leading to memory corruption. The following adjusts ao_ref_init_from_vn_reference to only lower access sizes via the outermost COMPONENT_REF but otherwise honor the access size as specified by the access type. It also places an assert in integer type building that we remain in the limits of WIDE_INT_MAX_PRECISION. I chose the shared code where we set TYPE_MIN/MAX_VALUE because that will immediately cross the wide_ints capacity otherwise. 2021-03-30 Richard Biener <rguenther@suse.de> PR tree-optimization/99824 * stor-layout.c (set_min_and_max_values_for_integral_type): Assert the precision is within the bounds of WIDE_INT_MAX_PRECISION. * tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use the outermost component ref only to lower the access size and initialize that from the access type. * gcc.dg/torture/pr99824.c: New testcase.
2021-03-30aarch64: Tweak post-RA handling of CONST_INT moves [PR98136]Richard Sandiford2-4/+39
This PR is a regression caused by r8-5967, where we replaced a call to aarch64_internal_mov_immediate in aarch64_add_offset with a call to aarch64_force_temporary, which in turn uses the normal emit_move_insn{,_1} routines. The problem is that aarch64_add_offset can be called while outputting a thunk, where we require all instructions to be valid without splitting. However, the move expanders were not splitting CONST_INT moves themselves. I think the right fix is to make the move expanders work even in this scenario, rather than require callers to handle it as a special case. gcc/ PR target/98136 * config/aarch64/aarch64.md (mov<mode>): Pass multi-instruction CONST_INTs to aarch64_expand_mov_immediate when called after RA. gcc/testsuite/ PR target/98136 * g++.dg/pr98136.C: New test.
2021-03-30aarch64: Prevent use of SIMD fcvtz[su] instruction variant with "nosimd"Mihailo Stojanovic2-1/+25
Currently, SF->SI and DF->DI conversions on Aarch64 with the "nosimd" flag provided sometimes cause the emitting of a vector variant of the fcvtz[su] instruction (e.g. fcvtzu s0, s0). This modifies the corresponding pattern to only select the vector variant of the instruction when generating code with SIMD enabled. gcc/ChangeLog: * config/aarch64/aarch64.md (<optab>_trunc<fcvt_target><GPI:mode>2): Set the "arch" attribute to disambiguate between SIMD and FP variants of the instruction. gcc/testsuite/ChangeLog: * gcc.target/aarch64/fcvt_nosimd.c: New test.
2021-03-30Daily bump.GCC Administrator5-1/+106
2021-03-29Update gcc sv.po.Joseph Myers1-196/+146
* sv.po: Update.
2021-03-30Fix wrong assignment of aggregate to full-access componentEric Botcazou1-2/+1
This is a regression present on the mainline: the compiler (front-end) fails to assign an aggregate to a full-access component (i.e. Atomic or VFA) as a whole if the type of the component is not full access itself. gcc/ada/ PR ada/99802 * freeze.adb (Is_Full_Access_Aggregate): Call Is_Full_Access_Object on the name of an N_Assignment_Statement to spot full access.
2021-03-29PR tree-optimization/61869 - Spurious uninitialized warningMartin Sebor1-0/+47
gcc/testsuite/ChangeLog: PR tree-optimization/61869 * gcc.dg/uninit-pr61869.c: New test.
2021-03-29PR tree-optimization/61677 - False positive with -Wmaybe-uninitializedMartin Sebor1-0/+26
gcc/testsuite/ChangeLog: PR tree-optimization/61677 * gcc.dg/uninit-pr61677.c: New test.
2021-03-29PR tree-optimization/61112 - repeated conditional triggers false positive ↵Martin Sebor1-0/+89
-Wmaybe-uninitialized gcc/testsuite/ChangeLog: PR tree-optimization/61112 * gcc.dg/uninit-pr61112.c: New test.
2021-03-29Fix pr99751.c testcaseJan Hubicka1-0/+0
PR ipa/99751 * gcc.c-torture/compile/pr99751.c: Rename from ... * gcc.c-torture/execute/pr99751.c: ... to this.
2021-03-29Fix typo in merge_call_lhs_flagsJan Hubicka2-3/+23
gcc/ChangeLog: 2021-03-29 Jan Hubicka <hubicka@ucw.cz> * ipa-modref.c (merge_call_lhs_flags): Correct handling of deref. (analyze_ssa_name_flags): Fix typo in comment. gcc/testsuite/ChangeLog: 2021-03-29 Jan Hubicka <hubicka@ucw.cz> * gcc.c-torture/compile/pr99751.c: New test.
2021-03-29testsuite: Expect a warning on aarch64 for declare-simd-coarray-lib.f90 ↵Jakub Jelinek1-1/+1
[PR93660] aarch64 currently doesn't support declare simd where the return value and arguments have different sizes and warns about that case. This change adds a dg-warning for that case like various other tests have already. 2021-03-29 Jakub Jelinek <jakub@redhat.com> PR fortran/93660 * gfortran.dg/gomp/declare-simd-coarray-lib.f90: Expect a mixed size declare simd warning on aarch64.
2021-03-29aarch64: Fix SVE ACLE builtins with LTO [PR99216]Alex Coplan3-24/+43
As discussed in the PR, we currently have two different numbering schemes for SVE builtins: one for C, and one for C++. This is problematic for LTO, where we end up getting confused about which intrinsic we're talking about. This patch inserts placeholders into the registered_functions vector to ensure that there is a consistent numbering scheme for both C and C++. We use integer_zero_node as a placeholder node instead of building a function decl. This is safe because the node is only returned by the TARGET_BUILTIN_DECL hook, which (on AArch64) is only used for validation when builtin decls are streamed into lto1. gcc/ChangeLog: PR target/99216 * config/aarch64/aarch64-sve-builtins.cc (function_builder::add_function): Add placeholder_p argument, use placeholder decls if this is set. (function_builder::add_unique_function): Instead of conditionally adding direct overloads, unconditionally add either a direct overload or a placeholder. (function_builder::add_overloaded_function): Set placeholder_p if we're using C++ overloads. Use the obstack for string storage instead of relying on the tree nodes. (function_builder::add_overloaded_functions): Don't return early for m_direct_overloads: we need to add placeholders. * config/aarch64/aarch64-sve-builtins.h (function_builder::add_function): Add placeholder_p argument. gcc/testsuite/ChangeLog: PR target/99216 * g++.target/aarch64/sve/pr99216.C: New test.
2021-03-29tree-optimization/99807 - avoid bogus assert with permute SLP nodeRichard Biener2-1/+12
This avoids asserting anything on the SLP_TREE_REPRESENTATIVE of an SLP permute node (which shouldn't be there). 2021-03-29 Richard Biener <rguenther@suse.de> PR tree-optimization/99807 * tree-vect-slp.c (vect_slp_analyze_node_operations_1): Move assert below VEC_PERM handling. * gfortran.dg/vect/pr99807.f90: New testcase.
2021-03-29aarch64: PR target/99037 Fix RTL represntation in move_lo_quad patternsKyrylo Tkachov3-42/+24
This patch fixes the RTL representation of the move_lo_quad patterns to use aarch64_simd_or_scalar_imm_zero for the zero part rather than a vec_duplicate of zero or a const_int 0. The expander that generates them is also adjusted so that we use and match the correct const_vector forms throughout. Co-Authored-By: Jakub Jelinek <jakub@redhat.com> gcc/ChangeLog: PR target/99037 * config/aarch64/aarch64-simd.md (move_lo_quad_internal_<mode>): Use aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern matching const_int 0. (move_lo_quad_internal_be_<mode>): Likewise. (move_lo_quad_<mode>): Update for the above. * config/aarch64/iterators.md (VQ_2E): Delete. gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: New test.
2021-03-29fold-const: Fix ICE in extract_muldiv_1 [PR99777]Jakub Jelinek2-4/+48
extract_muldiv{,_1} is apparently only prepared to handle scalar integer operations, the callers ensure it by only calling it if the divisor or one of the multiplicands is INTEGER_CST and because neither multiplication nor division nor modulo are really supported e.g. for pointer types, nullptr type etc. But the CASE_CONVERT handling doesn't really check if it isn't a cast from some other type kind, so on the testcase we end up trying to build MULT_EXPR in POINTER_TYPE which ICEs. A few years ago Marek has added ANY_INTEGRAL_TYPE_P checks to two spots, but the code uses TYPE_PRECISION which means something completely different for vector types, etc. So IMNSHO we should just punt on conversions from non-integrals or non-scalar integrals. 2021-03-29 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/99777 * fold-const.c (extract_muldiv_1): For conversions, punt on casts from types other than scalar integral types. * g++.dg/torture/pr99777.C: New test.
2021-03-29Daily bump.GCC Administrator5-1/+75
2021-03-28aix: TLS DWARF symbol decorations.David Edelsohn1-20/+0
GCC currently emits TLS relocation decorations on symbols in DWARF sections. Recent changes to the AIX linker cause it to reject such symbols. This patch removes the decorations (@ie, @le, @m) and emit only the qualified symbol name. gcc/ChangeLog: * config/rs6000/rs6000.c (rs6000_output_dwarf_dtprel): Do not add XCOFF TLS reloc decorations.
generated by cgit v1.1 at 2025-09-22 04:44:00 +0000