aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-03make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizerDavid Seifert23-43/+183
* `-Werror` can cause issues when a more recent version of GCC compiles an older version: - https://bugs.gentoo.org/229059 - https://bugs.gentoo.org/475350 - https://bugs.gentoo.org/667104 libatomic/ChangeLog: * configure.ac: Support --disable-werror. * configure: Regenerate. libbacktrace/ChangeLog: * configure.ac: Support --disable-werror. * configure: Regenerate. libgomp/ChangeLog: * configure.ac: Support --disable-werror. * configure: Regenerate. libitm/ChangeLog: * configure.ac: Support --disable-werror. * configure: Regenerate. libsanitizer/ChangeLog: * configure.ac: Support --disable-werror. * aclocal.m4: Include also ../config/warnings.m4. * libbacktrace/Makefile.am (WARN_FLAGS): Remove. * configure: Regenerate. * Makefile.in: Regenerate. * asan/Makefile.in: Regenerate. * hwasan/Makefile.in: Regenerate. * interception/Makefile.in: Regenerate. * libbacktrace/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.in: Regenerate. Co-Authored-By: Jakub Jelinek <jakub@redhat.com>
2022-02-03debug/104337 - avoid messing with the abstract origin chain in NRVRichard Biener2-13/+15
The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after variable creation since NRV runs _after_ the function was inlined and thus affects the inlined variables copy indirectly. We may adjust the abstract origin of a variable only at the point we create it, not further along the path since otherwise the (new) invariant that the abstract origin is always the ultimate origin cannot be maintained. The intent of what NRV does is OK I guess and it may improve the debug experience. But I also notice we do SET_DECL_VALUE_EXPR (found, result); DECL_HAS_VALUE_EXPR_P (found) = 1; the code is there since the merge from tree-ssa which added tree-nrv.c. Jakub added the DECL_VALUE_EXPR in g:938650d8fddb878f623e315f0b7fd94b217efa96 and Jason added the abstract origin setting conditional in g:7716876bbd3a The follwoing takes the radical approach and remove the attempt to "optimize" the debug info. The gdb testsuites show no regressions. 2022-02-03 Richard Biener <rguenther@suse.de> PR debug/104337 * tree-nrv.cc (pass_nrv::execute): Remove tieing result and found together via DECL_ABSTRACT_ORIGIN. * gcc.dg/debug/pr104337.c: New testcase.
2022-02-03rs6000: Unify error messages for built-in constant restrictionsBill Schmidt51-87/+89
We currently give different error messages for built-in functions that violate range restrictions on their arguments, depending on whether we record them as requiring an n-bit literal or a literal between two values. It's better to be consistent. Change the error message for the n-bit literal to look like the other one. 2022-02-02 Bill Schmidt <wschmidt@linux.ibm.com> gcc/ * config/rs6000/rs6000-call.cc (rs6000_expand_builtin): Revise error message for RES_BITS case. gcc/testsuite/ * gcc.target/powerpc/bfp/scalar-test-data-class-10.c: Adjust error messages. * gcc.target/powerpc/bfp/scalar-test-data-class-2.c: Likewise. * gcc.target/powerpc/bfp/scalar-test-data-class-3.c: Likewise. * gcc.target/powerpc/bfp/scalar-test-data-class-4.c: Likewise. * gcc.target/powerpc/bfp/scalar-test-data-class-5.c: Likewise. * gcc.target/powerpc/bfp/scalar-test-data-class-9.c: Likewise. * gcc.target/powerpc/bfp/vec-test-data-class-4.c: Likewise. * gcc.target/powerpc/bfp/vec-test-data-class-5.c: Likewise. * gcc.target/powerpc/bfp/vec-test-data-class-6.c: Likewise. * gcc.target/powerpc/bfp/vec-test-data-class-7.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-12.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-14.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-17.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-19.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-2.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-22.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-24.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-27.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-29.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-32.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-34.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-37.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-39.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-4.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-42.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-44.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-47.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-49.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-52.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-54.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-57.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-59.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-62.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-64.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-67.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-69.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-7.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-72.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-74.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-77.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-79.c: Likewise. * gcc.target/powerpc/dfp/dtstsfi-9.c: Likewise. * gcc.target/powerpc/pr80315-1.c: Likewise. * gcc.target/powerpc/pr80315-2.c: Likewise. * gcc.target/powerpc/pr80315-3.c: Likewise. * gcc.target/powerpc/pr80315-4.c: Likewise. * gcc.target/powerpc/pr82015.c: Likewise. * gcc.target/powerpc/pr91903.c: Likewise. * gcc.target/powerpc/test_fpscr_rn_builtin_error.c: Likewise. * gcc.target/powerpc/vec-ternarylogic-10.c: Likewise.
2022-02-03ranger: fix small thinko in fur_list constructorAldy Hernandez1-1/+1
The fur_list constructor for two ranges is leaving [1] in an undefined state. The reason we haven't noticed is because after all the shuffling in the last cycle there are no remaining users of it (similarly for fur_list(unsigned, irange *)). Since it's very late in the cycle, I would prefer to fix this, rather than removing unused constructors altogether. Besides, we have uses of them queued up for the next release. gcc/ChangeLog: * gimple-range-fold.cc (fur_list::fur_list): Set m_local[1] correctly.
2022-02-03arm: Fix up help.exp regressionJakub Jelinek1-4/+4
On Thu, Jan 20, 2022 at 11:27:20AM +0000, Richard Earnshaw via Gcc-patches wrote: > gcc/ChangeLog: > > * config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line > option. > (mfix-cortex-a72-aes-1655431): New option alias. > --- a/gcc/config/arm/arm.opt > +++ b/gcc/config/arm/arm.opt > @@ -272,6 +272,16 @@ mfix-cmse-cve-2021-35465 > Target Var(fix_vlldm) Init(2) > Mitigate issues with VLLDM on some M-profile devices (CVE-2021-35465). > > +mfix-cortex-a57-aes-1742098 > +Target Var(fix_aes_erratum_1742098) Init(2) Save > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72. > +Arm erratum #1742098 > + > +mfix-cortex-a72-aes-1655431 > +Target Alias(mfix-cortex-a57-aes-1742098) > +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72. > +Arm erratum #1655431 > + > munaligned-access > Target Var(unaligned_access) Init(2) Save > Enable unaligned word and halfword accesses to packed data. This breaks: Running /usr/src/gcc/gcc/testsuite/gcc.misc-tests/help.exp ... FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from output: " -mfix-cortex-a57-aes-1742098 Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72. Arm erratum #1742098" help.exp with help of lib/options.exp tests whether all non-empty descriptions of options are terminated with . or :. 2022-02-03 Jakub Jelinek <jakub@redhat.com> * config/arm/arm.opt (mfix-cortex-a57-aes-1742098, mfix-cortex-a72-aes-1655431): Ensure description ends with full stop.
2022-02-03Assert that backedges are available in path solver.Aldy Hernandez5-1/+42
gcc/ChangeLog: * cfganal.cc (verify_marked_backedges): New. * cfganal.h (verify_marked_backedges): New. * gimple-range-path.cc (path_range_query::path_range_query): Verify freshness of back edges. * tree-ssa-loop-ch.cc (ch_base::copy_headers): Call mark_dfs_back_edges. * tree-ssa-threadbackward.cc (back_threader::back_threader): Move path_range_query construction after backedges have been updated.
2022-02-03Skip gnat.dg/div_zero.adb on PowerPCEric Botcazou1-0/+1
The hardware instruction does not trap on divide by zero there. gcc/testsuite PR tree-optimization/104356 * gnat.dg/div_zero.adb: Add dg-skip-if directive for PowerPC.
2022-02-03aarch64: Remove struct_vect_25.c XFAILsRichard Sandiford1-12/+6
At some point we started generating the intended code for aarch64/sve/struct_vect_25.c. This patch removes the xfails and the scan-assembler-times that replaced the xfailed forms. gcc/testsuite/ * gcc.target/aarch64/sve/struct_vect_25.c: Remove XFAILs.
2022-02-03aarch64: Adjust tests after fix for PR102659Richard Sandiford12-25/+25
After the fix for PR102659, the vectoriser can no longer group conditional accesses of the form: for (int i = 0; i < n; ++i) if (...) ...a[i * 2] + a[i * 2 + 1]...; on LP64 targets. It has to treat them as two independent gathers instead. This was causing failures in the sve mask_struct*.c tests. The tests weren't really testing that int iterators could be used, so this patch switches to pointer-sized iterators instead. gcc/testsuite/ * gcc.target/aarch64/sve/mask_struct_load_1.c: Use intptr_t iterators instead of int iterators. * gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise. * gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise. * gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise.
2022-02-03aarch64: Add missing movmisalign patternsRichard Sandiford2-6/+5
The Advanced SIMD movmisalign patterns didn't handle 16-bit FP modes, which meant that the vector loop for: void test (_Float16 *data) { _Pragma ("omp simd") for (int i = 0; i < 8; ++i) data[i] = 1.0; } would be versioned for alignment. This was causing some new failures in aarch64/sve/single_5.c: FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tb FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tcmp FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-times \\tstr\\tq[0-9]+, 10 but I didn't look into what changed from earlier releases. Adding the missing modes removes some existing xfails. gcc/ * config/aarch64/aarch64-simd.md (movmisalign<mode>): Extend from VALL to VALL_F16. gcc/testsuite/ * gcc.target/aarch64/sve/single_5.c: Remove some XFAILs.
2022-02-03aarch64: Remove VALL_F16MOV iteratorRichard Sandiford2-7/+2
The VALL_F16MOV iterator now has the same modes as VALL_F16, in the same order. This patch removes the former in favour of the latter. This doesn't fix a bug as such, but it's ultra-safe (no change in object code) and it saves a follow-up patch from having to make a false choice between the iterators. gcc/ * config/aarch64/iterators.md (VALL_F16MOV): Delete. * config/aarch64/aarch64-simd.md (mov<mode>): Use VALL_F16 instead of VALL_F16MOV.
2022-02-03testsuite: Remove TSVC XFAILs for SVERichard Sandiford25-25/+25
Many of the XFAILed TSVC tests pass for SVE. This patch updates the markup accordingly. gcc/testsuite/ * gcc.dg/vect/tsvc/vect-tsvc-s1115.c: Don't XFAIL for SVE. * gcc.dg/vect/tsvc/vect-tsvc-s114.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s1161.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s1232.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s124.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s1279.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s161.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s253.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s257.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s271.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s2711.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s2712.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s272.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s273.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s274.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s276.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s278.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s279.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s3111.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s4113.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s441.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s443.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-s491.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-vas.c: Likewise. * gcc.dg/vect/tsvc/vect-tsvc-vif.c: Likewise.
2022-02-03testsuite: Update guality xfails for aarch64*-*-*Richard Sandiford3-7/+7
Following on from GCC 11 patch g:f31ddad8ac8, this one gives clean guality.exp test results for aarch64-linux-gnu with modern gdb (this time gdb 11.2). The justification is the same as previously: ------ For people using older gdbs, it will trade one set of noisy results for another set. I still think it's better to have the xfails based on one “clean” and “modern” run rather than have FAILs and XPASSes for all runs. It's hard to tell which of these results are aarch64-specific and which aren't. If other target maintainers want to do something similar, and are prepared to assume the same gdb version, then it should become clearer over time which ones are target-specific and which aren't. There are no new skips here, so changes in test results will still show up as XPASSes. I've not analysed the failures or filed PRs for them. In some ways the guality directory itself seems like the best place to start looking for xfails, if someone's interested in working in this area. ------ gcc/testsuite/ * gcc.dg/guality/ipa-sra-1.c: Update aarch64*-*-* xfails. * gcc.dg/guality/pr54519-1.c: Likewise. * gcc.dg/guality/pr54519-3.c: Likewise.
2022-02-03Fix wording for: attribute ‘-xyz’ argument ‘target’ is unknownMartin Liska2-4/+4
gcc/ChangeLog: * config/i386/i386-options.cc (ix86_valid_target_attribute_inner_p): Change subject and object in the error message. * config/s390/s390.cc (s390_valid_target_attribute_inner_p): Likewise.
2022-02-03s390x: Fix one more -Wformat-diag.Martin Liska1-3/+3
gcc/ChangeLog: * config/s390/s390.cc (s390_valid_target_attribute_inner_p): Use the error message for i386 target.
2022-02-03ranger: Fix up wi_fold_in_parts for small precision types [PR104334]Jakub Jelinek2-12/+50
The wide-int.h templates expect that when an int/long etc. operand is used it will be sign-extended based on the types precision. wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3 bit type 4 should be written as -4. The following patch promotes the subtraction operands to widest_int and uses that as the type for ?h_range variables and compares them as such. We don't need the overflow handling because there is never an overflow. 2022-02-02 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/104334 * range-op.cc (range_operator::wi_fold_in_parts): Change lh_range and rh_range type to widest_int and subtract in widest_int. Remove ov_rh, ov_lh and sign vars, always perform comparisons as signed and use >, < and == operators for it. * g++.dg/opt/pr104334.C: New test.
2022-02-03openmp, fortran: Improve !$omp atomic checks [PR104328]Jakub Jelinek2-3/+46
The testcase shows some cases that weren't verified and we ICE on invalid because of that. One problem is that unlike before, we weren't checking if some expression is EXPR_VARIABLE with non-NULL symtree in the case where there was a conversion around it. The other two issues is that we check that in an IF ->block is non-NULL and then immediately dereference ->block->next->op, but on invalid code with no statements in the then clause ->block->next might be NULL. 2022-02-02 Jakub Jelinek <jakub@redhat.com> PR fortran/104328 * openmp.cc (is_scalar_intrinsic_expr): If must_be_var && conv_ok and expr is conversion, verify it is a conversion from EXPR_VARIABLE with non-NULL symtree. Check ->block->next before dereferencing it. * gfortran.dg/gomp/atomic-27.f90: New test.
2022-02-02c++: dependent array bounds completion [PR104302]Jason Merrill3-2/+34
The patch for PR55227 changed the minimal init-list handling in cp_complete_array_type to a call to reshape_init, which broke on the dependent initializer. It occurred to me that trying to deduce the array size from a dependent init-list is wrong in general, so let's just not. I also limited the reshape_init call to the case of a char array, as before the patch for 55227; that's the only case where we want to strip a level of braces from an array. PR c++/104302 gcc/cp/ChangeLog: * decl.cc (maybe_deduce_size_from_array_init): Give up on type-dependent init. (cp_complete_array_type): Only call reshape_init for character array. gcc/testsuite/ChangeLog: * g++.dg/template/array35.C: New test. * g++.dg/template/array36.C: New test.
2022-02-02Correct typos in -Wuse-after-free description.Martin Sebor1-2/+2
gcc/ChangeLog: * common.opt (-Wuse-after-free): Correct typos.
2022-02-03Daily bump.GCC Administrator6-1/+231
2022-02-02docs: mention analyzer interaction with -ftrivial-auto-var-init [PR104270]David Malcolm1-1/+2
gcc/ChangeLog: PR analyzer/104270 * doc/invoke.texi (-ftrivial-auto-var-init=): Add reference to -Wanalyzer-use-of-uninitialized-value to paragraph documenting that -ftrivial-auto-var-init= doesn't suppress warnings. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-02rs6000/testsuite: Return 0 for powerpc_altivec_ok on other targetsSegher Boessenkool1-15/+15
2022-02-02 Segher Boessenkool <segher@kernel.crashing.org> gcc/testsuite/ * lib/target-supports.exp (check_effective_target_powerpc_altivec_ok): Return 0 if the target is not Power. Restructure and add some comments.
2022-02-02libstdc++: Fix -Wunused-variable warning for -fno-exceptions buildJonathan Wakely2-2/+2
If _GLIBCXX_THROW_OR_ABORT expands to just __builtin_abort() then the bool variable used in the filesystem_error constructor is unused. Mark it as maybe_unused to there's no warning for -fno-exceptions builds. libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc (fs::recursive_directory_iterator::pop): Add [[maybe_unused]] attribute. * src/filesystem/dir.cc (fs::recursive_directory_iterator::pop): Likewise.
2022-02-02libstdc++: Fix invalid instantiations in testsJonathan Wakely2-4/+12
These tests instantiate std::multiset and std::set with a type that has no operator< so they should use a custom comparison function. libstdc++-v3/ChangeLog: * testsuite/23_containers/multiset/operators/cmp_c++20.cc: Use custom comparison function for multiset. * testsuite/23_containers/set/operators/cmp_c++20.cc: Use custom comparison function for set.
2022-02-02libstdc++: Fix link failure in _OutputIteratorConceptJonathan Wakely1-1/+3
The C++98-style concept check for output iterators causes a link failure on mingw-w64, because the __val() member function isn't defined. Change it to use a function pointer instead. That pointer is never set to anything meaningful, but it doesn't matter as the __constraints() function only has to be instantiated, it's never called. We could refactor all of these to use unevaluated contexts (e.g. sizeof of __decltype) so that we only check the expressions are well-formed, without any codegen at all. Any improvements to these are very low priority though. libstdc++-v3/ChangeLog: * include/bits/boost_concept_check.h (_OutputIteratorConcept): Change member function to data member of function pointer type.
2022-02-02lto: fix error handling for -Wl,-plugin-opt=debugMartin Liska2-12/+9
When one uses something like: -Wl,-plugin-opt=debug, we end up with lto1 WPA invocation that has 'debug' on command line. We interpret that as input filename. The patch moves resolution checking later so that we end up with a reasonable error message: lto1: fatal error: open debug failed: No such file or directory compilation terminated. PR lto/104333 gcc/lto/ChangeLog: * lto-common.cc (read_cgraph_and_symbols): Move resolution checking for number of files later and report a reasonable error message. * lto-object.cc (lto_obj_file_open): Make error fatal.
2022-02-02Remove dead macro: TEXT_SECTION_NAMEMartin Liska1-5/+0
gcc/ChangeLog: * dwarf2out.cc (TEXT_SECTION_NAME): Remove unused macro.
2022-02-02analyzer: fix missing check for uninit of return valuesDavid Malcolm10-48/+43
When moving the -fanalyzer tests for -ftrivial-auto-var-init to the "torture" subdirectory of gcc.dg/analyzer I noticed that -fanalyzer wasn't always properly checking for initialization of return values. The issue was that some "return" handling was using region_model::copy_region to copy to the RESULT_DECL, and copy_region wasn't checking for poisoned svalues. This patch eliminates region_model::copy_region in favor of simply doing a get_ravlue/set_value pair, fixing the issue. gcc/analyzer/ChangeLog: * region-model.cc (region_model::on_return): Replace usage of copy_region with get_rvalue/set_value pair. (region_model::pop_frame): Likewise. (selftest::test_compound_assignment): Likewise. * region-model.h (region_model::copy_region): Delete decl. * region.cc (region_model::copy_region): Delete. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/torture/ubsan-1.c: Add missing return stmts. * gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: Move to... * gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-pattern.c: ...here. * gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c: Move to... * gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-uninitialized.c: ...here. * gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: Move to... * gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-zero.c: ...here. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-02analyzer: consolidate duplicate code in region::calc_offsetDavid Malcolm1-43/+5
gcc/analyzer/ChangeLog: * region.cc (region::calc_offset): Consolidate effectively identical cases. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-02analyzer: implement bit_range_regionDavid Malcolm7-0/+243
GCC 12 has gained -Wanalyzer-use-of-uninitialized-value, and I'm seeing various false positives from it due to region_model::get_lvalue not properly handling BIT_FIELD_REF, and falling back to using an UNKNOWN_REGION for them. This patch fixes these false positives by implementing a new bit_range_region region subclass for handling BIT_FIELD_REF. gcc/analyzer/ChangeLog: * analyzer.h (class bit_range_region): New forward decl. * region-model-manager.cc (region_model_manager::get_bit_range): New. (region_model_manager::log_stats): Handle m_bit_range_regions. * region-model.cc (region_model::get_lvalue_1): Handle BIT_FIELD_REF. * region-model.h (region_model_manager::get_bit_range): New decl. (region_model_manager::m_bit_range_regions): New field. * region.cc (region::get_base_region): Handle RK_BIT_RANGE. (region::base_region_p): Likewise. (region::calc_offset): Likewise. (bit_range_region::dump_to_pp): New. (bit_range_region::get_byte_size): New. (bit_range_region::get_bit_size): New. (bit_range_region::get_byte_size_sval): New. (bit_range_region::get_relative_concrete_offset): New. * region.h (enum region_kind): Add RK_BIT_RANGE. (region::dyn_cast_bit_range_region): New vfunc. (class bit_range_region): New. (is_a_helper <const bit_range_region *>::test): New. (default_hash_traits<bit_range_region::key_t>): New. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/torture/uninit-bit-field-ref.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-02analyzer: stop -ftrivial-auto-var-init from suppressing uninit warnings ↵David Malcolm4-0/+31
[PR104270] GCC 12 has gained two features for dealing with uninitialized variables: (a) a new -Wanalyzer-use-of-uninitialized-value warning within -fanalyzer for interprocedural path-sensitive detection of ununit uses, and (b) a new -ftrivial-auto-var-init option for mitigating some uses of uninit variables It turns out that using (b) was thwarting (a), as it led to -fanalyzer seeing calls to IFN_DEFERRED_INIT, which -fanalyzer wasn't special-casing, thus treating it as initializing the variables in question, and thus silencing -Wanalyzer-use-of-uninitialized-value on them. invoke.texi says: "GCC still considers an automatic variable that doesn't have an explicit initializer as uninitialized, @option{-Wuninitialized} will still report warning messages on such automatic variables." and thus -Wanalyzer-use-of-uninitialized-value ought to as well. This patch adds special-case handling to -fanalyzer for IFN_DEFERRED_INIT, so that -fanalyzer will warn on uninit uses of variables that are mitigated by -ftrivial-auto-var-init. gcc/analyzer/ChangeLog: PR analyzer/104270 * region-model.cc (region_model::on_call_pre): Handle IFN_DEFERRED_INIT. gcc/testsuite/ChangeLog: PR analyzer/104270 * gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: New test. * gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c: New test. * gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2022-02-02gcc: define _REENTRANT for OpenRISC when -pthread is passedBernd Kuhls1-0/+2
The detection of pthread support fails on OpenRISC unless _REENTRANT is defined. Added the CPP_SPEC definition to correct this. gcc/ChangeLog: PR target/94372 * config/or1k/linux.h (CPP_SPEC): Define. Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
2022-02-02AArch32: use canonical ordering for complex mul, fma and fmsTamar Christina1-7/+7
After the first patch in the series this updates the optabs to expect the canonical sequence. gcc/ChangeLog: PR tree-optimization/102819 PR tree-optimization/103169 * config/arm/vec-common.md (cml<fcmac1><conj_op><mode>4): Use canonical order.
2022-02-02AArch64: use canonical ordering for complex mul, fma and fmsTamar Christina2-10/+10
After the first patch in the series this updates the optabs to expect the canonical sequence. gcc/ChangeLog: PR tree-optimization/102819 PR tree-optimization/103169 * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use canonical order. * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): Likewise.
2022-02-02vect: Simplify and extend the complex numbers validation routines.Tamar Christina16-209/+458
This patch boosts the analysis for complex mul,fma and fms in order to ensure that it doesn't create an incorrect output. Essentially it adds an extra verification to check that the two nodes it's going to combine do the same operations on compatible values. The reason it needs to do this is that if one computation differs from the other then with the current implementation we have no way to deal with it since we have to remove the permute. When we can keep the permute around we can probably handle these by unrolling. While implementing this since I have to do the traversal anyway I took advantage of it by simplifying the code a bit. Previously we would determine whether something is a conjugate and then try to figure out which conjugate it is and then try to see if the permutes match what we expect. Now the code that does the traversal will detect this in one go and return to us whether the operation is something that can be combined and whether a conjugate is present. Secondly because it does this I can now simplify the checking code itself to essentially just try to apply fixed patterns to each operation. The patterns represent the order operations should appear in. For instance a complex MUL operation combines : Left 1 + Right 1 Left 2 + Right 2 with a permute on the nodes consisting of: { Even, Even } + { Odd, Odd } { Even, Odd } + { Odd, Even } By abstracting over these patterns the checking code becomes quite simple. As part of this I was checking the order of the operands which was left in "slp" order. as in, the same order they showed up in during SLP, which means that the accumulator is first. However it looks like I didn't document this and the x86 optab was implemented assuming the same order as FMA, i.e. that the accumulator is last. I have this changed the order to match that of FMA and FMS which corrects the x86 codegen and will update the Arm targets. This has now also been documented. gcc/ChangeLog: PR tree-optimization/102819 PR tree-optimization/103169 * doc/md.texi: Update docs for cfms, cfma. * tree-data-ref.h (same_data_refs): Accept optional offset. * tree-vect-slp-patterns.cc (is_linear_load_p): Fix issue with repeating patterns. (vect_normalize_conj_loc): Remove. (is_eq_or_top): Change to take two nodes. (enum _conj_status, compatible_complex_nodes_p, vect_validate_multiplication): New. (class complex_add_pattern, complex_add_pattern::matches, complex_add_pattern::recognize, class complex_mul_pattern, complex_mul_pattern::recognize, class complex_fms_pattern, complex_fms_pattern::recognize, class complex_operations_pattern, complex_operations_pattern::recognize, addsub_pattern::recognize): Pass new cache. (complex_fms_pattern::matches, complex_mul_pattern::matches): Pass new cache and use new validation code. * tree-vect-slp.cc (vect_match_slp_patterns_2, vect_match_slp_patterns, vect_analyze_slp): Pass along cache. (compatible_calls_p): Expose. * tree-vectorizer.h (compatible_calls_p, slp_node_hash, slp_compat_nodes_map_t): New. (class vect_pattern): Update signatures include new cache. gcc/testsuite/ChangeLog: PR tree-optimization/102819 PR tree-optimization/103169 * g++.dg/vect/pr99149.cc: xfail for now. * gcc.dg/vect/complex/pr102819-1.c: New test. * gcc.dg/vect/complex/pr102819-2.c: New test. * gcc.dg/vect/complex/pr102819-3.c: New test. * gcc.dg/vect/complex/pr102819-4.c: New test. * gcc.dg/vect/complex/pr102819-5.c: New test. * gcc.dg/vect/complex/pr102819-6.c: New test. * gcc.dg/vect/complex/pr102819-7.c: New test. * gcc.dg/vect/complex/pr102819-8.c: New test. * gcc.dg/vect/complex/pr102819-9.c: New test. * gcc.dg/vect/complex/pr103169.c: New test.
2022-02-01Declare std::array members with attribute const [PR101831].Martin Sebor5-8/+101
Resolves: PR libstdc++/101831 - Spurious maybe-uninitialized warning on std::array::size libstdc++-v3/ChangeLog: PR libstdc++/101831 * include/std/array (begin): Declare const member function attribute const. (end, rbegin, rend, size, max_size, empty, data): Same. * testsuite/23_containers/array/capacity/empty.cc: Add test cases. * testsuite/23_containers/array/capacity/max_size.cc: Same. * testsuite/23_containers/array/capacity/size.cc: Same. * testsuite/23_containers/array/iterators/begin_end.cc: New test.
2022-02-02cris: Reload using special-regs before general-regsHans-Peter Nilsson2-6/+32
On code where reload has an effect (i.e. quite rarely, just enough to be noticeable), this change gets code quality back to the situation prior to "Remove CRIS v32 ACR artefacts". We had from IRA a pseudoregister marked to be reloaded from a union of all allocatable registers (here: SPEC_GENNONACR_REGS) but where the register-class corresponding to the constraint for the register-type alternative (here: GENERAL_REGS) was *not* a subset of that class: SPEC_GENNONACR_REGS (and GENNONACR_REGS) had a one-register "hole" for the ACR register, a register present in GENERAL_REGS. Code in reload.cc:find_reloads adds 4 to the cost of a register-type alternative that is neither a subset of the preferred register class nor vice versa and thus reload thinks it can't use. It would be preferable to look for a non-empty intersection of the two, and use that intersection for that alternative, something that can't be expressed because a register class can't be formed from a random register set. The effect was here that the GENERAL_REGS to/from memory alternatives ("r") had their cost raised such that the SPECIAL_REGS alternatives ("x") looked better. This happened to improve code quality just a little bit compared to GENERAL_REGS being chosen. Anyway, with the improved CRIS register-class topology, the subset-checking code no longer has the GENERAL_REGS-demoting effect. To get the same quality, we have to adjust the port such that SPECIAL_REGS are specifically preferred when possible and advisible, i.e. when there's at least two of those registers as for the CPU variant with multiplication (which happens to be the variant maintained for performance). For the move-pattern, the obvious method may seem to simply "curse" the constraints of some alternatives (by prepending one of the "?!^$" characters) but that method can't be used, because we want the effect to be conditional on the CPU variant. It'd also be a shame to split the "*movsi_internal<setcc><setnz><setnzvc>" into two CPU-variants (with different cursing). Iterators would help, but it still seems unwieldy. Instead, add copies of the GENERAL_REGS variants (to the SPECIAL_REGS alternatives) on the "other" side, and make use of the "enabled" attribute to activate just the desired order of alternatives. gcc: * config/cris/cris.cc (cris_preferred_reload_class): Reject "eliminated" registers and small-enough constants unless reloaded into a class that is a subset of GENERAL_REGS. * config/cris/cris.md (attribute "cpu_variant"): New. (attribute "enabled"): Conditionalize on a matching attribute cpu_variant, if specified. ("*movsi_internal<setcc><setnz><setnzvc>"): For moves to and from memory, add cpu-variant-enabled variants for "r" alternatives on the far side of the "x" alternatives, preferring the "x" ones only for variants where MOF is present (in addition to SRP).
2022-02-02cris: Don't discriminate against ALL_REGS in TARGET_REGISTER_MOVE_COSTHans-Peter Nilsson1-14/+4
When the tightest class including both SPECIAL_REGS and GENERAL_REGS is ALL_REGS, artificially special-casing for *either* to or from, hits artificially hard. This gets the port back to the code quality before the previous patch ("cris: Remove CRIS v32 ACR artefacts") - except for_vfprintf_r and _vfiprintf_r in newlib (still .8 and .4% larger). gcc: * config/cris/cris.cc (cris_register_move_cost): Remove special pre-ira extra cost for ALL_REGS.
2022-02-02cris: Remove CRIS v32 ACR artefactsHans-Peter Nilsson4-27/+13
This is the change to which I alluded to this in r11-220 / d0780379c1b6 as "causes extra register moves in libgcc". It has unfortunate side-effects due to the change in register-class topology. There's a slight improvement in coremark numbers (< 0.07%) though also increase in code size total (< 0.7%) but looking at the individual changes in functions, it's all-over (-7..+7%). Looking specifically at functions that improved in speed, it's also both plus and minus in code sizes. It's unworkable to separate improvements from regressions for this case. I'll follow up with patches to restore the previous code quality, in both size and speed. gcc: * config/cris/constraints.md (define_register_constraint "b"): Now GENERAL_REGS. * config/cris/cris.md (CRIS_ACR_REGNUM): Remove. * config/cris/cris.h: (reg_class, REG_CLASS_NAMES) (REG_CLASS_CONTENTS): Remove ACR_REGS, SPEC_ACR_REGS, GENNONACR_REGS, and SPEC_GENNONACR_REGS. * config/cris/cris.cc (cris_preferred_reload_class): Don't mention ACR_REGS and return GENERAL_REGS instead of GENNONACR_REGS.
2022-02-02cris: For expanded movsi, don't match operands we know will be reloadedHans-Peter Nilsson1-3/+4
In a session investigating unexpected fallout from a change, I noticed reload needs one operand being a register to make an informed decision. It can happen that there's just a constant and a memory operand, as in: (insn 668 667 42 104 (parallel [ (set (mem:SI (plus:SI (reg/v/f:SI 347 [ fs ]) (const_int 168 [0xa8])) \ [1 fs_126(D)->regs.cfa_how+0 S4 A8]) (const_int 2 [0x2])) (clobber (reg:CC 19 dccr)) ]) "<...>/gcc/libgcc/unwind-dw2.c":1121:21 22 {*movsi_internal} (expr_list:REG_UNUSED (reg:CC 19 dccr) (nil))) This was helpfully created by combine. When this happens, reload can't check for costs and preferred register classes, (both operands will start with NO_REGS as the preferred class) and will default to the constraints order in the insn in reload. (Which also does its own temporary merge in find_reloads, but that's a different story.) Better don't match the simple cases. Beware that subregs have to be matched. I'm doing this just for word_mode (SI) for now, but may repeat this for the other valid modes as well. In particular, that goes for DImode as I see the expanded movdi does *almost* this, but uses register_operand instead of REG_S_P (from cris.h). Using REG_S_P is the right choice here because register_operand also matches (subreg (mem ...) ...) *until* reload is done. By itself it's just a sub-0.1% performance win (coremark). Also removing a stale comment. gcc: * config/cris/cris.md ("*movsi_internal<setcc><setnz><setnzvc>"): Conditionalize on (sub-)register operands or operand 1 being 0.
2022-02-02cris: Don't default to -mmul-bug-workaroundHans-Peter Nilsson2-4/+17
This flips the default for the errata handling for an old version (TL;DR: workaround: no multiply instruction last on a cache-line). Newer versions of the CRIS cpu don't have that bug. While the impact of the workaround is very marginal (coremark: less than .05% larger, less than .0005% slower) it's an irritating pseudorandom factor when assessing the impact of other changes. Also, fix a wart requiring changes to more than TARGET_DEFAULT to flip the default. People building old kernels or operating systems to run on ETRAX 100 LX are advised to pass "-mmul-bug-workaround". gcc: * config/cris/cris.h (TARGET_DEFAULT): Don't include MASK_MUL_BUG. (MUL_BUG_ASM_DEFAULT): New macro. (MAYBE_AS_NO_MUL_BUG_ABORT): Define in terms of MUL_BUG_ASM_DEFAULT. * doc/invoke.texi (CRIS Options, -mmul-bug-workaround): Adjust accordingly.
2022-02-02Daily bump.GCC Administrator8-1/+436
2022-02-02libstdc++: Do not use dirent::d_type unconditionallyJonathan Wakely2-0/+8
These new tests should not use the d_type member unless it's actually present on the OS. libstdc++-v3/ChangeLog: * testsuite/27_io/filesystem/iterators/error_reporting.cc: Use autoconf macro to check whether d_type is present. * testsuite/experimental/filesystem/iterators/error_reporting.cc: Likewise.
2022-02-01AutoFDO: don't set param_early_inliner_max_iterations to 10.Eugene Rozenfeld2-4/+1
param_early_inliner_max_iterations specifies the maximum number of nested indirect inlining iterations performed by early inliner. Normally, the default value is 1. For AutoFDO this parameter was also used as the number of iteration for its indirect call promotion loop and the default value was set to 10. While it makes sense to have 10 in the indirect call promotion loop (we want to make the IR match the profiled binary before actual annotation) there is no reason to have a special default value for the regular early inliner. This change removes the special AutoFDO default value setting for param_early_inliner_max_iterations while keeping 10 as the number of iterations for the AutoFDO indirect call promotion loop. This change improves a simple fibonacci benchmark in AutoFDO mode by 15% on x86_64-pc-linux-gnu. Tested on x86_64-pc-linux-gnu. gcc/ChangeLog: * auto-profile.cc (auto_profile): Hard-code the number of iterations (10). gcc/ChangeLog: * opts.cc (common_handle_option): Don't set param_early_inliner_max_iterations to 10 for AutoFDO.
2022-02-01[COMMITTED] Change multiprecision.org to use httpsAndrew Pinski1-1/+1
As reported at https://gcc.gnu.org/pipermail/gcc/2022-February/238216.html, multiprecision.org now uses https so this updates the documentation to use https instead of http. Committed as obvious. gcc/ChangeLog: * doc/install.texi:
2022-02-01libstdc++: Add more tests for filesystem directory iteratorsJonathan Wakely3-1/+87
The PR 97731 test was added to verify a fix to the Filesystem TS code, but we should also have the same test to avoid similar regressions in the C++17 std::filesystem code. Also add tests for directory_options::follow_directory_symlink libstdc++-v3/ChangeLog: * testsuite/27_io/filesystem/iterators/97731.cc: New test. * testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc: Check follow_directory_symlink option. * testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc: Likewise.
2022-02-01libstdc++: Reset filesystem::recursive_directory_iterator on errorJonathan Wakely4-4/+291
The standard requires directory iterators to become equal to the end iterator value if they report an error. Some members functions of filesystem::recursive_directory_iterator fail to do that. libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc (recursive_directory_iterator::increment): Reset state to past-the-end iterator on error. (fs::recursive_directory_iterator::pop(error_code&)): Likewise. (fs::recursive_directory_iterator::pop()): Check _M_dirs before it might get reset. * src/filesystem/dir.cc (recursive_directory_iterator): Likewise, for the TS implementation. * testsuite/27_io/filesystem/iterators/error_reporting.cc: New test. * testsuite/experimental/filesystem/iterators/error_reporting.cc: New test.
2022-02-01libstdc++: Fix doxygen comment for filesystem::perms operatorsJonathan Wakely1-1/+1
libstdc++-v3/ChangeLog: * include/bits/fs_fwd.h (filesystem::perms): Fix comment.
2022-02-01libstdc++: Improve config output for --enable-cstdio [PR104301]Jonathan Wakely2-3/+8
Currently we just print "checking for underlying I/O to use... stdio" unconditionally, whether configured to use stdio_pure or stdio_posix. We should make it clear that the user's configure option chose the right thing. libstdc++-v3/ChangeLog: PR libstdc++/104301 * acinclude.m4 (GLIBCXX_ENABLE_CSTDIO): Print different messages for stdio_pure and stdio_posix options. * configure: Regenerate.
2022-02-01IBM Z: fix `section type conflict` with -mindirect-branch-tableIlya Leoshkevich2-1/+22
s390_code_end () puts indirect branch tables into separate sections and tries to switch back to wherever it was in the beginning by calling switch_to_section (current_function_section ()). First of all, this is unnecessary - the other backends don't do it. Furthermore, at this time there is no current function, but if the last processed function was cold, in_cold_section_p remains set. This causes targetm.asm_out.function_section () to call targetm.section_type_flags (), which in absence of current function decl classifies the section as SECTION_WRITE. This causes a section type conflict with the existing SECTION_CODE. gcc/ChangeLog: * config/s390/s390.cc (s390_code_end): Do not switch back to code section. gcc/testsuite/ChangeLog: * gcc.target/s390/nobp-section-type-conflict.c: New test.
generated by cgit v1.1 at 2024-10-20 03:25:03 +0000