aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-08-09d: Fix undefined reference to pragma(inline) symbol (PR106563)Iain Buclaw6-19/+161
Functions that are declared `pragma(inline)' should be treated as if they are defined in every translation unit they are referenced from, regardless of visibility protection. Ensure they always get DECL_ONE_ONLY linkage, and start emitting them into other modules that import them. PR d/106563 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (FuncDeclaration *)): Set semanticRun before generating its symbol. (function_defined_in_root_p): New function. (function_needs_inline_definition_p): New function. (maybe_build_decl_tree): New function. (get_symbol_decl): Call maybe_build_decl_tree before returning symbol. (start_function): Use function_defined_in_root_p instead of inline test for locally defined symbols. (set_linkage_for_decl): Check for inline functions before private or protected symbols. gcc/testsuite/ChangeLog: * gdc.dg/torture/torture.exp (srcdir): New proc. * gdc.dg/torture/imports/pr106563math.d: New test. * gdc.dg/torture/imports/pr106563regex.d: New test. * gdc.dg/torture/imports/pr106563uni.d: New test. * gdc.dg/torture/pr106563.d: New test. (cherry picked from commit 04284176d549ff2565406406a6d53ab4ba8e507d)
2022-08-09Daily bump.GCC Administrator3-1/+18
2022-08-08d: Fix ICE in in add_stack_var, at cfgexpand.cc:476Iain Buclaw3-0/+16
The type that triggers the ICE never got completed by the semantic analysis pass. Checking for size forces it to be done, or issue a compile-time error. PR d/106555 gcc/d/ChangeLog: * d-target.cc (Target::isReturnOnStack): Check for return type size. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr106555.d: New test. * gdc.dg/pr106555.d: New test. (cherry picked from commit 4b0253b019943abf2cc5f4db0b7ed67caedffe4a)
2022-08-08Daily bump.GCC Administrator1-1/+1
2022-08-07Daily bump.GCC Administrator1-1/+1
2022-08-06Daily bump.GCC Administrator3-1/+39
2022-08-05Do not enable -mblock-ops-vector-pair.Michael Meissner1-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.
2022-08-05libstdc++: Make std::string_view(Range&&) constructor explicitJonathan Wakely3-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)
2022-08-05libstdc++: Rename data members of std::unexpected and std::bad_expected_accessJonathan Wakely1-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)
2022-08-05libstdc++: Update value of __cpp_lib_ios_noreplace macroJonathan Wakely4-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)
2022-08-05Daily bump.GCC Administrator1-1/+1
2022-08-04Daily bump.GCC Administrator3-1/+128
2022-08-03libstdc++: Improve directory iterator abstractions for openatJonathan Wakely3-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)
2022-08-03Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus18-25/+160
Merge up to r12-8653-g4e5ca7ff8c9afd3c38245aa6b939cd3ae49bf1fe (3 Aug 2022)
2022-08-03libstdc++: Tweak common_iterator::operator-> return type [PR104443]Jonathan Wakely1-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)
2022-08-03libstdc++: Check for EOF if extraction avoids buffer overflow [PR106248]Jonathan Wakely3-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)
2022-08-03libstdc++: Add nodiscard attribute to filesystem operationsJonathan Wakely16-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)
2022-08-03libstdc++: Support constexpr global std::string for size < 15 [PR105995]Jonathan Wakely2-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)
2022-08-03libstdc++: Fix indentation in allocator base classesJonathan Wakely2-6/+6
libstdc++-v3/ChangeLog: * include/bits/new_allocator.h: Fix indentation. * include/ext/malloc_allocator.h: Likewise. (cherry picked from commit 29da01709facbcc7efef4fd6767660d417f44531)
2022-08-03libstdc++: Check for size overflow in constexpr allocation [PR105957]Jonathan Wakely2-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)
2022-08-03libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]Jonathan Wakely6-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)
2022-08-03libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble ↵Jakub Jelinek1-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)
2022-08-03Daily bump.GCC Administrator3-1/+29
2022-08-02openmp-simd-clone: Match shift typesAndrew Stubbs2-1/+15
Ensure that both parameters to vector shifts use the same mode. This is most important for amdgcn where the masks are DImode. gcc/ChangeLog: * omp-simd-clone.cc (simd_clone_adjust): Convert shift_cnt to match the mask type. Co-authored-by: Jakub Jelinek <jakub@redhat.com> (cherry picked from commit b64e937ccde286278743e8fdffea494faa46c214)
2022-08-02amdgcn: 64-bit vector shiftsAndrew Stubbs2-8/+17
Enable 64-bit vector-vector and vector-scalar shifts. gcc/ChangeLog: * config/gcn/gcn-valu.md (V_INT_noHI): New iterator. (<expander><mode>3<exec>): Use V_INT_noHI. (v<expander><mode>3<exec>): Likewise. (cherry picked from commit 6e0ca3fe88d8f98ba6b4009c9483e87afbcf4ee8)
2022-08-02amdgcn: 64-bit notAndrew Stubbs2-0/+25
This makes the auto-vectorizer happier when handling masks. gcc/ChangeLog: * config/gcn/gcn.md (one_cmpldi2): New. (cherry picked from commit 8f4d9c1dedac54942ad28cc1647d48959bec9e77)
2022-08-01rs6000: Adjust -mdejagnu-cpu to filter out -mtune [PR106345]Peter Bergner1-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)
2022-08-01rs6000: Preserve REG_EH_REGION when replacing load/store [PR106091]Kewen Lin2-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)
2022-08-02Daily bump.GCC Administrator5-1/+40
2022-08-01c: Fix location for _Pragma tokens [PR97498]Lewis Hyatt8-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)
2022-08-01Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus9-21/+197
Merge up to commit r12-8647-gd2bafe190c230fc0aeab1ac961bf7ae9f8b5b19f (1st Aug 2022)
2022-08-01openmp: Simplify fold_build_pointer_plus callers in omp-expandJakub Jelinek2-36/+25
Tobias mentioned in PR106449 that fold_build_pointer_plus already fold_converts the second argument to sizetype if it doesn't already have an integral type gimple compatible with sizetype. So, this patch simplifies the callers of fold_build_pointer_plus in omp-expand so that they don't do those conversions manually. 2022-07-29 Jakub Jelinek <jakub@redhat.com> * omp-expand.cc (expand_omp_for_init_counts, expand_omp_for_init_vars, extract_omp_for_update_vars, expand_omp_for_ordered_loops, expand_omp_simd): Don't fold_convert second argument to fold_build_pointer_plus to sizetype. (cherry picked from commit 4796d16de657d7c2720471e61432de0f4a5cb6df)
2022-08-01Daily bump.GCC Administrator1-1/+1
2022-07-31Daily bump.GCC Administrator4-1/+47
2022-07-30openmp: Fix up handling of non-rectangular simd loops with pointer type ↵Jakub Jelinek2-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)
2022-07-30cgraphunit: Don't emit asm thunks for -dx [PR106261]Jakub Jelinek2-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)
2022-07-30wide-int: Fix up wi::shifted_mask [PR106144]Jakub Jelinek1-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)
2022-07-30Daily bump.GCC Administrator1-1/+1
2022-07-29Add libgomp.c-c++-common/pr106449-2.cTobias Burnus2-0/+71
This run-time test test pointer-based iteration with collapse, similar to the '(parallel) simd' test for PR106449 but for 'for'. libgomp/ChangeLog: * testsuite/libgomp.c-c++-common/pr106449-2.c: New test. (cherry picked from commit 85fe7e7dd1f1461b86d92a3a0c1bfd97a06efcc0)
2022-07-29OpenMP/Fortran: Permit assumed-size arrays in uniform clauseTobias Burnus4-1/+47
gcc/fortran/ChangeLog: * openmp.cc (resolve_omp_clauses): Permit assumed-size arrays in uniform clause. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/declare-simd-3.f90: New test. (cherry picked from commit a6afbe5e9528e9ec3f0426d9791bd28e6e584d82)
2022-07-29openmp: Reject invalid forms of C++ #pragma omp atomic compare [PR106448]Jakub Jelinek4-1/+35
The allowed syntaxes of atomic compare don't allow ()s around the condition of ?:, but we were accepting it in one case for C++. Fixed thusly. 2022-07-29 Jakub Jelinek <jakub@redhat.com> PR c++/106448 * parser.cc (cp_parser_omp_atomic): For simple cast followed by CPP_QUERY token, don't try cp_parser_binary_operation if compare is true. * c-c++-common/gomp/atomic-32.c: New test. (cherry picked from commit 2dcceedb3c121f2498ae58d8414e7b8454b7bf55)
2022-07-29Daily bump.GCC Administrator1-1/+1
2022-07-28Merge branch 'releases/gcc-12' into devel/omp/gcc-12Tobias Burnus145-325/+3106
Merge up to r12-8640-gb2ae75fd2afc7d92f5f71748540390b7aebde4c6 (28th July 2022)
2022-07-28Daily bump.GCC Administrator4-1/+211
2022-07-27analyzer: fix stray get_element declsDavid Malcolm1-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>
2022-07-27analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]David Malcolm4-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>
2022-07-27analyzer: fix uninit false positive with -ftrivial-auto-var-init= [PR106204]David Malcolm3-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>
2022-07-27analyzer: show saved diagnostics as nodes in .eg.dot dumpsDavid Malcolm3-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>
2022-07-27analyzer: add more uninit test coverageDavid Malcolm1-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>
2022-07-27json: fix escaping of '\'David Malcolm1-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>