summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Daily bump.releases/gcc-12GCC Administrator15 hours1-1/+1
|
* Daily bump.GCC Administrator39 hours3-1/+39
|
* Do not enable -mblock-ops-vector-pair.Michael Meissner41 hours1-11/+0
| | | | | | | | | | | | | | | | | | | | | Testing has shown that using the load vector pair and store vector pair instructions for block moves has some performance issues on power10. A patch on June 11th modified the code so that GCC would not set -mblock-ops-vector-pair by default if we are tuning for power10, but it would set the option if we were tuning for a different machine and have load and store vector pair instructions enabled. This patch eliminates the code setting -mblock-ops-vector-pair. If you want to generate load vector pair and store vector pair instructions for block moves, you must use -mblock-ops-vector-pair. 2022-08-05 Michael Meissner <meissner@linux.ibm.com> gcc/ * config/rs6000/rs6000.cc (rs6000_option_override_internal): Remove code setting -mblock-ops-vector-pair. Back port patch from trunk on 8/3.
* libstdc++: Make std::string_view(Range&&) constructor explicitJonathan Wakely2 days3-10/+50
| | | | | | | | | | | | | | | The P2499R0 paper was recently approved for C++23. libstdc++-v3/ChangeLog: * include/std/string_view (basic_string_view(Range&&)): Add explicit as per P2499R0. * testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc: Adjust implicit conversions. Check implicit conversions fail. * testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc: Likewise. (cherry picked from commit 2678386df2cc3505da85e95643327aa928e66a8e)
* libstdc++: Rename data members of std::unexpected and std::bad_expected_accessJonathan Wakely2 days1-16/+16
| | | | | | | | | | | | | | The P2549R1 paper was accepted for C++23. I already implemented it for our <expected>, but I didn't rename the private daata members, only the public member functions. This renames the data members for consistency with the working draft. libstdc++-v3/ChangeLog: * include/std/expected (unexpected::_M_val): Rename to _M_unex. (bad_expected_access::_M_val): Likewise. (cherry picked from commit 07c7ee4d2d42f4728928556dbbe0700f9a13db90)
* libstdc++: Update value of __cpp_lib_ios_noreplace macroJonathan Wakely2 days4-6/+6
| | | | | | | | | | | | | | | | | My P2467R1 proposal was accepted for C++23 so there's an official value for this macro now. libstdc++-v3/ChangeLog: * include/bits/ios_base.h (__cpp_lib_ios_noreplace): Update value to 202207L. * include/std/version (__cpp_lib_ios_noreplace): Likewise. * testsuite/27_io/basic_ofstream/open/char/noreplace.cc: Check for new value. * testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc: Likewise. (cherry picked from commit 3e9bd6b2b1782891639fa5d49b7d2a933b8e85cd)
* Daily bump.GCC Administrator3 days1-1/+1
|
* Daily bump.GCC Administrator4 days3-1/+128
|
* libstdc++: Improve directory iterator abstractions for openatJonathan Wakely4 days3-43/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the _Dir::open_subdir function decides whether to construct a _Dir_base with just a pathname, or a file descriptor and pathname. But that means it is tightly coupled to the implementation of _Dir_base::openat, which is what actually decides whether to use a file descriptor or not. If the derived class passes a file descriptor and filename, but the base class expects a full path and ignores the file descriptor, then recursive_directory_iterator cannot recurse. This change introduces a new type that provides the union of all the information available to the derived class (the full pathname, as well as a file descriptor for a directory and another pathname relative to that directory). This allows the derived class to be agnostic to how the base class will use that information. libstdc++-v3/ChangeLog: * src/c++17/fs_dir.cc (_Dir::dir_and_pathname):: Replace with current() returning _At_path. (_Dir::_Dir, _Dir::open_subdir, _Dir::do_unlink): Adjust. * src/filesystem/dir-common.h (_Dir_base::_At_path): New class. (_Dir_base::_Dir_Base, _Dir_base::openat): Use _At_path. * src/filesystem/dir.cc (_Dir::dir_and_pathname): Replace with current() returning _At_path. (_Dir::_Dir, _Dir::open_subdir): Adjust. (cherry picked from commit 198781144f33b0ef17dd2094580b5c77ad97d6e8)
* libstdc++: Tweak common_iterator::operator-> return type [PR104443]Jonathan Wakely4 days1-1/+1
| | | | | | | | | | | | | | | This adjusts the return type to match the resolution of LWG 3672. There is no functional difference, because decltype(auto) always deduced a value anyway, but this makes it simpler and consistent with the working draft. libstdc++-v3/ChangeLog: PR libstdc++/104443 * include/bits/stl_iterator.h (common_iterator::operator->): Change return type to just auto. (cherry picked from commit b5f5d1b36edbcd7d923f2e2653e54e52637c715b)
* libstdc++: Check for EOF if extraction avoids buffer overflow [PR106248]Jonathan Wakely4 days3-5/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In r11-2581-g17abcc77341584 (for LWG 2499) I added overflow checks to the pre-C++20 operator>>(istream&, char*) overload. Those checks can cause extraction to stop after filling the buffer, where previously it would have tried to extract another character and stopped at EOF. When that happens we no longer set eofbit in the stream state, which is consistent with the behaviour of the new C++20 overload, but is an observable and unexpected change in the C++17 behaviour. What makes it worse is that the behaviour change is dependent on optimization, because __builtin_object_size is used to detect the buffer size and that only works when optimizing. To avoid the unexpected and optimization-dependent change in behaviour, set eofbit manually if we stopped extracting because of the buffer size check, but had reached EOF anyway. If the stream's rdstate() != goodbit or width() is non-zero and smaller than the buffer, there's nothing to do. Otherwise, we filled the buffer and need to check for EOF, and maybe set eofbit. The new check is guarded by #ifdef __OPTIMIZE__ because otherwise __builtin_object_size is useless. There's no point compiling and emitting dead code that can't be eliminated because we're not optimizing. We could add extra checks that the next character in the buffer is not whitespace, to detect the case where we stopped early and prevented a buffer overflow that would have happened otherwise. That would allow us to assert or set badbit in the stream state when undefined behaviour was prevented. However, those extra checks would increase the size of the function, potentially reducing the likelihood of it being inlined, and so making the buffer size detection less reliable. It seems preferable to prevent UB and silently truncate, rather than miss the UB and allow the overflow to happen. libstdc++-v3/ChangeLog: PR libstdc++/106248 * include/std/istream [C++17] (operator>>(istream&, char*)): Set eofbit if we stopped extracting at EOF. * testsuite/27_io/basic_istream/extractors_character/char/pr106248.cc: New test. * testsuite/27_io/basic_istream/extractors_character/wchar_t/pr106248.cc: New test. (cherry picked from commit 5ae74944af1de032d4a27fad4a2287bd3a2163fd)
* libstdc++: Add nodiscard attribute to filesystem operationsJonathan Wakely4 days16-24/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of these are not truly "pure" because they access the file system, e.g. exists and file_size, but they do not modify anything and are only useful for the return value. If you really want to use one of those functions just to check whether an error is reported (either via an exception or an error_code& argument) you can still do so, but you need to cast the discarded result to void. Several tests need such a change, because they were indeed only calling the functions to check for expected errors. libstdc++-v3/ChangeLog: * include/bits/fs_ops.h: Add nodiscard to all pure functions. * include/experimental/bits/fs_ops.h: Likewise. * testsuite/27_io/filesystem/operations/all.cc: Do not discard results of absolute and canonical. * testsuite/27_io/filesystem/operations/absolute.cc: Cast discarded result to void. * testsuite/27_io/filesystem/operations/canonical.cc: Likewise. * testsuite/27_io/filesystem/operations/exists.cc: Likewise. * testsuite/27_io/filesystem/operations/is_empty.cc: Likewise. * testsuite/27_io/filesystem/operations/read_symlink.cc: Likewise. * testsuite/27_io/filesystem/operations/status.cc: Likewise. * testsuite/27_io/filesystem/operations/symlink_status.cc: Likewise. * testsuite/27_io/filesystem/operations/temp_directory_path.cc: Likewise. * testsuite/experimental/filesystem/operations/canonical.cc: Likewise. * testsuite/experimental/filesystem/operations/exists.cc: Likewise. * testsuite/experimental/filesystem/operations/is_empty.cc: Likewise. * testsuite/experimental/filesystem/operations/read_symlink.cc: Likewise. * testsuite/experimental/filesystem/operations/temp_directory_path.cc: Likewise. (cherry picked from commit f7a148304a71f3d3ad6845b7966fdc3af88c9e45)
* libstdc++: Support constexpr global std::string for size < 15 [PR105995]Jonathan Wakely4 days2-1/+13
| | | | | | | | | | | | | | I don't think this is required by the standard, but it's easy to support. libstdc++-v3/ChangeLog: PR libstdc++/105995 * include/bits/basic_string.h (_M_use_local_data): Initialize the entire SSO buffer. * testsuite/21_strings/basic_string/cons/char/105995.cc: New test. (cherry picked from commit 98a0d72a610a87e8e383d366e50253ddcc9a51dd)
* libstdc++: Fix indentation in allocator base classesJonathan Wakely4 days2-6/+6
| | | | | | | | | libstdc++-v3/ChangeLog: * include/bits/new_allocator.h: Fix indentation. * include/ext/malloc_allocator.h: Likewise. (cherry picked from commit 29da01709facbcc7efef4fd6767660d417f44531)
* libstdc++: Check for size overflow in constexpr allocation [PR105957]Jonathan Wakely4 days2-1/+24
| | | | | | | | | | | libstdc++-v3/ChangeLog: PR libstdc++/105957 * include/bits/allocator.h (allocator::allocate): Check for overflow in constexpr allocation. * testsuite/20_util/allocator/105975.cc: New test. (cherry picked from commit 0a9af7b4ef1b8aa85cc8820acf54d41d1569fc10)
* libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]Jonathan Wakely4 days6-61/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When I fixed PR libstdc++/92978 I introduced a regression whereby std::lcm(INT_MIN, 1) and std::lcm(50000, 49999) would no longer produce errors during constant evaluation. Those calls are undefined, because they violate the preconditions that |m| and the result can be represented in the return type (which is int in both those cases). The regression occurred because __absu<unsigned>(INT_MIN) is well-formed, due to the explicit casts to unsigned in that new helper function, and the out-of-range multiplication is well-formed, because unsigned arithmetic wraps instead of overflowing. To fix 92978 I made std::gcm and std::lcm calculate |m| and |n| immediately, yielding a common unsigned type that was used to calculate the result. That was partly correct, but there's no need to use an unsigned type. Doing so only suppresses the overflow errors so the compiler can't detect them. This change replaces __absu with __abs_r that returns the common type (not its corresponding unsigned type). This way we can detect overflow in __abs_r when required, while still supporting the most-negative value when it can be represented in the result type. To detect LCM results that are out of range of the result type we still need explicit checks, because neither constant evaluation nor UBsan will complain about unsigned wrapping for cases such as std::lcm(500000u, 499999u). We can detect those overflows efficiently by using __builtin_mul_overflow and asserting. libstdc++-v3/ChangeLog: PR libstdc++/105844 * include/experimental/numeric (experimental::gcd): Simplify assertions. Use __abs_r instead of __absu. (experimental::lcm): Likewise. Remove use of __detail::__lcm so overflow can be detected. * include/std/numeric (__detail::__absu): Rename to __abs_r and change to allow signed result type, so overflow can be detected. (__detail::__lcm): Remove. (gcd): Simplify assertions. Use __abs_r instead of __absu. (lcm): Likewise. Remove use of __detail::__lcm so overflow can be detected. * testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines. * testsuite/26_numerics/lcm/lcm_neg.cc: Likewise. * testsuite/26_numerics/gcd/105844.cc: New test. * testsuite/26_numerics/lcm/105844.cc: New test. (cherry picked from commit 671970a5621e18e7079b4ca113e56434c858db66)
* libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble ↵Jakub Jelinek4 days1-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PR106079] The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble is used (either default through --with-long-double-format=ieee or when used explicitly). The problem is that the read/write transfer routines are called with BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say it is the IEEE quad real(kind=16) rather than the IBM double double real(kind=16). For the floating point input/output we then handle kind 17 specially, but for B/O/Z we just treat the bytes of the floating point value as binary blob and using 17 in that case results in unexpected behavior, for write it means we don't estimate right how many chars we'll need and print ******************** etc. rather than what we should, and even with explicit size we'd print one further byte than intended. For read it would even mean overwriting some unrelated byte after the floating point object. Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls. 2022-08-01 Jakub Jelinek <jakub@redhat.com> PR libfortran/106079 * io/transfer.c (formatted_transfer_scalar_read, formatted_transfer_scalar_write): For type BT_REAL with kind 17 change kind to 16 before calling read_radix or write_{b,o,z}. (cherry picked from commit 82ac4cd213867be939aedee15347e8fd3f200b6a)
* Daily bump.GCC Administrator5 days3-1/+29
|
* rs6000: Adjust -mdejagnu-cpu to filter out -mtune [PR106345]Peter Bergner6 days1-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | As PR106345 shows, when configuring compiler with an explicit option --with-tune=<value>, it would cause some test cases to fail if their test points are sensitive to tune setting, such as: group_ending_nop, loop align etc. It doesn't help that even to specify one explicit -mcpu=. This patch is to adjust the behavior of -mdejagnu-cpu by filtering out all -mcpu= and -mtune= options, then test cases would use <cpu> as tune as the one specified by -mdejagnu-cpu. 2022-07-25 Peter Bergner <bergner@linux.ibm.com> Kewen Lin <linkw@linux.ibm.com> PR testsuite/106345 gcc/ChangeLog: * config/rs6000/rs6000.h (DRIVER_SELF_SPECS): Adjust -mdejagnu-cpu to filter out all -mtune options. (cherry picked from commit 75d20d6c84c12bedd65a904e462f02f0b9eb3f77)
* rs6000: Preserve REG_EH_REGION when replacing load/store [PR106091]Kewen Lin6 days2-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | As test case in PR106091 shows, rs6000 specific pass swaps doesn't preserve the reg_note REG_EH_REGION when replacing some load insn at the end of basic block, it causes the flow info verification to fail unexpectedly. Since memory reference rtx may trap, this patch is to ensure we copy REG_EH_REGION reg_note while replacing swapped aligned load or store. PR target/106091 gcc/ChangeLog: * config/rs6000/rs6000-p8swap.cc (replace_swapped_aligned_store): Copy REG_EH_REGION when replacing one store insn having it. (replace_swapped_aligned_load): Likewise. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106091.c: New test. (cherry picked from commit f4286601933406142b46693660f7f4b682cb50a5)
* Daily bump.GCC Administrator6 days5-1/+40
|
* c: Fix location for _Pragma tokens [PR97498]Lewis Hyatt6 days8-18/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The handling of #pragma GCC diagnostic uses input_location, which is not always as precise as needed; in particular the relative location of some tokens and a _Pragma directive will crucially determine whether a given diagnostic is enabled or suppressed in the desired way. PR97498 shows how the C frontend ends up with input_location pointing to the beginning of the line containing a _Pragma() directive, resulting in the wrong behavior if the diagnostic to be modified pertains to some tokens found earlier on the same line. This patch fixes that by addressing two issues: a) libcpp was not assigning a valid location to the CPP_PRAGMA token generated by the _Pragma directive. b) C frontend was not setting input_location to something reasonable. With this change, the C frontend is able to change input_location to point to the _Pragma token as needed. This is just a two-line fix (one for each of a) and b)), the testsuite changes were needed only because the location on the tested warnings has been somewhat improved, so the tests need to look for the new locations. gcc/c/ChangeLog: PR preprocessor/97498 * c-parser.cc (c_parser_pragma): Set input_location to the location of the pragma, rather than the start of the line. libcpp/ChangeLog: PR preprocessor/97498 * directives.cc (destringize_and_run): Override the location of the CPP_PRAGMA token from a _Pragma directive to the location of the expansion point, as is done for the tokens lexed from it. gcc/testsuite/ChangeLog: PR preprocessor/97498 * c-c++-common/pr97498.c: New test. * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations. * c-c++-common/gomp/pragma-5.c: Likewise. * gcc.dg/pragma-message.c: Likewise. libgomp/ChangeLog: * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for improved warning locations. * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise. (cherry picked from commit 0587cef3d7962a8b0f44779589ba2920dd3d71e5)
* Daily bump.GCC Administrator7 days1-1/+1
|
* Daily bump.GCC Administrator8 days4-1/+47
|
* openmp: Fix up handling of non-rectangular simd loops with pointer type ↵Jakub Jelinek8 days2-18/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | iterators [PR106449] There were 2 issues visible on this new testcase, one that we didn't have special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer part in sizetype, for non-rectangular loop on the other side we can rely on multiplication factor 1, pointers can't be multiplied, without those changes we'd ICE. The other issue was that we put n2 expression directly into a comparison in a condition and regimplified that, for the &a[512] case that and with gimplification being destructed that unfortunately meant modification of original fd->loops[?].n2. Fixed by unsharing the expression. This was causing a runtime failure on the testcase. 2022-07-29 Jakub Jelinek <jakub@redhat.com> PR middle-end/106449 * omp-expand.cc (expand_omp_simd): Fix up handling of pointer iterators in non-rectangular simd loops. Unshare fd->loops[i].n2 or n2 before regimplifying it inside of a condition. * testsuite/libgomp.c-c++-common/pr106449.c: New test. (cherry picked from commit 97d32048c04e9787fccadc4bae1c042754503e34)
* cgraphunit: Don't emit asm thunks for -dx [PR106261]Jakub Jelinek8 days2-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | When -dx option is used (didn't know we have it and no idea what is it useful for), we just expand functions to RTL and then omit all further RTL passes, so the normal functions aren't actually emitted into assembly, just variables. The following testcase ICEs, because we don't emit the methods, but do emit thunks pointing to that and those thunks have unwind info and rely on at least some real functions to be emitted (which is normally the case, thunks are only emitted for locally defined functions) because otherwise there are no CIEs, only FDEs and dwarf2out is upset about it. The following patch fixes that by not emitting assembly thunks for -dx either. 2022-07-27 Jakub Jelinek <jakub@redhat.com> PR debug/106261 * cgraphunit.cc (cgraph_node::assemble_thunks_and_aliases): Don't output asm thunks for -dx. * g++.dg/debug/pr106261.C: New test. (cherry picked from commit f9671b60f9395cb1dca128b92f5dd215f5aeaae1)
* wide-int: Fix up wi::shifted_mask [PR106144]Jakub Jelinek8 days1-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the following self-test testcase shows, wi::shifted_mask sometimes doesn't create canonicalized wide_ints, which then fail to compare equal to canonicalized wide_ints with the same value. In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec 128, while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2 and prec 128. The problem is that the code is written with the assumption that there are 3 bit blocks (or 2 if start is 0), but doesn't consider the possibility where there are 2 bit blocks (or 1 if start is 0) where the highest block isn't present. In that case, there is the optional block of negate ? 0 : -1 elts, followed by just one elt (either one from the if (shift) or just negate ? -1 : 0) and the rest is implicit sign-extension. Only if end < prec there is 1 or more bits above it that have different bit value and so we need to emit all the elts till end and then one more elt. if (end == prec) would work too, because we have: if (width > prec - start) width = prec - start; unsigned int end = start + width; so end is guaranteed to be end <= prec, dunno what is preferred. 2022-07-01 Jakub Jelinek <jakub@redhat.com> PR middle-end/106144 * wide-int.cc (wi::shifted_mask): If end >= prec, return right after emitting element for shift or if shift is 0 first element after start. (wide_int_cc_tests): Add tests for equivalency of wi::mask and wi::shifted_mask with 0 start. (cherry picked from commit e52592073f6df3d7a3acd9f0436dcc32a8b7493d)
* Daily bump.GCC Administrator9 days1-1/+1
|
* Daily bump.GCC Administrator10 days1-1/+1
|
* Daily bump.GCC Administrator11 days4-1/+211
|
* analyzer: fix stray get_element declsDavid Malcolm11 days1-8/+0
| | | | | | | | | | | | (cherry picked from r13-1847-g0460ba622e833d) These were copy&paste errors. gcc/analyzer/ChangeLog: * region.h (code_region::get_element): Remove stray decl. (function_region::get_element): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]David Malcolm11 days4-12/+119
| | | | | | | | | | | | | | | | | | | | | (cherry picked from r13-1562-g897b3b31f0a94b) gcc/analyzer/ChangeLog: PR analyzer/106225 * sm-taint.cc (taint_state_machine::on_stmt): Move handling of assignments from division to... (taint_state_machine::check_for_tainted_divisor): ...this new function. Reject warning when the divisor is known to be non-zero. * sm.cc: Include "analyzer/program-state.h". (sm_context::get_old_region_model): New. * sm.h (sm_context::get_old_region_model): New decl. gcc/testsuite/ChangeLog: PR analyzer/106225 * gcc.dg/analyzer/taint-divisor-1.c: Add test coverage for various correct and incorrect checks against zero. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: fix uninit false positive with -ftrivial-auto-var-init= [PR106204]David Malcolm11 days3-13/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from r13-1517-gb33dd7874523af) -fanalyzer handles -ftrivial-auto-var-init= by special-casing IFN_DEFERRED_INIT to be a no-op, so that e.g.: len_2 = .DEFERRED_INIT (4, 2, &"len"[0]); is treated as a no-op, so that len_2 is still uninitialized after the stmt. PR analyzer/106204 reports that -fanalyzer gives false positives from -Wanalyzer-use-of-uninitialized-value on locals that have their address taken, due to e.g.: _1 = .DEFERRED_INIT (4, 2, &"len"[0]); len = _1; where -fanalyzer leaves _1 uninitialized, and then complains about the assignment to "len". Fixed thusly by suppressing the warning when assigning from such SSA names. gcc/analyzer/ChangeLog: PR analyzer/106204 * region-model.cc (within_short_circuited_stmt_p): Move extraction of assign_stmt to caller. (due_to_ifn_deferred_init_p): New. (region_model::check_for_poison): Move extraction of assign_stmt from within_short_circuited_stmt_p to here. Share logic with call to due_to_ifn_deferred_init_p. gcc/testsuite/ChangeLog: PR analyzer/106204 * gcc.dg/analyzer/torture/uninit-pr106204.c: New test. * gcc.dg/analyzer/uninit-pr106204.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: show saved diagnostics as nodes in .eg.dot dumpsDavid Malcolm11 days3-0/+86
| | | | | | | | | | | | | | | | | | | (cherry picked from r13-1117-gc540077a3bf600) I've been using this tweak to the output of -fdump-analyzer-exploded-graph in my working copies for a while; the extra red nodes make it *much* easier to find the places where diagnostics are being emitted (or rejected by the diagnostic_manager). gcc/analyzer/ChangeLog: * diagnostic-manager.cc (saved_diagnostic::dump_dot_id): New. (saved_diagnostic::dump_as_dot_node): New. * diagnostic-manager.h (saved_diagnostic::dump_dot_id): New decl. (saved_diagnostic::dump_as_dot_node): New decl. * engine.cc (exploded_node::dump_dot): Add nodes for saved diagnostics. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: add more uninit test coverageDavid Malcolm11 days1-0/+19
| | | | | | | | | | | (cherry picked from r13-1116-g44681d45473883) gcc/testsuite/ChangeLog: * gcc.dg/analyzer/uninit-1.c: Add test coverage of attempts to jump through an uninitialized function pointer, and of attempts to pass an uninitialized value to a function call. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* json: fix escaping of '\'David Malcolm11 days1-1/+1
| | | | | | | | | (cherry picked from r13-965-g4f9ad0b4b0a8c7) gcc/ChangeLog: * json.cc (string::print): Fix escaping of '\'. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: fix memory leaksDavid Malcolm11 days4-18/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from r13-334-g99988b0e8b57b3) These leaks all relate to logging within -fdump-analyzer[-stderr] or are one-time leaks; seen with valgrind. gcc/analyzer/ChangeLog: * checker-path.cc (state_change_event::get_desc): Call maybe_free on label_text temporaries. * diagnostic-manager.cc (diagnostic_manager::prune_for_sm_diagnostic): Likewise. * engine.cc (exploded_graph::~exploded_graph): Fix leak of m_per_point_data and m_per_call_string_data values. Simplify cleanup of m_per_function_stats and m_per_point_data values. (feasibility_state::maybe_update_for_edge): Fix leak of result of superedge::get_description. * region-model-manager.cc (region_model_manager::~region_model_manager): Move cleanup of m_setjmp_values to match the ordering of the fields within region_model_manager. Fix leak of values within m_repeated_values_map, m_bits_within_values_map, m_asm_output_values_map, and m_const_fn_result_values_map. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: handle repeated accesses after init of unknown size [PR105285]David Malcolm11 days2-0/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry-picked from r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3) PR analyzer/105285 reports a false positive from -Wanalyzer-null-dereference on git.git's reftable/reader.c. A reduced version of the problem can be seen in test_1a of gcc.dg/analyzer/symbolic-12.c in the following: void test_1a (void *p, unsigned next_off) { struct st_1 *r = p; external_fn(); if (next_off >= r->size) return; if (next_off >= r->size) /* We should have already returned if this is the case. */ __analyzer_dump_path (); /* { dg-bogus "path" } */ } where the analyzer erroneously considers this path, where (next_off >= r->size) is both false and then true: symbolic-12.c: In function ‘test_1a’: symbolic-12.c:22:5: note: path 22 | __analyzer_dump_path (); /* { dg-bogus "path" } */ | ^~~~~~~~~~~~~~~~~~~~~~~ ‘test_1a’: events 1-5 | | 17 | if (next_off >= r->size) | | ^ | | | | | (1) following ‘false’ branch... |...... | 20 | if (next_off >= r->size) | | ~ ~~~~~~~ | | | | | | | (2) ...to here | | (3) following ‘true’ branch... | 21 | /* We should have already returned if this is the case. */ | 22 | __analyzer_dump_path (); /* { dg-bogus "path" } */ | | ~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (4) ...to here | | (5) here | The root cause is that, at the call to the external function, the analyzer considers the cluster for *p to have been touched, binding it to a conjured_svalue, but because p is void * no particular size is known for the write, and so the cluster is bound using a symbolic key covering the base region. Later, the accesses to r->size are handled by binding_cluster::get_any_binding, but binding_cluster::get_binding fails to find a match for the concrete field lookup, due to the key for the binding being symbolic, and reaching this code: 1522 /* If this cluster has been touched by a symbolic write, then the content 1523 of any subregion not currently specifically bound is "UNKNOWN". */ 1524 if (m_touched) 1525 { 1526 region_model_manager *rmm_mgr = mgr->get_svalue_manager (); 1527 return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ()); 1528 } Hence each access to r->size is an unknown svalue, and thus the condition (next_off >= r->size) isn't tracked, leading to the path with contradictory conditions being treated as satisfiable. In the original reproducer in git's reftable/reader.c, the call to the external fn is: reftable_record_type(rec) which is considered to possibly write to *rec, which is *tab, where tab is the void * argument to reftable_reader_seek_void, and thus after the call to reftable_record_type some arbitrary amount of *rec could have been written to. This patch fixes things by detecting the "this cluster has been 'filled' with a conjured value of unknown size" case, and handling get_any_binding on it by returning a sub_svalue of the conjured_svalue, so that repeated accesses to r->size give the same symbolic value, so that the constraint manager rejects the bogus execution path, fixing the false positive. gcc/analyzer/ChangeLog: PR analyzer/105285 * store.cc (binding_cluster::get_any_binding): Handle accessing sub_svalues of clusters where the base region has a symbolic binding. gcc/testsuite/ChangeLog: PR analyzer/105285 * gcc.dg/analyzer/symbolic-12.c: New test. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibilityDavid Malcolm11 days8-3/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074) I found this extension to -fdump-analyzer-feasibility very helpful when debugging PR analyzer/105285. gcc/analyzer/ChangeLog: * diagnostic-manager.cc (epath_finder::process_worklist_item): Call dump_feasible_path when a path that reaches the the target enode is found. (epath_finder::dump_feasible_path): New. * engine.cc (feasibility_state::dump_to_pp): New. * exploded-graph.h (feasibility_state::dump_to_pp): New decl. * feasible-graph.cc (feasible_graph::dump_feasible_path): New. * feasible-graph.h (feasible_graph::dump_feasible_path): New decls. * program-point.cc (function_point::print): Fix missing trailing newlines. * program-point.h (program_point::print_source_line): Remove unimplemented decl. gcc/ChangeLog: * doc/invoke.texi (-fdump-analyzer-feasibility): Mention the fpath.txt output. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* RISC-V: Remove duplicate backslashes from `stack_protect_set_<mode>'Maciej W. Rozycki11 days1-1/+1
| | | | | | | | | | | Remove redundant duplicate backslash characters from \t sequences in the output pattern of the `stack_protect_set_<mode>' RTL insn. gcc/ * config/riscv/riscv.md (stack_protect_set_<mode>): Remove duplicate backslashes. (cherry picked from commit 3cf07cc5e51c833f39f5bad5ca6fbe23c853a214)
* tree-optimization/106189 - avoid division by zero exceptionRichard Biener11 days2-1/+6
| | | | | | | | | | | | | | | The diagnostic code can end up with zero sized array elements with T[][0] and the wide-int code nicely avoids exceptions when dividing by zero in one codepath but not in another. The following fixes the exception by using wide-int in both paths. PR tree-optimization/106189 * gimple-array-bounds.cc (array_bounds_checker::check_mem_ref): Divide using offset_ints. * gcc.dg/pr106189.c: New testcase. (cherry picked from commit bb04f9f23ac0dee2c003118c85372ece50a52220)
* lto: Fix option merging [PR106129]Joseph Myers11 days1-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LTO merging of options from different input files was broken by: commit 227a2ecf663d69972b851f51f1934d18927b62cd Author: Martin Liska <mliska@suse.cz> Date: Fri Mar 12 11:53:47 2021 +0100 lto-wrapper: Use vec<cl_decoded_option> data type. Previously, find_and_merge_options would merge options it read into those in *opts. After this commit, options in *opts on entry to find_and_merge_options are ignored; the only merging that takes place is between multiple sets of options in the same input file that are read in the same call to this function (not sure how that case can occur at all). The effects include, for example, that if some objects are built with PIC enabled and others with it disabled, and the last LTO object processed has PIC enabled, the choice of PIC for the last object will result in the whole program being built as PIC, when the merging logic is intended to ensure that a mixture of PIC and non-PIC objects results in the whole program being built as non-PIC. Fix this with an extra argument to find_and_merge_options to determine whether merging should take place. This shows up a second issue with that commit (which I think wasn't actually intended to change code semantics at all): once merging is enabled again, the check for -Xassembler options became an infinite loop in the case where both inputs had -Xassembler options, with the same first option, so fix that loop to restore the previous semantics. Note that I'm not sure how LTO option merging might be tested in the testsuite (clearly there wasn't sufficient, if any, coverage to detect these bugs). Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR lto/106129 * lto-wrapper.cc (find_option): Add argument start. (merge_and_complain): Loop over existing_opt_index and existing_opt2_index for Xassembler check. Update calls to find_option. (find_and_merge_options): Add argument first to determine whether to merge options with those passed in *opts. (run_gcc): Update calls to find_and_merge_options. (cherry picked from commit 8a8ee37a3325f1009034245676ef4e482c0444a2)
* Fix tree-opt/PR106087: ICE with inline-asm with multiple output and assigned ↵Andrew Pinski11 days2-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | only static vars The problem here is that when we mark the ssa name that was referenced in the now removed dead store (to a write only static variable), the inline-asm would also be removed even though it was defining another ssa name. This fixes the problem by checking to make sure that the statement was only defining one ssa name. Committed as approved after a bootstrapped and tested on x86_64 with no regressions. PR tree-optimization/106087 gcc/ChangeLog: * tree-ssa-dce.cc (simple_dce_from_worklist): Check to make sure the statement is only defining one operand. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/inline-asm-1.c: New test. (cherry picked from commit 71e3daa31cfa35ee58e5899cb00767be92227fd2)
* testsuite: Require int128 for gcc.dg/pr106063.cDimitar Dimitrov11 days1-1/+1
| | | | | | | | | | | | | Require effective target int128 for gcc.dg/pr106063.c. PR tree-optimization/106063 gcc/testsuite/ChangeLog: * gcc.dg/pr106063.c: Require effective target int128. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu> (cherry picked from commit 4ebbf3906895bcb40d7ff2729cf46deae66bc268)
* middle-end: don't lower past veclower [PR106063]Tamar Christina11 days2-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | Hi All, My previous patch can cause a problem if the pattern matches after veclower as it may replace the construct with a vector sequence which the target may not directly support. As such don't perform the rewriting if after veclower unless the target supports the operation. If before veclower do the rewriting as well if the target didn't support the original operation either. gcc/ChangeLog: PR tree-optimization/106063 * match.pd: Do not apply pattern after veclower is not supported. gcc/testsuite/ChangeLog: PR tree-optimization/106063 * gcc.dg/pr106063.c: New test. (cherry picked from commit f7854e2faf7640230062dec3596e71773ca500ed)
* [PR105665] ivopts: check defs of names in base for undefsAlexandre Oliva11 days2-4/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch for PR 100810 tested for undefined SSA_NAMEs appearing directly in the base expression of the potential IV candidate, but that's not enough. The testcase for PR105665 shows an undefined SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg in the referenced SSA_NAME. The variant of that test shows it can be further removed from the referenced SSA_NAME. To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start from known-undefined nonvirtual default defs, and propagate them to any PHI nodes reached by a maybe-undefined arg, as long as there aren't intervening non-PHI uses, that would imply the maybe-undefined name must be defined at that point, otherwise it would invoke undefined behavior. Also test for intervening non-PHI uses of DEFs in the base expr. The test for intervening uses implemented herein relies on dominance; this could be further extended, regarding conditional uses in every path leading to a point as an unconditional use dominating that point, but I haven't implemented that. for gcc/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New. (ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New. (find_ssa_undef): Check precomputed flag and intervening uses. (tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs. for gcc/testsuite/ChangeLog PR tree-optimization/105665 PR tree-optimization/100810 * gcc.dg/torture/pr105665.c: New. (cherry picked from commit be2861fe8c527a5952257462ceca899bb43b1452)
* Daily bump.GCC Administrator12 days7-1/+66
|
* libstdc++: Minor codegen improvement for atomic wait spinloopThomas Rodgers12 days1-10/+7
| | | | | | | | | | This patch merges the spin loops in the atomic wait implementation which is a minor codegen improvement. libstdc++-v3/ChangeLog: * include/bits/atomic_wait.h (__atomic_spin): Merge spin loops. (cherry picked from commit e75da2ace6b6f634237259ef62cfb2d3d34adb10)
* d: Merge upstream dmd 76e3b41375, druntime 1462ebd1, phobos 5fef0d28f.Iain Buclaw12 days31-37/+408
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates D language version to v2.100.1. D front-end changes: - Fix delegate literal with inferred return value that requires following alias-this to not use class cast. - Fix internal error on variadic template type instantiated with two arrays of classes. - `scope(failure)' blocks that contain `return' statements are now deprecated. - Fix regression where wrong cast was inserted for ternary operator and non-int enums. - Fix internal error in code generation trying to reference _d_arraysetctor. - Fix memory corruption when array literal is passed to map in lambda, then returned from nested function. - Generate invariant id on the basis of location rather than a global counter. - Make `noreturn' conversions work. - Fix segfault when `.stringof' of template alias overloaded with function accessed by trait. - Empty array literal passed to scope param not 'falsey' anymore. Phobos changes: - Avoid copying ranges in std.algorithm.comparison.equal. gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 76e3b41375. * dmd/VERSION: Bump version to v2.100.1. * decl.cc (DeclVisitor::visit (VarDeclaration *)): Evaluate RHS of noreturn declaration expressions first. * expr.cc (ExprVisitor::visit (AssignExp *)): Don't generate assignment for noreturn types. libphobos/ChangeLog: * libdruntime/MERGE: Merge upstream druntime 1462ebd1. * src/MERGE: Merge upstream phobos 5fef0d28f.
* Fortran: error recovery from calculation of storage size of a symbol [PR103504]Harald Anlauf12 days2-2/+33
| | | | | | | | | | | | | | | gcc/fortran/ChangeLog: PR fortran/103504 * interface.cc (get_sym_storage_size): Array bounds and character length can only be of integer type. gcc/testsuite/ChangeLog: PR fortran/103504 * gfortran.dg/pr103504.f90: New test. (cherry picked from commit 600956c81c784f4a0cc9d10f6e03e01847afd961)