aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-11libgo: update to Go1.18beta2Ian Lance Taylor1980-36277/+84209
gotools/ * Makefile.am (go_cmd_cgo_files): Add ast_go118.go (check-go-tool): Copy golang.org/x/tools directories. * Makefile.in: Regenerate. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384695
2022-02-11libstdc++: Fix FAIL: 20_util/temporary_buffer.cc for C++14Jonathan Wakely1-1/+1
The std::get_temporary_buffer function is deprecated since C++17, but the test was expecting a warning for C++14 as well. libstdc++-v3/ChangeLog: * testsuite/20_util/temporary_buffer.cc: Fix dg-warning target selector.
2022-02-11libstdc++: Fix test failures at -O0Jonathan Wakely3-0/+7
libstdc++-v3/ChangeLog: * testsuite/20_util/monotonic_buffer_resource/allocate.cc: Ignore -Walloc-larger-than warning. * testsuite/20_util/unsynchronized_pool_resource/allocate.cc: Likewise. * testsuite/29_atomics/atomic/cons/user_pod.cc: Compile with -O1 to avoid linker error for __atomic_is_lock_free.
2022-02-11match.pd: Fix up (X & Y) CMP 0 -> X CMP2 ~Y simplifications [PR104499]Jakub Jelinek2-1/+12
The following testcase ICEs on x86_64-linux, because match.pd emits there a NOP_EXPR cast from int*8 vector type with BLKmode to unsigned*8 vector type with BLKmode and vec-lowering isn't prepared to handle such casts. Fixed by using VIEW_CONVERT_EXPR instead. 2022-02-11 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/104499 * match.pd ((X & Y) CMP 0 -> X CMP2 ~Y): Use view_convert instead of convert. * gcc.c-torture/compile/pr104499.c: New test.
2022-02-11middle-end: Small __builtin_clear_padding improvementsJakub Jelinek3-19/+12
When looking at __builtin_clear_padding today, I've noticed that it is quite wasteful to extend the original user one argument to 3, 2 is enough. We need to encode the original type of the first argument because pointer conversions are useless in GIMPLE, and we need to record a boolean whether it is for -ftrivial-auto-var-init=* or not. But for recording the type we don't need the value (we've always used zero) and for recording the boolean we don't need the type (we've always used integer_type_node). So, this patch merges the two into one. 2022-02-11 Jakub Jelinek <jakub@redhat.com> * tree.cc (build_common_builtin_nodes): Fix up formatting in __builtin_clear_padding decl creation. * gimplify.cc (gimple_add_padding_init_for_auto_var): Encode for_auto_init in the value of 2nd BUILT_IN_CLEAR_PADDING argument rather than in 3rd argument. (gimplify_call_expr): Likewise. Fix up comment formatting. * gimple-fold.cc (gimple_fold_builtin_clear_padding): Expect 2 arguments instead of 3, take for_auto_init from the value of 2nd argument.
2022-02-11[PR104400] LRA: Modify exclude start hard register calculation for insn ↵Vladimir N. Makarov3-2/+57
alternative v850 target has an interesting insn alternative constraint 'e!r' where e denotes even general regs and e is a subset of r. We cannot just make union of exclude start hard registers for e and r and should use only exclude start hard registers of r. The following patch implements this. gcc/ChangeLog: PR rtl-optimization/104400 * lra-constraints.cc (process_alt_operands): Don't make union of this_alternative_exclude_start_hard_regs when reg class in insn alternative covers other reg classes in the same alternative. gcc/testsuite/ChangeLog: PR rtl-optimization/104400 * gcc.target/v850/pr104400.c: New. * gcc.target/v850/v850.exp: New.
2022-02-11analyzer: ignore uninitialized uses of empty types [PR104274]David Malcolm2-1/+27
PR analyzer/104274 reports a false positive from -Wanalyzer-use-of-uninitialized-value on hppa when passing an empty struct as a function parameter. pa_pass_by_reference returns true for empty structs, so the call is turned into: struct empty arg.0; arg.0 = arg called_function (arg.0); by gimplify_parameters. However, gimplify_modify_expr discards assignments statments of empty types, so that we end up with: struct empty arg.0; called_function (arg.0); which the analyzer considers to be a use of uninitialized "arg.0"; Given that gimplify_modify_expr will discard any assignments to such types, it seems simplest for -Wanalyzer-use-of-uninitialized-value to ignore values of empty types. gcc/analyzer/ChangeLog: PR analyzer/104274 * region-model.cc (region_model::check_for_poison): Ignore uninitialized uses of empty types. gcc/testsuite/ChangeLog: PR analyzer/104274 * gcc.dg/analyzer/torture/empty-struct-1.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-11[gimplefe] Add vector_mask attribute to get access to vector boolsRichard Biener3-4/+64
The following adds __attribute__((vector_mask)) to get access to the corresponding mask type for a vector type. The implementation simply uses truth_type_for so creating a mask type that's not what the target would choose as canonical, say a AVX2 style one when AVX512VL is enabled, is not possible. It might be possible to provide access to that with an optional argument specifying the precision of the bool element. The syntax is as simple as typedef vector_type mask_type __attribute__((vector_mask)); In theory this allows to create unit testcases for vector lowering and ISEL. 2022-02-11 Richard Biener <rguenther@suse.de> gcc/c-family/ * c-attribs.cc (c_common_attribute_table): Add entry for vector_mask. (handle_vector_mask_attribute): New. gcc/c/ * gimple-parser.cc (c_parser_gimple_statement): Properly parse VEC_COND_EXPRs. gcc/testsuite/ * gcc.dg/gimplefe-48.c: New testcase.
2022-02-11c++: Fix up constant expression __builtin_convertvector folding [PR104472]Jakub Jelinek2-6/+12
The following testcase ICEs, because due to the -frounding-math fold_const_call fails, which is it returns NULL, and returning NULL from cxx_eval* is wrong, all the callers rely on them to either return folded value or original with *non_constant_p = true. The following patch does that, and additionally falls through into the default case where there is diagnostics for the !ctx->quiet case too. 2022-02-11 Jakub Jelinek <jakub@redhat.com> PR c++/104472 * constexpr.cc (cxx_eval_internal_function) <case IFN_VEC_CONVERT>: Only return fold_const_call result if it is non-NULL. Otherwise fall through into the default: case to return t, set *non_constant_p and emit diagnostics if needed. * g++.dg/cpp0x/constexpr-104472.C: New test.
2022-02-11combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument [PR104446]Jakub Jelinek2-0/+21
The following testcase ICEs, because combine substitutes (insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ]) (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal} (nil)) (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A32]) (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2} (expr_list:REG_DEAD (reg:SI 85) (expr_list:REG_ARGS_SIZE (const_int 16 [0x10]) (nil)))) forming (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0 S4 A32]) (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2} (expr_list:REG_DEAD (reg:SI 85) (expr_list:REG_ARGS_SIZE (const_int 16 [0x10]) (nil)))) which is invalid RTL (pre_dec's argument must be a REG). I know substitution creates various forms of invalid RTL and hopes that invalid RTL just won't recog. But unfortunately in this case we ICE before we get to recog, as try_combine does: if (n_auto_inc) { int new_n_auto_inc = 0; for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc); if (n_auto_inc != new_n_auto_inc) { if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Number of auto_inc expressions changed\n"); undo_all (); return 0; } } and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case: case PRE_DEC: case POST_DEC: { poly_int64 size = GET_MODE_SIZE (GET_MODE (mem)); rtx r1 = XEXP (x, 0); rtx c = gen_int_mode (-size, GET_MODE (r1)); return fn (mem, x, r1, r1, c, data); } and that code rightfully expects that the PRE_DEC operand has non-VOIDmode (as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE. I think it is better not to emit the clearly invalid RTL during substitution like we do for other cases, than to adding workarounds for invalid IL created by combine to rtlanal.cc and perhaps elsewhere. As for the testcase, of course it is UB at runtime to modify sp that way, but if such code is never reached, we must compile it, not to ICE on it. And I don't see why on other targets which use the autoinc rtxes much more it couldn't happen with other registers. 2022-02-11 Jakub Jelinek <jakub@redhat.com> PR middle-end/104446 * combine.cc (subst): Don't substitute CONST_INTs into RTX_AUTOINC operands. * gcc.target/i386/pr104446.c: New test.
2022-02-11middle-end/104496 - fix vectorized_internal_fn_supported_pRichard Biener2-1/+14
This fixes vectorized_internal_fn_supported_p behavior when facing vector types with an integer mode. 2022-02-11 Richard Biener <rguenther@suse.de> PR middle-end/104496 * internal-fn.cc (vectorized_internal_fn_supported_p): Bail out for integer mode vector types. * gcc.target/i386/pr104496.c: New testcase.
2022-02-11df: Don't set bbs dirty because of debug insn moves [PR104459]Jakub Jelinek2-2/+42
As mentioned in the PR, we get -fcompare-debug failure, which is caused by cfg_layout_merge_blocks successfully merging two bbs where both bbs contained just CODE_LABEL, NOTE_INSN_BASIC_BLOCK and in the -g case both some debug insns at the end. cfg_layout_merge_blocks calls update_bb_for_insn_chain which for the post-label insns in the second block (except for BARRIERs) calls df_insn_change_bb. This function changes the bb of the insns and for notes just punts, but for other insns calls df_set_bb_dirty. Now the problem is that because there were only debug insns and notes in the second block, df_set_bb_dirty is called on both only in the -g case and not with -g0. df_set_bb_dirty these days sets both the BB_MODIFIED flag and marks the bb as dirty, and the former is what 6 spots in cfgcleanup.cc use in code-generation decisions, in this case may_thread |= (target->flags & BB_MODIFIED) != 0; in particular. So, with -g may_thread is true while with -g0 it is not and we diverge from that point onwards. I've thought about introducing df_set_bb_dirty_nondebug that wouldn't set BB_MODIFIED but would mark the bb dirty, but then I went through history and found changes like: https://gcc.gnu.org/legacy-ml/gcc-patches/2010-10/msg00059.html so I've also tried just not calling df_set_bb_dirty for debug insns at all and it passed x86_64-linux and i686-linux --enable-checking=yes,rtl,extra,df bootstraps/regtests, so perhaps that works too. Now that I look at it again, if we don't need those from %d to %d messages for debug insns in the dump files, another way to fix it would be just to change the very first line in the hunk from if (!INSN_P (insn)) to if (!DEBUG_INSN_P (insn)) Though, df_set_bb_dirty_nondebug which will do everything but set bb->flags |= BB_MODIFIED is yet another option I can test. Perhaps even that PR42889 was solely about those 6 decisions in cfgcleanup (at that point it used df_get_bb_dirty) and not about actually the recomputation of some of the problems causing different code generations. 2022-02-11 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/104459 * df-scan.cc (df_insn_change_bb): Don't call df_set_bb_dirty when moving DEBUG_INSNs between bbs. * gcc.dg/pr104459.c: New test.
2022-02-11Add single_use to simplification (uncond_op + vec_cond -> cond_op).liuhongt3-6/+42
gcc/ChangeLog: PR tree-optimization/104479 * match.pd (uncond_op + vec_cond -> cond_op): Add single_use for the dest of uncond_op. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104479.c: New test. * gcc.target/i386/cond_op_shift_w-1.c: Adjust testcase.
2022-02-11[testsuite] Require non_strict_prototype in a few testsTom de Vries2-0/+4
Require effective target non_strict_prototype in a few test-cases. Tested on nvptx. gcc/testsuite/ChangeLog: 2022-02-10 Tom de Vries <tdevries@suse.de> * gcc.c-torture/compile/pr100576.c: Require effective target non_strict_prototype. * gcc.c-torture/compile/pr97576.c: Same.
2022-02-11[testsuite] Require alloca support in a few testsTom de Vries41-24/+66
Require effective target alloca in a few test-cases. Tested on nvptx. gcc/testsuite/ChangeLog: 2022-02-10 Tom de Vries <tdevries@suse.de> * c-c++-common/Walloca-larger-than.c: Require effective target alloca. * c-c++-common/Warray-bounds-9.c: Same. * c-c++-common/Wdangling-pointer-2.c: Same. * c-c++-common/Wdangling-pointer-4.c: Same. * c-c++-common/Wdangling-pointer-5.c: Same. * c-c++-common/Wdangling-pointer.c: Same. * c-c++-common/auto-init-11.c: Same. * c-c++-common/auto-init-12.c: Same. * c-c++-common/auto-init-15.c: Same. * c-c++-common/auto-init-16.c: Same. * c-c++-common/torture/builtin-clear-padding-4.c: Same. * gcc.c-torture/compile/pr99787-1.c: Same. * gcc.dg/Walloca-larger-than-4.c: Same. * gcc.dg/Wdangling-pointer.c: Same. * gcc.dg/Wfree-nonheap-object-2.c: Same. * gcc.dg/Wfree-nonheap-object.c: Same. * gcc.dg/Wstringop-overflow-56.c: Same. * gcc.dg/Wstringop-overflow-57.c: Same. * gcc.dg/Wstringop-overflow-67.c: Same. * gcc.dg/Wstringop-overflow-71.c: Same. * gcc.dg/Wvla-larger-than-5.c: Same. * gcc.dg/analyzer/taint-alloc-1.c: Same. * gcc.dg/analyzer/torture/ubsan-1.c: Same. * gcc.dg/graphite/pr99085.c: Same. * gcc.dg/pr100225.c: Same. * gcc.dg/pr98721-1.c: Same. * gcc.dg/pr99122-2.c: Same. * gcc.dg/sso-14.c: Same. * gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: Same. * gcc.dg/uninit-38.c: Same. * gcc.dg/uninit-39.c: Same. * gcc.dg/uninit-41.c: Same. * gcc.dg/uninit-pr100250.c: Same. * gcc.dg/uninit-pr101300.c: Same. * gcc.dg/uninit-pr101494.c: Same. * gcc.dg/uninit-pr98578.c: Same. * gcc.dg/uninit-pr98583.c: Same. * gcc.dg/vla-stexp-1.c: Same. * gcc.dg/vla-stexp-2.c: Same. * gcc.dg/vla-stexp-4.c: Same. * gcc.dg/vla-stexp-5.c: Same.
2022-02-11[nvptx] Handle asm insn in prevent_branch_around_nothingTom de Vries1-0/+8
With GOMP_NVPTX_JIT=-00 and -mptx=3.1, I run into: ... FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-version-1.c \ -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 \ execution test ... The problem is that we're generating a diverging branch around nothing: ... { .reg.u32 %x; mov.u32 %x, %tid.x; setp.ne.u32 %r23, %x, 0; } @%r23 bra $L2; $L2: ... which the driver JIT has problems with at -O0, so consequently we run into the nvptx_uniform_warp_check. Fix this by handling asm ("") and alike in prevent_branch_around_nothing. Tested on x86_64 with nvptx accelerator. gcc/ChangeLog: 2022-02-10 Tom de Vries <tdevries@suse.de> PR target/104456 * config/nvptx/nvptx.cc (prevent_branch_around_nothing): Handle asm insn.
2022-02-11Daily bump.GCC Administrator10-1/+422
2022-02-11testsuite: Fix up g++.dg/warn/Wuninitialized-32.C test for ilp32 [PR104373]Jakub Jelinek1-1/+1
The testcase FAILs whenever size_t is not unsigned long: FAIL: g++.dg/warn/Wuninitialized-32.C -std=c++98 (test for excess errors) Excess errors: .../gcc/testsuite/g++.dg/warn/Wuninitialized-32.C:4:7: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter [-fpermissive] Fixed by using __SIZE_TYPE__ instead of unsigned long. 2022-02-11 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/104373 * g++.dg/warn/Wuninitialized-32.C (operator new[]): Use __SIZE_TYPE__ as type of the first argument instead of unsigned long.
2022-02-10c++: ICE on xtreme-header_a.HJason Merrill1-1/+1
This test regressed after my PR103752 patch with -march=cascadelake. I don't understand why that flag makes a difference, but this patch is correct in any case. gcc/cp/ChangeLog: * module.cc (depset::hash::add_specializations): Use STRIP_TEMPLATE.
2022-02-10libstdc++: Strengthen memory order for atomic<T>::wait/notifyThomas Rodgers1-2/+2
This changes the memory order used in the spin wait code to match that of libc++. libstdc++-v3/ChangeLog: * include/bits/atomic_wait.h (__waiter_base::_S_do_spin, __waiter_base::_S_do_spin_v): Change memory order from relaxed to acquire.
2022-02-10OpenMP/C++: Permit mapping classes with virtual members [PR102204]Tobias Burnus3-9/+51
PR c++/102204 gcc/cp/ChangeLog: * decl2.cc (cp_omp_mappable_type_1): Remove check for virtual members as those are permitted since OpenMP 5.0. libgomp/ChangeLog: * testsuite/libgomp.c++/target-virtual-1.C: New test. gcc/testsuite/ChangeLog: * g++.dg/gomp/unmappable-1.C: Remove previously expected dg-message.
2022-02-10analyzer: handle more casts of string literals [PR98797]David Malcolm4-14/+84
gcc/analyzer/ChangeLog: PR analyzer/98797 * region-model-manager.cc (region_model_manager::maybe_fold_sub_svalue): Generalize getting individual chars of a STRING_CST from element_region to any subregion which is a concrete access of a single byte from its parent region. * region.cc (region::get_relative_concrete_byte_range): New. * region.h (region::get_relative_concrete_byte_range): New decl. gcc/testsuite/ChangeLog: PR analyzer/98797 * gcc.dg/analyzer/casts-1.c: Mark xfails as fixed; add further test coverage for casts of string literals. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-10middle-end: updating the reg use in exit block for -fzero-call-used-regs ↵Qing Zhao2-1/+10
[PR100775] In the pass_zero_call_used_regs, when updating dataflow info after adding the register zeroing sequence in the epilogue of the function, we should call "df_update_exit_block_uses" to update the register use information in the exit block to include all the registers that have been zeroed. 2022-02-10 Qing Zhao <qing.zhao@oracle.com> gcc/ChangeLog: PR middle-end/100775 * function.cc (gen_call_used_regs_seq): Call df_update_exit_block_uses when updating df. gcc/testsuite/ChangeLog: PR middle-end/100775 * gcc.target/arm/pr100775.c: New test.
2022-02-10i386: Fix vec_unpacks_float_lo_v4si operand constraint [PR104469]Uros Bizjak2-1/+13
2022-02-10 Uroš Bizjak <ubizjak@gmail.com> gcc/ChangeLog: PR target/104469 * config/i386/sse.md (vec_unpacks_float_lo_v4si): Change operand 1 constraint to register_operand. gcc/testsuite/ChangeLog: PR target/104469 * gcc.target/i386/pr104469.c: New test.
2022-02-10pr104458.c: Replace long with long long for -mx32H.J. Lu1-1/+1
PR target/104458 * gcc.target/i386/pr104458.c: Replace long with long long.
2022-02-10analyzer: fix testsuite issues seen with mingw [PR102052]David Malcolm8-9/+9
gcc/testsuite/ChangeLog: PR analyzer/102052 * gcc.dg/analyzer/fields.c (size_t): Use __SIZE_TYPE__ rather than hardcoding long unsigned int. * gcc.dg/analyzer/gzio-3.c (size_t): Likewise. * gcc.dg/analyzer/gzio-3a.c (size_t): Likewise. * gcc.dg/analyzer/pr98969.c (test_1): Use __UINTPTR_TYPE__ rather than long int. (test_2): Likewise. * gcc.dg/analyzer/pr99716-2.c (test_mountpoint): Use "rand" rather than "random". * gcc.dg/analyzer/pr99774-1.c (size_t): Use __SIZE_TYPE__ rather than hardcoding long unsigned int. * gcc.dg/analyzer/strndup-1.c: Add MinGW to targets that don't implement strndup. * gcc.dg/analyzer/zlib-5.c (size_t): Use __SIZE_TYPE__ rather than hardcoding long unsigned int. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-10c++: memfn lookup consistency and dependent using-declsPatrick Palka1-9/+17
Rather than not doing any filtering when filter_memfn_lookup encounters a dependent using-decl, handle this case less imprecisely by holding on to the members in the new lookup set that come from a base, i.e. that could plausibly have been introduced by that using-decl, and filtering the rest as usual. This is still imperfect, but it's closer to the correct answer than the previous behavior was. gcc/cp/ChangeLog: * pt.cc (filter_memfn_lookup): Handle dependent USING_DECL better.
2022-02-10gfortran: Respect target's NO_DOT_IN_LABEL in trans-common.ccRoger Sayle1-1/+8
This patch fixes 9 unexpected failures in the gfortran testsuite on nvptx-none. The issue is that gfortran's EQUIVALENCE internally uses symbols such as "equiv.0" even on platforms that define NO_DOT_IN_LABEL. On nvptx-none, this then results in the following error message(s): ptxas application ptx input, fatal: Parsing error near '.0': syntax error ptxas fatal: Ptx assembly aborted due to errors The fix is to tweak trans-common.cc to respect the target's NO_DOT_IN_LABEL (and NO_DOLLAR_IN_LABEL) when generating internal equiv.%d symbols. Only the nvptx, mmix and xtensa backends define NO_DOT_IN_LABEL which explains why no-one has spotted/fixed this issue since the problematic code was last changed back in 2005(!). 2022-02-10 Roger Sayle <roger@nextmovesoftware.com> Tobias Burnus <tobias@codesourcery.com> gcc/fortran/ChangeLog * trans-common.cc (GFC_EQUIV_FMT): New macro respecting the target's NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL preferences. (build_equiv_decl): Use GFC_EQUIV_FMT here.
2022-02-10libstdc++: Add atomic_fetch_xor to <stdatomic.h>Jonathan Wakely2-0/+13
This function (and the explicit memory over version) are present in both C++ <atomic> and C <stdatomic.h>, so should be in C++ <stdatomic.h> too. There is a library issue incoming for this, but the resolution is obvious. libstdc++-v3/ChangeLog: * include/c_compatibility/stdatomic.h (atomic_fetch_xor): Add using-declaration. (atomic_fetch_xor_explicit): Likewise. * testsuite/29_atomics/headers/stdatomic.h/c_compat.cc: Check arithmetic and logical operations for atomic_int.
2022-02-10libstdc++: Fix directory iterator build for newlibJonathan Wakely1-0/+2
When building for newlib HAVE_OPENAT and HAVE_UNLINKAT are (sometimes?) defined, but <fcntl.h> is only included when HAVE_DIRENT_H is defined. Since directory iterators are completely useless without <dirent.h>, just override the HAVE_OPENAT and HAVE_UNLINKAT detection when we don't have <dirent.h>. libstdc++-v3/ChangeLog: * src/filesystem/dir-common.h (_GLIBCXX_HAVE_DIRFD): Undefine when <dirent.h> is not available. (_GLIBCXX_HAVE_UNLINKAT): Likewise.
2022-02-10tree-optimization/104373 - early diagnostic on unreachable codeRichard Biener5-16/+58
The following improves early uninit diagnostics by computing edge reachability using VN and ignoring unreachable blocks when looking for uninitialized uses. To not ICE with -fdump-tree-all the early uninit pass needs a dumpfile since VN tries to dump statistics. 2022-02-04 Richard Biener <rguenther@suse.de> PR tree-optimization/104373 * tree-ssa-sccvn.h (do_rpo_vn): New export exposing the walk kind. * tree-ssa-sccvn.cc (do_rpo_vn): Export, get the default walk kind as argument. (run_rpo_vn): Adjust. (pass_fre::execute): Likewise. * tree-ssa-uninit.cc (warn_uninitialized_vars): Skip blocks not reachable. (execute_late_warn_uninitialized): Mark all edges as executable. (execute_early_warn_uninitialized): Use VN to compute executable edges. (pass_data_early_warn_uninitialized): Enable a dump file, change dump name to warn_uninit. * g++.dg/warn/Wuninitialized-32.C: New testcase. * gcc.dg/uninit-pr20644-O0.c: Remove XFAIL.
2022-02-10middle-end/104467 - fix vector extract simplificationRichard Biener2-1/+12
This fixes a bogus vector type used for a CTOR build as part of vector extract simplification. The code failed to consider a CTOR of vector elements. 2022-02-10 Richard Biener <rguenther@suse.de> PR middle-end/104467 * match.pd (vector extract simplification): Multiply the number of CTOR elements with the number of element elements. * gcc.dg/torture/pr104467.c: New testcase.
2022-02-10tree-optimization/104466 - fix cut&paste error perventing alias disambiguationRichard Biener2-4/+120
The following fixes a cut&paste error in disambiguating using restrict info. Instead of using the for this purpose computed rbase1/rbase2 which preserve MEM_REF bases even when they are based on a decl the code performs the check on the bases that drop info for those ... 2022-02-10 Richard Biener <rguenther@suse.de> PR tree-optimization/104466 * tree-ssa-alias.cc (refs_may_alias_p_2): Use rbase1/rbase2 for the MR_DEPENDENCE checks as intended. * gfortran.dg/pr104466.f90: New testcase.
2022-02-10[nvptx] Handle sm_7x shared atomic store more optimalTom de Vries2-2/+46
For sm_7x atomic stores we fall back on expand_atomic_store, but this results in using membar.sys for shared stores. Fix this by adding an nvptx_atomic_store insn that adds a membar.cta for a shared store. Tested on x86_64 with nvptx accelerator. gcc/ChangeLog: 2022-02-02 Tom de Vries <tdevries@suse.de> * config/nvptx/nvptx.md (define_insn "nvptx_atomic_store<mode>"): New define_insn. (define_expand "atomic_store<mode>"): Use nvptx_atomic_store<mode> for TARGET_SM70. (define_c_enum "unspecv"): Add UNSPECV_ST. gcc/testsuite/ChangeLog: 2022-02-02 Tom de Vries <tdevries@suse.de> * gcc.target/nvptx/atomic-store-2.c: New test.
2022-02-10[nvptx] Handle pre-sm_7x shared atomic store using atomic exchangeTom de Vries6-1/+109
The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory locations do not guarantee atomicity with respect to normal store instructions to the same address. This can be fixed by: - inserting barriers between normal stores and atomic operations to a common address - using atom.exch to store to locations accessed by other atomic operations. It's not clearly spelled out which barriers are needed, and a barrier seem more expensive than atomic exchange. Implement the pre-sm_7x shared atomic store using atomic exchange. That includes stores using generic addressing, since those may also point to shared memory. Tested on x86-64 with nvptx accelerator. gcc/ChangeLog: 2022-02-02 Tom de Vries <tdevries@suse.de> * config/nvptx/nvptx-protos.h (nvptx_mem_maybe_shared_p): Declare. * config/nvptx/nvptx.cc (nvptx_mem_data_area): New static function. (nvptx_mem_maybe_shared_p): New function. * config/nvptx/nvptx.md (define_expand "atomic_store<mode>"): New define_expand. gcc/testsuite/ChangeLog: 2022-02-02 Tom de Vries <tdevries@suse.de> * gcc.target/nvptx/atomic-store-1.c: New test. * gcc.target/nvptx/atomic-store-3.c: New test. * gcc.target/nvptx/stack-atomics-run.c: Update.
2022-02-10[nvptx] Workaround sub.u16 driver JIT bugTom de Vries1-1/+8
There's a nvidia driver JIT bug that mishandles this code (minimized from builtin-arith-overflow-15.c): ... int main (void) { signed char r; unsigned char y = (unsigned char) 0x80; if (__builtin_sub_overflow ((unsigned char)0, (unsigned char)y, &r)) __builtin_abort (); return 0; } ... which at ptx level minimizes to: ... mov.u16 r22, 0x0080; st.local.u16 [frame_var],r22; ld.local.u16 r32,[frame_var]; sub.u16 r33,0x0000,r32; cvt.u32.u16 r35,r33; ... where we expect r35 == 0x0000ff80 but get instead 0xffffff80, and where using nvptx-none-run -O0 fixes the problem. [ See also https://github.com/vries/nvidia-bugs/tree/master/builtin-arith-overflow-15 . ] Try to workaround the bug by using sub.s16 instead of sub.u16. Tested on nvptx. gcc/ChangeLog: 2022-02-07 Tom de Vries <tdevries@suse.de> PR target/97005 * config/nvptx/nvptx.md (define_insn "sub<mode>3"): Workaround driver JIT bug by using sub.s16 instead of sub.u16.
2022-02-10Fortran/OpenMP: Avoid ICE for invalid char array in omp atomic [PR104329]Tobias Burnus2-3/+36
PR fortran/104329 gcc/fortran/ChangeLog: * openmp.cc (resolve_omp_atomic): Defer extra-code assert after other diagnostics. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/atomic-28.f90: New test.
2022-02-10nvptx: Tweak constraints on copysign instructionsRoger Sayle1-2/+2
Many thanks to Thomas Schwinge for confirming my hypothesis that the register usage regression, PR target/104345, is solely due to libgcc's _muldc3 function. In addition to the isinf functionality in the previously proposed nvptx patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588453.html which significantly reduces the number of instructions in _muldc3, the patch below further reduces both the number of instructions and the number of explicitly declared registers, by permitting floating point constant immediate operands in nvptx's copysign instruction. Fingers-crossed, the combination with all of the previous proposed nvptx patches improves things. Ultimately, increasing register usage from 50 to 51 registers, reducing the number of concurrent threads by ~2%, can easily be countered if we're now executing significantly fewer instructions in each kernel, for a net performance win. This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu with a "make" and "make -k check" with no new failures. gcc/ChangeLog: * config/nvptx/nvptx.md (copysign<mode>3): Allow immediate floating point constants as operands 1 and/or 2.
2022-02-10PR target/104345: Use nvptx "set" instruction for cond ? -1 : 0Roger Sayle2-4/+71
This patch addresses the "increased register pressure" regression on nvptx-none caused by my change to transition the backend to a STORE_FLAG_VALUE = 1 target. This improved code generation for the more common case of producing 0/1 Boolean values, but unfortunately made things marginally worse when a 0/-1 mask value is desired. Unfortunately, nvptx kernels are extremely sensitive to changes in register usage, which was observable in the reported PR. This patch provides optimizations for -(cond ? 1 : 0), effectively simplify this into cond ? -1 : 0, where these ternary operators are provided by nvptx's selp instruction, and for the specific case of SImode, using (restoring) nvptx's "set" instruction (which avoids the need for a predicate register). This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu with a "make" and "make -k check" with no new failures. Unfortunately, the exact register usage of a nvptx kernel depends upon the version of the Cuda drivers being used (and the hardware), but I believe this change should resolve the PR (for Thomas) by improving code generation for the cases that regressed. gcc/ChangeLog: PR target/104345 * config/nvptx/nvptx.md (sel_true<mode>): Fix indentation. (sel_false<mode>): Likewise. (define_code_iterator eqne): New code iterator for EQ and NE. (*selp<mode>_neg_<code>): New define_insn_and_split to optimize the negation of a selp instruction. (*selp<mode>_not_<code>): New define_insn_and_split to optimize the bitwise not of a selp instruction. (*setcc_int<mode>): Use set instruction for neg:SI of a selp. gcc/testsuite/ChangeLog: PR target/104345 * gcc.target/nvptx/neg-selp.c: New test case.
2022-02-10nvptx: Fix and use BI mode logic instructions (e.g. and.pred)Roger Sayle5-21/+67
This patch adds support for nvptx's BImode and.pred, or.pred and xor.pred instructions. Technically, nvptx.md previously defined andbi3, iorbi3 and xorbi3 instructions, but the assembly language mnemonic output for these was incorrect (e.g. and.b1) and would be rejected by the ptxas assembler. The most significant part of this patch is the new define_split which teaches the compiler to actually use these instructions when appropriate (exposing the latent bug above). After https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587999.html, the function: int foo(int x, int y) { return (x==21) && (y==69); } when compiled with -O2 produces: mov.u32 %r26, %ar0; mov.u32 %r27, %ar1; setp.eq.u32 %r31, %r26, 21; setp.eq.u32 %r34, %r27, 69; selp.u32 %r37, 1, 0, %r31; selp.u32 %r38, 1, 0, %r34; and.b32 %value, %r37, %r38; with this patch we now save an extra instruction and generate: mov.u32 %r26, %ar0; mov.u32 %r27, %ar1; setp.eq.u32 %r31, %r26, 21; setp.eq.u32 %r34, %r27, 69; and.pred %r39, %r34, %r31; selp.u32 %value, 1, 0, %r39; This patch has been tested (on top of the patch mentioned above) on nvptx-none hosted on x86_64-pc-linux-gnu (including newlib) with a make and make -k check with no new failures. gcc/ChangeLog: * config/nvptx/nvptx.md (any_logic): Move code iterator earlier in machine description. (logic): Move code attribute earlier in machine description. (ilogic): New code attribute, like logic but "ior" for IOR. (and<mode>3, ior<mode>3, xor<mode>3): Delete. Replace with... (<ilogic><mode>3): New define_insn for HSDIM logic operations. (<ilogic>bi3): New define_insn for BI mode logic operations. (define_split): Lower logic operations from integer modes to BI mode predicate operations. gcc/testsuite/ChangeLog: * gcc.target/nvptx/bool-1.c: Update. * gcc.target/nvptx/bool-2.c: New test case for and.pred. * gcc.target/nvptx/bool-3.c: New test case for or.pred. * gcc.target/nvptx/bool-4.c: New test case for xor.pred.
2022-02-10nvptx: Add support for 64-bit mul.hi (and other) instructionsRoger Sayle6-4/+216
Now that the middle-end MULT_HIGHPART_EXPR pieces are in place, this patch adds support for nvptx's mul.hi.s64 and mul.hi.u64 instructions, as previously reviewed (provisionally pre-approved) back in August 2020: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551373.html Since then a few things have changed, so this patch uses the new SMUL_HIGHPART and UMUL_HIGHPART RTX expressions, but the test cases remain the same. Like the x86_64 backend, this patch retains the "trunc" forms of these instructions (while the RTL optimizers/combine may still generate them). Given that we're rapidly approaching stage 4, I also took the liberty of including support in nvptx.md for a few other instructions. With the new 64-bit highpart multiplication instructions added above, we can now provide a define_expand for efficient 64-bit (to 128-bit) widening multiplications. This patch also adds support for nvptx's testp.infinite instruction (for implementing __builtin_isinf) and the not.pred instruction. As an example of the code generation improvements, the function int foo(double x) { return __builtin_isinf(x); } previously generated with -O2: mov.f64 %r26, %ar0; abs.f64 %r28, %r26; setp.leu.f64 %r31, %r28, 0d7fefffffffffffff; selp.u32 %r30, 1, 0, %r31; mov.u32 %r29, %r30; cvt.u16.u8 %r35, %r29; mov.u16 %r33, %r35; xor.b16 %r32, %r33, 1; cvt.u32.u16 %r34, %r32; cvt.u32.u8 %value, %r34; and with this patch now generates: mov.f64 %r23, %ar0; testp.infinite.f64 %r24, %r23; selp.u32 %value, 1, 0, %r24; This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu (including newlib) with a make and make -k check with no new failures. gcc/ChangeLog: * config/nvptx/nvptx.md (UNSPEC_ISINF): New UNSPEC. (one_cmplbi2): New define_insn for not.pred. (mulditi3): New define_expand for signed widening multiply. (umulditi3): New define_expand for unsigned widening multiply. (smul<mode>3_highpart): New define_insn for signed highpart mult. (umul<mode>3_highpart): New define_insn for unsigned highpart mult. (*smulhi3_highpart_2): Renamed from smulhi3_highpart. (*smulsi3_highpart_2): Renamed from smulsi3_highpart. (*umulhi3_highpart_2): Renamed from umulhi3_highpart. (*umulsi3_highpart_2): Renamed from umulsi3_highpart. (*setcc<mode>_from_not_bi): New define_insn. (*setcc_isinf<mode>): New define_insn for testp.infinite. (isinf<mode>2): New define_expand. gcc/testsuite/ChangeLog: * gcc.target/nvptx/mul-hi64.c: New test case. * gcc.target/nvptx/umul-hi64.c: New test case. * gcc.target/nvptx/mul-wide64.c: New test case. * gcc.target/nvptx/umul-wide64.c: New test case. * gcc.target/nvptx/isinf.c: New test case.
2022-02-10nvptx: Expand QI mode operations using SI mode instructionsRoger Sayle2-7/+123
One of the unusual target features of the Nvidia PTX ISA is that it doesn't provide QI mode (byte sized) operations or registers. Somewhat conventionally, 8-bit quantities are read from/written to memory using special instructions, but stored internally using SImode (32-bit) registers. GCC's middle-end accomodates targets without QImode optabs, by widening operations until suitable support is found, and with the current nvptx backend this means 16-bit HImode operations. The inconvenience is that nvptx is also a TARGET_TRULY_NOOP_TRUNCATION=false target, meaning that additional instructions are required to convert between the SImode registers used to hold QImode values, and the HImode registers used to operate on them (and back again). This results in a large amount of shuffling and type conversion in code dealing with bytes, i.e. using char or Boolean types. This patch improves the situation by providing expanders in the nvptx machine description to perform QImode operations natively in SImode instead of HImode. An alternate implementation might be to provide some form of target hook to specify which fallback modes to use during RTL expansion, but I think this requirement is unusual, and a solution entirely in the nvptx backend doesn't disturb/affect other targets. The improvements can be quite dramatic, as shown in the example below: int foo(int x, int y) { return (x==21) && (y==69); } previously with -O2 required 15 instructions: mov.u32 %r26, %ar0; mov.u32 %r27, %ar1; setp.eq.u32 %r31, %r26, 21; selp.u32 %r30, 1, 0, %r31; mov.u32 %r29, %r30; setp.eq.u32 %r34, %r27, 69; selp.u32 %r33, 1, 0, %r34; mov.u32 %r32, %r33; cvt.u16.u8 %r39, %r29; mov.u16 %r36, %r39; cvt.u16.u8 %r39, %r32; mov.u16 %r37, %r39; and.b16 %r35, %r36, %r37; cvt.u32.u16 %r38, %r35; cvt.u32.u8 %value, %r38; with this patch, now requires only 7 instructions: mov.u32 %r26, %ar0; mov.u32 %r27, %ar1; setp.eq.u32 %r31, %r26, 21; setp.eq.u32 %r34, %r27, 69; selp.u32 %r37, 1, 0, %r31; selp.u32 %r38, 1, 0, %r34; and.b32 %value, %r37, %r38; This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu (including newlib) with a make and make -k check with no new failures. gcc/ChangeLog: * config/nvptx/nvptx.md (cmp<mode>): Renamed from *cmp<mode>. (setcc<mode>_from_bi): Additionally support QImode. (extendbi<mode>2): Additionally support QImode. (zero_extendbi<mode>2): Additionally support QImode. (any_sbinary, any_ubinary, any_sunary, any_uunary): New code iterators for signed and unsigned, binary and unary operations. (<sbinary>qi3, <ubinary>qi3, <sunary>qi2, <uunary>qi2): New expanders to perform QImode operations using SImode instructions. (cstoreqi4): New define_expand. (*ext_truncsi2_qi): New define_insn. (*zext_truncsi2_qi): New define_insn. gcc/testsuite/ChangeLog: * gcc.target/nvptx/bool-1.c: New test case.
2022-02-10nvptx: Improved support for HFMode including neghf2 and abshf2Roger Sayle5-0/+117
This patch adds more support for _Float16 (HFmode) to the nvptx backend. Currently negation, absolute value and floating point comparisons are implemented by promoting to float (SFmode). This patch adds suitable define_insns to nvptx.md, most conditional on TARGET_SM53 (-misa=sm_53). This patch also adds support for HFmode fused multiply-add. One subtlety is that neghf2 and abshf2 are implemented by (HImode) bit manipulation operations to update the sign bit. The NVidia PTX ISA documentation for neg.f16 and abs.f16 contains the caution "Future implementations may comply with the IEEE 754 standard by preserving the (NaN) payload and modifying only the sign bit". Given the availability of suitable replacements, I thought it best to provide IEEE 754 compliant implementations. If anyone observes a performance penalty from this choice I'm happy to provide a -ffast-math variant (or revisit this decision). This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu (including newlib) with a make and make -k check with no new failures. gcc/ChangeLog: * config/nvptx/nvptx.md (*cmpf): New define_insn. (cstorehf4): New define_expand. (fmahf4): New define_insn. (neghf2): New define_insn. (abshf2): New define_insn. gcc/testsuite/ChangeLog: * gcc.target/nvptx/float16-3.c: New test case for neghf2. * gcc.target/nvptx/float16-4.c: New test case for abshf2. * gcc.target/nvptx/float16-5.c: New test case for fmahf4. * gcc.target/nvptx/float16-6.c: New test case.
2022-02-10doc: Tweak the www.bitwizard.nl referenceGerald Pfeifer1-1/+1
gcc: * doc/install.texi (Specific): Change the www.bitwizard.nl reference to use https.
2022-02-09C, C++, Fortran, OpenMP: Add 'has_device_addr' clause to 'target' construct.Marcel Vollweiler38-82/+961
This patch adds the 'has_device_addr' clause to the OpenMP 'target' construct which was introduced in OpenMP 5.1 (OpenMP API 5.1 specification pp. 197ff): has_device_addr(list) "The has_device_addr clause indicates that its list items already have device addresses and therefore they may be directly accessed from a target device. If the device address of a list item is not for the device on which the target region executes, accessing the list item inside the region results in unspecified behavior. The list items may include array sections." (p. 200) "A list item may not be specified in both an is_device_ptr clause and a has_device_addr clause on the directive." (p. 202) "A list item that appears in an is_device_ptr or a has_device_addr clause must not be specified in any data-sharing attribute clause on the same target construct." (p. 203) gcc/c-family/ChangeLog: * c-omp.cc (c_omp_split_clauses): Added OMP_CLAUSE_HAS_DEVICE_ADDR case. * c-pragma.h (enum pragma_kind): Added 5.1 in comment. (enum pragma_omp_clause): Added PRAGMA_OMP_CLAUSE_HAS_DEVICE_ADDR. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_clause_name): Parse 'has_device_addr' clause. (c_parser_omp_variable_list): Handle array sections. (c_parser_omp_clause_has_device_addr): Added. (c_parser_omp_all_clauses): Added PRAGMA_OMP_CLAUSE_HAS_DEVICE_ADDR case. (c_parser_omp_target_exit_data): Added HAS_DEVICE_ADDR to OMP_CLAUSE_MASK. * c-typeck.cc (handle_omp_array_sections): Handle clause restrictions. (c_finish_omp_clauses): Handle array sections. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_clause_name): Parse 'has_device_addr' clause. (cp_parser_omp_var_list_no_open): Handle array sections. (cp_parser_omp_all_clauses): Added PRAGMA_OMP_CLAUSE_HAS_DEVICE_ADDR case. (cp_parser_omp_target_update): Added HAS_DEVICE_ADDR to OMP_CLAUSE_MASK. * semantics.cc (handle_omp_array_sections): Handle clause restrictions. (finish_omp_clauses): Handle array sections. gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_omp_clauses): Added OMP_LIST_HAS_DEVICE_ADDR case. * gfortran.h: Added OMP_LIST_HAS_DEVICE_ADDR. * openmp.cc (enum omp_mask2): Added OMP_CLAUSE_HAS_DEVICE_ADDR. (gfc_match_omp_clauses): Parse HAS_DEVICE_ADDR clause. (resolve_omp_clauses): Same. * trans-openmp.cc (gfc_trans_omp_variable_list): Added OMP_LIST_HAS_DEVICE_ADDR case. (gfc_trans_omp_clauses): Firstprivatize of array descriptors. gcc/ChangeLog: * gimplify.cc (gimplify_scan_omp_clauses): Added cases for OMP_CLAUSE_HAS_DEVICE_ADDR and handle array sections. (gimplify_adjust_omp_clauses): Added OMP_CLAUSE_HAS_DEVICE_ADDR case. * omp-low.cc (scan_sharing_clauses): Handle OMP_CLAUSE_HAS_DEVICE_ADDR. (lower_omp_target): Same. * tree-core.h (enum omp_clause_code): Same. * tree-nested.cc (convert_nonlocal_omp_clauses): Same. (convert_local_omp_clauses): Same. * tree-pretty-print.cc (dump_omp_clause): Same. * tree.cc: Same. libgomp/ChangeLog: * libgomp.texi: Updated entry for HAS_DEVICE_ADDR. * target.c (copy_firstprivate_data): Copy only if host address is not NULL. * testsuite/libgomp.c++/target-has-device-addr-2.C: New test. * testsuite/libgomp.c++/target-has-device-addr-4.C: New test. * testsuite/libgomp.c++/target-has-device-addr-5.C: New test. * testsuite/libgomp.c++/target-has-device-addr-6.C: New test. * testsuite/libgomp.c-c++-common/target-has-device-addr-1.c: New test. * testsuite/libgomp.c/target-has-device-addr-3.c: New test. * testsuite/libgomp.fortran/target-has-device-addr-1.f90: New test. * testsuite/libgomp.fortran/target-has-device-addr-2.f90: New test. * testsuite/libgomp.fortran/target-has-device-addr-3.f90: New test. * testsuite/libgomp.fortran/target-has-device-addr-4.f90: New test. gcc/testsuite/ChangeLog: * c-c++-common/gomp/clauses-1.c: Added has_device_addr to test cases. * g++.dg/gomp/attrs-1.C: Added has_device_addr to test cases. * g++.dg/gomp/attrs-2.C: Added has_device_addr to test cases. * c-c++-common/gomp/target-has-device-addr-1.c: New test. * c-c++-common/gomp/target-has-device-addr-2.c: New test. * c-c++-common/gomp/target-is-device-ptr-1.c: New test. * c-c++-common/gomp/target-is-device-ptr-2.c: New test. * gfortran.dg/gomp/is_device_ptr-3.f90: New test. * gfortran.dg/gomp/target-has-device-addr-1.f90: New test. * gfortran.dg/gomp/target-has-device-addr-2.f90: New test.
2022-02-09AutoFDO: Don't try to promote indirect calls that result in recursive direct ↵Eugene Rozenfeld2-16/+78
calls AutoFDO tries to promote and inline all indirect calls that were promoted and inlined in the original binary and that are still hot. In the included test case, the promotion results in a direct call that is a recursive call. inline_call and optimize_inline_calls can't handle recursive calls at this stage. Currently, inline_call fails with a segmentation fault. This change leaves the indirect call alone if promotion will result in a recursive call. Tested on x86_64-pc-linux-gnu. gcc/ChangeLog: * auto-profile.cc (afdo_indirect_call): Don't attempt to promote indirect calls that will result in direct recursive calls. gcc/testsuite/ChangeLog: * g++.dg/tree-prof/indir-call-recursive-inlining.C : New test.
2022-02-09[COMMITTED] Fix PR aarch64/104474: ICE with vector float initializers and ↵Andrew Pinski4-1/+28
non-consts. The problem here is that the aarch64 back-end was placing const0_rtx into the constant vector RTL even if the mode was a floating point mode. The fix is instead to use CONST0_RTX and pass the mode to select the correct zero (either const_int or const_double). Committed as obvious after a bootstrap/test on aarch64-linux-gnu with no regressions. PR target/104474 gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_sve_expand_vector_init_handle_trailing_constants): Use CONST0_RTX instead of const0_rtx for the non-constant elements. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/pr104474-1.c: New test. * gcc.target/aarch64/sve/pr104474-2.c: New test. * gcc.target/aarch64/sve/pr104474-3.c: New test.
2022-02-10Daily bump.GCC Administrator11-1/+515
2022-02-09analyzer: more uninit test coverageDavid Malcolm2-0/+204
In addition to other test coverage, this adds the examples from https://cwe.mitre.org/data/definitions/457.html (aka "CWE-457: Use of Uninitialized Variable") For reference, the output from -fanalyzer looks like this (after stripping away the DejaGnu directives): uninit-CWE-457-examples.c: In function 'example_2_bad_code': uninit-CWE-457-examples.c:56:3: warning: use of uninitialized value 'bN' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 56 | repaint(aN, bN); /* { dg-warning "use of uninitialized value 'bN'" } */ | ^~~~~~~~~~~~~~~ 'example_2_bad_code': events 1-4 | | 34 | int aN, bN; | | ^~ | | | | | (1) region created on stack here | 35 | switch (ctl) { | | ~~~~~~ | | | | | (2) following 'default:' branch... |...... | 51 | default: | | ~~~~~~~ | | | | | (3) ...to here |...... | 56 | repaint(aN, bN); | | ~~~~~~~~~~~~~~~ | | | | | (4) use of uninitialized value 'bN' here | uninit-CWE-457-examples.c: In function 'example_3_bad_code': uninit-CWE-457-examples.c:95:3: warning: use of uninitialized value 'test_string' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 95 | printf("%s", test_string); | ^~~~~~~~~~~~~~~~~~~~~~~~~ 'example_3_bad_code': events 1-4 | | 90 | char *test_string; | | ^~~~~~~~~~~ | | | | | (1) region created on stack here | 91 | if (i != err_val) | | ~ | | | | | (2) following 'false' branch (when 'i == err_val')... |...... | 95 | printf("%s", test_string); | | ~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (3) ...to here | | (4) use of uninitialized value 'test_string' here | gcc/testsuite/ChangeLog: * gcc.dg/analyzer/uninit-1.c: Add test coverage for shifts, comparisons, +, -, *, /, and __builtin_strlen. * gcc.dg/analyzer/uninit-CWE-457-examples.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-09compiler: don't warn for print()Ian Lance Taylor2-11/+2
We used to warn for calls to print(), because it doesn't do anything. However, a Go 1.18 test uses that call, and it is valid Go. Change the compiler to just accept it and compile it; this will produce calls to printlock and printunlock, and nothing else. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/384355