aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-07-28rs6000, Remove __builtin_vec_set_v1ti, __builtin_vec_set_v2df, ↵Carl Love2-53/+0
__builtin_vec_set_v2di This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and __builtin_vec_set_v2di built-ins. The users should just use normal C-code to update the various vector elements. This change was originally intended to be part of the earlier series of cleanup patches. It was initially thought that some additional work would be needed to do some gimple generation instead of these built-ins. However, the existing default code generation does produce the needed code. For the vec_set bif, the equivalent C code is as good or better than the built-in. For the vec_insert bif whose resolving previously made use of the vec_set bif, the assembly code generation is as good as before with the -O3 optimization. Remove the built-ins, use the default gimple generation instead. gcc/ChangeLog: * config/rs6000/rs6000-builtins.def (__builtin_vec_set_v1ti, __builtin_vec_set_v2df, __builtin_vec_set_v2di): Remove built-in definitions. * config/rs6000/rs6000-c.cc (resolve_vec_insert): Remove the handling for constant vec_insert position with VECTOR_UNIT_VSX_P V1TImode, V2DFmode and V2DImode modes.
2024-07-28rs6000, remove __builtin_vsx_xvcmp* built-insCarl Love2-16/+21
This patch removes the built-ins: __builtin_vsx_xvcmpeqsp, __builtin_vsx_xvcmpgesp, __builtin_vsx_xvcmpgtsp. which are similar to the recommended PVIPR documented overloaded vec_cmpeq, vec_cmpgt and vec_cmpge built-ins. The difference is that the overloaded built-ins return a vector of 32-bit booleans. The removed built-ins returned a vector of floats. The __builtin_vsx_xvcmpeqdp, __builtin_vsx_xvcmpgedp and __builtin_vsx_xvcmpgtdp are not removed as they are used by the overloaded vec_cmpeq, vec_cmpgt and vec_cmpge built-ins. The test cases for the __builtin_vsx_xvcmpeqsp, __builtin_vsx_xvcmpgesp, __builtin_vsx_xvcmpgtsp, __builtin_vsx_xvcmpeqdp, __builtin_vsx_xvcmpgedp and __builtin_vsx_xvcmpgtdp are changed to use the overloaded vec_cmpeq, vec_cmpgt, vec_cmpge built-ins. Use of the overloaded built-ins requires the result to be stored in a vector of boolean of the appropriate size or the result must be cast to the return type used by the original __builtin_vsx_xvcmp* built-ins. gcc/ChangeLog: * config/rs6000/rs6000-builtins.def (__builtin_vsx_xvcmpeqsp, __builtin_vsx_xvcmpgesp, __builtin_vsx_xvcmpgtsp): Remove definitions. gcc/testsuite/ChangeLog: * gcc.target/powerpc/vsx-builtin-3.c (do_cmp): Replace __builtin_vsx_xvcmp{eq,gt,ge}{sp,dp} by vec_cmp{eq,gt,ge} respectively and add explicit casts to vector {float,double}. Add more testing code assigning result to vector boolean types.
2024-07-28libstdc++: Add static_assert to std::expected for LWG 3843 and 3940Jonathan Wakely1-0/+8
libstdc++-v3/ChangeLog: * include/std/expected (expected::value): Add assertions for LWG 3843 requirements. (expected<cv void, E>::value): Add assertions for LWG 3940 requirements.
2024-07-28libstdc++: Remove std::basic_format_args default constructor (LWG 4106)Jonathan Wakely2-2/+4
There's no valid use case for default constructing this type, so the committee approved removing the default constructor. libstdc++-v3/ChangeLog: * include/std/format (basic_format_args): Remove default constructor, as per LWG 4106. * testsuite/std/format/arguments/args.cc: Check it isn't default constructible.
2024-07-28libstdc++: Implement P2968R2 "Making std::ignore a first-class object"Jonathan Wakely3-31/+58
This was recently approved for C++26, but we can apply the changes for all modes back to C++11. There's no reason not to make the assignment usable in constant expressions for C++11 mode, and noexcept for all modes. Move the definitions to <bits/utility.h> so they're available in <utility> as well as <tuple>. libstdc++-v3/ChangeLog: * include/bits/utility.h (_Swallow_assign): Make assignment constexpr for C++11 as well, and add noexcept. * include/std/tuple (_Swallow_assign, ignore): Move to bits/utility.h. * testsuite/20_util/headers/utility/ignore.cc: New test.
2024-07-28libstdc++: Reorder template params of std::optional comparisons (LWG 2945)Jonathan Wakely1-18/+18
libstdc++-v3/ChangeLog: * include/std/optional: Reorder parameters in comparison operators as per LWG 2945.
2024-07-28c++: Implement C++26 P2558R2 - Add @, $, and ` to the basic character set ↵Jakub Jelinek17-34/+50
[PR110343] The following patch implements the easy parts of the paper. When @$` are added to the basic character set, it means that R"@$`()@$`" should now be valid (here I've noticed most of the raw string tests were tested solely with -std=c++11 or -std=gnu++11 and I've tried to change that), and on the other side even if by extension $ is allowed in identifiers, \u0024 or \U00000024 or \u{24} should not be, similarly how \u0041 is not allowed. The paper in 3.1 claims though that #include <stdio.h> #define STR(x) #x int main() { printf("%s", STR(\u0060)); // U+0060 is ` GRAVE ACCENT } should have been accepted before this paper (and rejected after it), but g++ rejects it. I've tried to understand it, but am confused on what is the right behavior and why. Consider #define STR(x) #x const char *a = "\u00b7"; const char *b = STR(\u00b7); const char *c = "\u0041"; const char *d = STR(\u0041); const char *e = STR(a\u00b7); const char *f = STR(a\u0041); const char *g = STR(a \u00b7); const char *h = STR(a \u0041); const char *i = "\u066d"; const char *j = STR(\u066d); const char *k = "\u0040"; const char *l = STR(\u0040); const char *m = STR(a\u066d); const char *n = STR(a\u0040); const char *o = STR(a \u066d); const char *p = STR(a \u0040); Neither clang nor gcc emit any diagnostics on the a, c, i and k initializers, those are certainly valid (c is invalid in C23 though). g++ emits with -pedantic-errors errors on all the others, while clang++ on the ones with STR involving \u0041, \u0040 and a\u0066d. The chosen values are \u0040 '@' as something being changed by this paper, \u0041 'A' as basic character set char valid in identifiers before/after, \u00b7 as an example of character which is pedantically valid in identifiers if not at the start and \u066d s something pedantically not valid in identifiers. Now, https://eel.is/c++draft/lex.charset#6 says that UCN used outside of a string/character literal which corresponds to basic character set character (or control character) is ill-formed, that would make d, f, h cases invalid for C++ and l, n, p cases invalid for C++26. https://eel.is/c++draft/lex.name states which characters can appear at the start of the identifier and which can appear after the start. And https://eel.is/c++draft/lex.pptoken states that preprocessing-token is either identifier, or tons of other things, or "each non-whitespace character that cannot be one of the above" Then https://eel.is/c++draft/lex.pptoken#1 says that this last category is invalid if the preprocessing token is being converted into token. And https://eel.is/c++draft/lex.pptoken#2 includes "If any character not in the basic character set matches the last category, the program is ill-formed." Now, e.g. for the C++23 STR(\u0040) case, \u0040 is there not in the basic character set, so valid outside of the literals (not the case anymore in C++26), but it isn't nondigit and doesn't have XID_Start property, so it isn't IMHO an identifier and so must be the "each non-whitespace character that cannot be one of the above" case. Why doesn't the above mentioned https://eel.is/c++draft/lex.pptoken#2 sentence make that invalid? Ignoring that, I'd say it would be then stringized and that feels like it is what clang++ is doing. Now, e.g. for the STR(a\u066d) case, I wonder why that isn't lexed as a identifier followed by \u066d "each non-whitespace character that cannot be one of the above" token and stringified similarly, clang++ rejects that. What GCC libcpp seems to be doing is that if that forms_identifier_p calls _cpp_valid_utf8 or _cpp_valid_ucn with an argument which tells it is first or second+ in identifier, and e.g. _cpp_valid_ucn then for UCNs valid in string literals calls else if (identifier_pos) { int validity = ucn_valid_in_identifier (pfile, result, nst); if (validity == 0) cpp_error (pfile, CPP_DL_ERROR, "universal character %.*s is not valid in an identifier", (int) (str - base), base); else if (validity == 2 && identifier_pos == 1) cpp_error (pfile, CPP_DL_ERROR, "universal character %.*s is not valid at the start of an identifier", (int) (str - base), base); } so basically all those invalid in identifiers cases emit an error and pretend to be valid in identifiers, rather than what e.g. _cpp_valid_utf8 does for C but not for C++ and only for the chars completely invalid in identifiers rather than just valid in identifiers but not at the start: /* In C++, this is an error for invalid character in an identifier because logically, the UTF-8 was converted to a UCN during translation phase 1 (even though we don't physically do it that way). In C, this byte rather becomes grammatically a separate token. */ if (CPP_OPTION (pfile, cplusplus)) cpp_error (pfile, CPP_DL_ERROR, "extended character %.*s is not valid in an identifier", (int) (*pstr - base), base); else { *pstr = base; return false; } The comment doesn't really match what is done in recent C++ versions because there UCNs are translated to characters and not the other way around. 2024-07-25 Jakub Jelinek <jakub@redhat.com> PR c++/110343 libcpp/ * lex.cc: C++26 P2558R2 - Add @, $, and ` to the basic character set. (lex_raw_string): For C++26 allow $@` characters in prefix. * charset.cc (_cpp_valid_ucn): For C++26 reject \u0024 in identifiers. gcc/testsuite/ * c-c++-common/raw-string-1.c: Use { c || c++11 } effective target, remove c++ specific dg-options. * c-c++-common/raw-string-2.c: Likewise. * c-c++-common/raw-string-4.c: Likewise. * c-c++-common/raw-string-5.c: Likewise. Expect some diagnostics only for non-c++26, for c++26 expect different. * c-c++-common/raw-string-6.c: Use { c || c++11 } effective target, remove c++ specific dg-options. * c-c++-common/raw-string-11.c: Likewise. * c-c++-common/raw-string-13.c: Likewise. * c-c++-common/raw-string-14.c: Likewise. * c-c++-common/raw-string-15.c: Use { c || c++11 } effective target, change c++ specific dg-options to just -Wtrigraphs. * c-c++-common/raw-string-16.c: Likewise. * c-c++-common/raw-string-17.c: Use { c || c++11 } effective target, remove c++ specific dg-options. * c-c++-common/raw-string-18.c: Use { c || c++11 } effective target, remove -std=c++11 from c++ specific dg-options. * c-c++-common/raw-string-19.c: Likewise. * g++.dg/cpp26/raw-string1.C: New test. * g++.dg/cpp26/raw-string2.C: New test.
2024-07-28[PR rtl-optimization/116039] Fix life computation for promoted subregsJeff Law2-6/+57
So this turned out to be a neat little test and while the fuzzer found it on RISC-V, I wouldn't be surprised if the underlying issue is also the root cause of the loongarch issue with ext-dce. The key issue is that if we have something like (set (dest) (any_extend (subreg (source)))) If the subreg object is marked with SUBREG_PROMOTED and the sign/unsigned state matches the any_extend opcode, then combine (and I guess anything using simplify-rtx) may simplify that to (set (dest) (source)) That implies that bits outside the mode of the subreg are actually live and valid. This needs to be accounted for during liveness computation. We have to be careful here though. If we're too conservative about setting additional bits live, then we'll inhibit the desired optimization in the coremark examples. To do a good job we need to know the extension opcode. I'm extremely unhappy with how the use handling works in ext-dce. It mixes different conceptual steps and has horribly complex control flow. It only handles a subset of the unary/binary opcodes, etc etc. It's just damn mess. It's going to need some more noodling around. In the mean time this is a bit hacky in that it depends on non-obvious behavior to know it can get the extension opcode, but I don't want to leave the trunk in a broken state while I figure out the refactoring problem. Bootstrapped and regression tested on x86 and tested on the crosses. Pushing to the trunk. PR rtl-optimization/116039 gcc/ * ext-dce.cc (ext_dce_process_uses): Add some comments about concerns with current code. Mark additional bit groups as live when we have an extension of a suitably promoted subreg. gcc/testsuite * gcc.dg/torture/pr116039.c: New test.
2024-07-28Fortran: Suppress wrong End Of File error with user defined IO.Jerry DeLisle2-1/+43
PR libfortran/105361 libgfortran/ChangeLog: * io/list_read.c (finish_list_read): Add a condition check for a user defined derived type IO operation to avoid calling the EOF error. gcc/testsuite/ChangeLog: * gfortran.dg/pr105361.f90: New test.
2024-07-28RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressingChristoph Müllner2-4/+18
auto_inc_dec (-O3) performs optimizations like the following if RVV and XTheadMemIdx is enabled. (insn 23 20 27 3 (set (mem:V4QI (reg:DI 136 [ ivtmp.13 ]) [0 MEM <vector(4) char> [(char *)_39]+0 S4 A32]) (reg:V4QI 168)) "gcc/testsuite/gcc.target/riscv/pr116033.c":12:27 3183 {*movv4qi} (nil)) (insn 40 39 41 3 (set (reg:DI 136 [ ivtmp.13 ]) (plus:DI (reg:DI 136 [ ivtmp.13 ]) (const_int 20 [0x14]))) 5 {adddi3} (nil)) ====> (insn 23 20 27 3 (set (mem:V4QI (post_modify:DI (reg:DI 136 [ ivtmp.13 ]) (plus:DI (reg:DI 136 [ ivtmp.13 ]) (const_int 20 [0x14]))) [0 MEM <vector(4) char> [(char *)_39]+0 S4 A32]) (reg:V4QI 168)) "gcc/testsuite/gcc.target/riscv/pr116033.c":12:27 3183 {*movv4qi} (expr_list:REG_INC (reg:DI 136 [ ivtmp.13 ]) (nil))) The reason why the pass believes that this is legal is, that the mode test in th_memidx_classify_address_modify() requires INTEGRAL_MODE_P (mode), which includes vector modes. Let's restrict the mode test such, that only MODE_INT is allowed. PR target/116033 gcc/ChangeLog: * config/riscv/thead.cc (th_memidx_classify_address_modify): Fix mode test. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr116033.c: New test. Reported-by: Patrick O'Neill <patrick@rivosinc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2024-07-28cp+coroutines: teach convert_to_void to diagnose discarded co_awaitsArsen Arsenović5-1/+91
co_await expressions are nearly calls to Awaitable::await_resume, and, as such, should inherit its nodiscard. A discarded co_await expression should, hence, act as if its call to await_resume was discarded. This patch teaches convert_to_void how to discard 'through' a CO_AWAIT_EXPR. When we discard a CO_AWAIT_EXPR, we can also just discard the await_resume() call conveniently embedded within it. This results in a [[nodiscard]] diagnostic that the PR noted was missing. gcc/cp/ChangeLog: PR c++/110171 * coroutines.cc (co_await_get_resume_call): New function. Returns the await_resume expression of a given co_await. * cp-tree.h (co_await_get_resume_call): New function. * cvt.cc (convert_to_void): Handle CO_AWAIT_EXPRs and call maybe_warn_nodiscard on their resume exprs. gcc/testsuite/ChangeLog: PR c++/110171 * g++.dg/coroutines/pr110171-1.C: New test. * g++.dg/coroutines/pr110171.C: New test.
2024-07-28cp/coroutines: do not rewrite parameters in unevaluated contextsArsen Arsenović2-0/+36
It is possible to use parameters of a parent function of a lambda in unevaluated contexts without capturing them. By not capturing them, we work around the usual mechanism we use to prevent rewriting captured parameters. Prevent this by simply skipping rewrites in unevaluated contexts. Those won't mind the value not being present anyway. This prevents an ICE during parameter substitution. In the testcase from the PR, the rewriting machinery finds a param in the body of the coroutine, which it did not previously encounter while processing the coroutine declaration, and that does not have a DECL_VALUE_EXPR, and fails. gcc/cp/ChangeLog: PR c++/111728 * coroutines.cc (rewrite_param_uses): Skip unevaluated subexpressions. gcc/testsuite/ChangeLog: PR c++/111728 * g++.dg/coroutines/pr111728.C: New test.
2024-07-28[committed] Trivial testcase adjustmentJeff Law1-1/+1
I made pr116037.c dependent on int32 just based on the constants used without noting the int128 vector type. Naturally on targets that don't support int128 the test fails. Fixed by changing the target selector from int32 to int128. Pushed to the trunk. gcc/testsuite * gcc.dg/torture/pr116037.c: Fix target selector.
2024-07-28tree-optimization/116083 - improve behavior when SLP discovery limit is reachedRichard Biener1-14/+12
The following avoids some useless work when the SLP discovery limit is reached, for example allocating a node to cache the failure and starting discovery on split store groups when analyzing BBs. It does not address the issue in the PR which is a gratious budget for discovery when the store group size approaches the number of overall statements. PR tree-optimization/116083 * tree-vect-slp.cc (vect_build_slp_tree): Do not allocate a discovery fail node when we reached the discovery limit. (vect_build_slp_instance): Terminate early when the discovery limit is reached.
2024-07-28libstdc++: fix uses of explicit object parameter [PR116038]Patrick Palka5-6/+92
The type of an implicit object parameter is always the current class. For an explicit object parameter however, its deduced type can be a derived class of the current class. So when combining multiple implicit-object overloads into a single explicit-object overload we need to account for this possibility. For example when accessing a member of the current class through an explicit object parameter, it may now be a derived class from which the member is not accessible, as in the below testcases. This pitfall is discussed[1] in the deducing this paper. The general solution is to cast the explicit object parameter to (a reference to) the current class rather than e.g. using std::forward which preserves the deduced type. This patch corrects the existing problematic uses of explicit object parameters in the library, all of which forward the parameter via std::forward, to instead cast the parameter to the current class via our __like_t alias template. Note that unlike the paper's like_t, ours always returns a reference so we can just write __like_t<Self, B>(self) instead of (_like_t<Self, B>&&)self as the paper does. [1]: https://wg21.link/P0847#name-lookup-within-member-functions (and the section after that) PR libstdc++/116038 libstdc++-v3/ChangeLog: * include/std/functional (_Bind_front::operator()): Use __like_t instead of std::forward when forwarding __self. (_Bind_back::operator()): Likewise. * include/std/ranges (_Partial::operator()): Likewise. (_Pipe::operator()): Likewise. * testsuite/20_util/function_objects/bind_back/116038.cc: New test. * testsuite/20_util/function_objects/bind_front/116038.cc: New test. * testsuite/std/ranges/adaptors/116038.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-07-28rtl-ssa: Define INCLUDE_ARRAYRichard Sandiford15-0/+15
g:72fbd3b2b2a497dbbe6599239bd61c5624203ed0 added a use of std::array without explicitly forcing <array> to be included. That didn't cause problems in my local builds but understandably did for some people. gcc/ * doc/rtl.texi: Document the need to define INCLUDE_ARRAY before including rtl-ssa.h. * rtl-ssa.h: Likewise (in comment). * config/aarch64/aarch64-cc-fusion.cc: Add INCLUDE_ARRAY. * config/aarch64/aarch64-early-ra.cc: Likewise. * config/riscv/riscv-avlprop.cc: Likewise. * config/riscv/riscv-vsetvl.cc: Likewise. * fwprop.cc: Likewise. * late-combine.cc: Likewise. * pair-fusion.cc: Likewise. * rtl-ssa/accesses.cc: Likewise. * rtl-ssa/blocks.cc: Likewise. * rtl-ssa/changes.cc: Likewise. * rtl-ssa/functions.cc: Likewise. * rtl-ssa/insns.cc: Likewise. * rtl-ssa/movement.cc: Likewise.
2024-07-28doc: Document -O1 as the preferred level for large machine-generated codeSam James1-0/+5
At -O1, the intention is that we compile things in a "reasonable" amount of time (ditto memory use). In particular, we try to especially avoid optimizations which scale poorly on pathological cases, as is the case for large machine-generated code. Recommend -O1 for large machine-generated code, as has been informally done on bugs for a while now. This applies (broadly speaking) for both large machine-generated functions but also to a lesser extent repetitive small-but-still-not-tiny functions from a generator program. gcc/ChangeLog: PR middle-end/114855 * doc/invoke.texi (Optimize options): Mention machine-generated code for -O1.
2024-07-28tree-optimization/116081 - typedef vs. non-typedef in vectorizationRichard Biener1-1/+1
The following fixes the code generation difference when using a typedef for the scalar type. The issue is using a pointer equality test for an INTEGER_CST which fails when the types are different variants. PR tree-optimization/116081 * tree-vect-loop.cc (get_initial_defs_for_reduction): Use operand_equal_p for comparing the element with the neutral op.
2024-07-28libstdc++: Add noexcept to bad_expected_access<void> members (LWG 4031)Jonathan Wakely2-4/+17
libstdc++-v3/ChangeLog: * include/std/expected (bad_expected_access<void>): Add noexcept to special member functions, as per LWG 4031. * testsuite/20_util/expected/bad.cc: Check for nothrow copy and move members.
2024-07-28libstdc++: Use concepts and conditional explicit in std::optionalJonathan Wakely1-9/+121
For C++20 mode we can improve compile times by using conditional explicit to reduce the number of constructor overloads. We can also use requires-clauses instead of SFINAE to implement constraints on the constructors and assignment operators. libstdc++-v3/ChangeLog: * include/std/optional (optional): Use C++20 features to simplify overload sets for constructors and assignment operators.
2024-07-28libstdc++: Implement LWG 3836 for std::optional bool conversionsJonathan Wakely2-16/+100
libstdc++-v3/ChangeLog: * include/std/optional (optional): Constrain constructors to prevent problematic bool conversions, as per LWG 3836. * testsuite/20_util/optional/cons/lwg3836.cc: New test.
2024-07-28libstdc++: Implement LWG 3836 for std::expected bool conversionsJonathan Wakely2-16/+77
libstdc++-v3/ChangeLog: * include/std/expected (expected): Constrain constructors to prevent problematic bool conversions, as per LWG 3836. * testsuite/20_util/expected/lwg3836.cc: New test.
2024-07-28libstdc++: Use concepts to simplify std::optional base classesJonathan Wakely1-45/+121
In C++20 mode we can simplify some of the std::optional base class hierarchy using concepts. We can overload the destructor and copy constructor and move constructor with a trivial defaulted version and a constrained non-trivial version. This allows us to remove some class template partial specializations that were used to conditionally define those special members as trivial or non-trivial. This should not change any semantics, but should be less work for the compiler, due to not needing to match partial specializations, and completely removing one level of the inheritance hierarchy. libstdc++-v3/ChangeLog: * include/std/optional (_Optional_payload_base::_Storage) [C++20]: Define constrained non-trivial destructor. (_Optional_payload_base::_Storage<U, false>) [C++20]: Do not define partial specialization when primary template has constrained destructor. (_Optional_base) [C++20]: Define constrained trivial copy and move cons and move constructors. Define payload accessors here instead of inheriting them from _Optional_base_impl. (_Optional_base_impl, _Optional_base<T, false, true>) (_Optional_base<T, true, false>, _Optional_base<T, true, true>) [C++20]: Do not define.
2024-07-28libstdc++: Use _M_get() in std::optional internalsJonathan Wakely1-18/+20
Now that _base::_M_get() doesn't check the precondition, we can use _M_get() instead of operator*() for the internal uses where we've already checked the precondition holds. Add a using-declaration so that we don't need to lookup _M_get in the dependent base class, and make optional<U> a friend so that the converting constructors and assignment operators can use the parameter's _M_get member. libstdc++-v3/ChangeLog: * include/std/optional (optional): Add using-declaraction for _Base::_M_get and declare optional<U> as friend. (optional(const optional<U>&)): Use _M_get instead of operator*. (optional(optional<U>&&)): Likewise. (operator=(const optional<U>&)): Likewise. (operator=(optional<U>&&)): Likewise. (and_then, tansform): Likewise.
2024-07-28libstdc++: Move std::optional assertions out of _M_get()Jonathan Wakely1-14/+26
Currently we implement the precondition for accessing the contained value of a std::optional in the _M_get() accessor in the base class. This means that we always check the assertions even in internal functions that have an explicit check for a contained value being present, such as value() and value_or(U&&). Although those redundant assertions should get optimized out in most cases, they might hurt inliner heuristics and generally give the compiler more work to do. And they won't be optimized out at all for non-optimized builds. The current assertions also result in repeated invalid bug reports, such as PR 91281, PR 101659, PR 102712, and PR 107894. We can move the assertions from the internal accessors to the public member functions where the preconditions are specified. Reviewed-by: Ville Voutilainen <ville.voutilainen@gmail.com> libstdc++-v3/ChangeLog: * include/std/optional (_Optional_base_impl::_M_get()): Move assertions to ... (optional::operator->, optional::operator*): ... here.
2024-07-28tree-optimization/116079 - store motion and clobbersRichard Biener2-0/+22
When we move a store out of an inner loop and remove a clobber in the process, analysis of the inner loop can run into the clobber via the meta-data and crash when accessing its basic-block. The following avoids this by clearing the VDEF which is how it identifies already processed stores. PR tree-optimization/116079 * tree-ssa-loop-im.cc (hoist_memory_references): Clear VDEF of elided clobbers. * gcc.dg/torture/pr116079.c: New testcase.
2024-07-28tree-optimization/116081 - typedef vs. non-typedef in vectorizationRichard Biener1-1/+1
The following addresses a behavioral difference in vector type analysis for typedef vs. non-typedef. It doesn't fix the issue at hand but avoids a spurious difference in the dumps. PR tree-optimization/116081 * tree-vect-stmts.cc (vect_get_vector_types_for_stmt): Properly compare types.
2024-07-28RISC-V: Error early with V and no M extension.Robin Dapp18-20/+60
For calculating the value of a poly_int at runtime we use a multiplication instruction that requires the M extension. Instead of just asserting and ICEing this patch emits an early error at option-parsing time. gcc/ChangeLog: PR target/116036 * config/riscv/riscv.cc (riscv_override_options_internal): Error with TARGET_VECTOR && !TARGET_MUL. gcc/testsuite/ChangeLog: * gcc.target/riscv/arch-31.c: Add m to arch string and expect it. * gcc.target/riscv/arch-32.c: Ditto. * gcc.target/riscv/arch-37.c: Ditto. * gcc.target/riscv/arch-38.c: Ditto. * gcc.target/riscv/predef-14.c: Ditto. * gcc.target/riscv/predef-15.c: Ditto. * gcc.target/riscv/predef-16.c: Ditto. * gcc.target/riscv/predef-26.c: Ditto. * gcc.target/riscv/predef-27.c: Ditto. * gcc.target/riscv/predef-32.c: Ditto. * gcc.target/riscv/predef-33.c: Ditto. * gcc.target/riscv/predef-36.c: Ditto. * gcc.target/riscv/predef-37.c: Ditto. * gcc.target/riscv/rvv/autovec/pr111486.c: Add m to arch string. * gcc.target/riscv/compare-debug-1.c: Ditto. * gcc.target/riscv/compare-debug-2.c: Ditto. * gcc.target/riscv/rvv/base/pr116036.c: New test.
2024-07-28RISC-V: Allow LICM hoist POLY_INT configuration code sequenceJuzhe-Zhong4-4/+76
Realize in recent benchmark evaluation (coremark-pro zip-test): vid.v v2 vmv.v.i v5,0 .L9: vle16.v v3,0(a4) vrsub.vx v4,v2,a6 ---> LICM failed to hoist it outside the loop. The root cause is: (insn 56 47 57 4 (set (subreg:DI (reg:HI 220) 0) (reg:DI 223)) "rvv.c":11:9 208 {*movdi_64bit} -> Its result used by the following vrsub.vx then supress the hoist of the vrsub.vx (nil)) (insn 57 56 59 4 (set (reg:RVVMF2HI 216) (if_then_else:RVVMF2HI (unspec:RVVMF32BI [ (const_vector:RVVMF32BI repeat [ (const_int 1 [0x1]) ]) (reg:DI 350) (const_int 2 [0x2]) repeated x2 (const_int 1 [0x1]) (reg:SI 66 vl) (reg:SI 67 vtype) ] UNSPEC_VPREDICATE) (minus:RVVMF2HI (vec_duplicate:RVVMF2HI (reg:HI 220)) (reg:RVVMF2HI 217)) (unspec:RVVMF2HI [ (reg:DI 0 zero) ] UNSPEC_VUNDEF))) "rvv.c":11:9 6938 {pred_subrvvmf2hi_reverse_scalar} (expr_list:REG_DEAD (reg:HI 220) (nil))) This patch fixes it generate (set (reg:HI) (subreg:HI (reg:DI))) instead of (set (subreg:DI (reg:DI)) (reg:DI)). After this patch: vid.v v2 vrsub.vx v2,v2,a7 vmv.v.i v4,0 .L3: vle16.v v3,0(a4) Tested on both RV32 and RV64 no regression. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_legitimize_move): Fix poly_int dest generation. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/poly_licm-1.c: New test. * gcc.target/riscv/rvv/autovec/poly_licm-2.c: New test. * gcc.target/riscv/rvv/autovec/poly_licm-3.c: New test.
2024-07-28libstdc++: Fix testsuite for remote testing (and sim)Andrew Pinski1-1/+2
The problem here is that v3_additional_files will have a space at the begining of the string as dg-additional-files will append `" " $files` to it. Then when split is called on that string, there will be an empty file and copying a dir will just fail for remote/sim testing (I didn't look at why it works for native testing though). Ran a full libstdc++ testsuite using a sim board for testing. libstdc++-v3/ChangeLog: * testsuite/lib/libstdc++.exp (v3_target_compile): Call string trim on v3_target_compile before calling split. Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
2024-07-28rtl-ssa: Fix split_clobber_group tree insertion [PR116044]Richard Sandiford2-30/+39
PR116044 is a regression in the testsuite on AMD GCN caused (again) by the split_clobber_group code. The first patch in this area (g:71b31690a7c52413496e91bcc5ee4c68af2f366f) fixed a bug caused by carrying the old group over as one of the split ones. That patch instead: - created two new groups - inserted them in the splay tree as neighbours of the old group - removed the old group, and - invalidated the old group (to force lazy recomputation when a clobber's parent group is queried) However, this left add_def trying to insert the new definition relative to a stale splay tree root. The second patch (g:34f33ea801563e2eabb348e8d3e9344a91abfd48) attempted to fix that by inserting it relative to the new root. But that's not always correct either. We specifically want to insert it after the first of the two new groups, whether that group is the root or not. This patch does that, and tries to refactor the code to make it a bit less brittle. gcc/ PR rtl-optimization/116044 * rtl-ssa/functions.h (function_info::split_clobber_group): Return an array of two clobber_groups. * rtl-ssa/accesses.cc (function_info::split_clobber_group): Return the new clobber groups. Don't modify the splay tree here. (function_info::add_def): Update call accordingly. Generalize the splay tree insertion code so that the new definition can be inserted as a child of any existing node, not just the root. Fix the insertion used after calling split_clobber_group.
2024-07-28SVE Intrinsics: Change return type of redirect_call to gcall.Jennifer Schmitz3-5/+5
As suggested in the review of https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657474.html, this patch changes the return type of gimple_folder::redirect_call from gimple * to gcall *. The motivation for this is that so far, most callers of the function had been casting the result of the function to gcall. These call sites were updated. The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression. OK for mainline? Signed-off-by: Jennifer Schmitz <jschmitz@nvidia.com> gcc/ * config/aarch64/aarch64-sve-builtins.cc (gimple_folder::redirect_call): Update return type. * config/aarch64/aarch64-sve-builtins.h: Likewise. * config/aarch64/aarch64-sve-builtins-sve2.cc (svqshl_impl::fold): Remove cast to gcall. (svrshl_impl::fold): Likewise.
2024-07-28Maintain complex constraint vector order during PTA solvingRichard Biener1-12/+61
There's a FIXME comment in the PTA constraint solver that the vector of complex constraints can get unsorted which can lead to duplicate entries piling up during node unification. The following fixes this with the assumption that delayed updates to constraints are uncommon (otherwise re-sorting the whole vector would be more efficient). * tree-ssa-structalias.cc (constraint_equal): Take const reference to constraints. (constraint_vec_find): Similar. (solve_graph): Keep constraint vector sorted and verify sorting with checking.
2024-07-28i386: Adjust rtx cost for imulq and imulw [PR115749]Lingling Kong2-8/+24
gcc/ChangeLog: PR target/115749 * config/i386/x86-tune-costs.h (struct processor_costs): Adjust rtx_cost of imulq and imulw for COST_N_INSNS (4) to COST_N_INSNS (3). gcc/testsuite/ChangeLog: * gcc.target/i386/pr115749.c: New test.
2024-07-28Daily bump.GCC Administrator10-1/+1055
2024-07-28diagnostics: SARIF output: tweak output for UNKNOWN_LOCATIONDavid Malcolm1-8/+115
gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_builder::make_locations_arr): Don't add entirely empty location objects, such as for UNKNOWN_LOCATION. (test_sarif_diagnostic_context::test_sarif_diagnostic_context): Add param "main_input_filename". (selftest::test_simple_log): Provide above param. Verify that "locations" is empty. (selftest::test_simple_log_2): New. (selftest::diagnostic_format_sarif_cc_tests): Call it. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: add selftests for SARIF outputDavid Malcolm6-8/+264
The existing DejaGnu-based tests for our SARIF output used regexes to verify the JSON at the string level, which lets us test for the presence of properties, but doesn't check the overall structure. This patch uses the selftest framework to verify the structure of the tree of JSON values for a log containing one diagnostic. No functional change intended. gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_builder::flush_to_object): New, using code moved from... (sarif_builder::end_group): ...here. (class selftest::test_sarif_diagnostic_context): New. (selftest::test_simple_log): New. (selftest::diagnostic_format_sarif_cc_tests): Call it. * json.h (json::object::is_empty): New. * selftest-diagnostic.cc (test_diagnostic_context::report): New. * selftest-diagnostic.h (test_diagnostic_context::report): New decl. * selftest-json.cc (selftest::assert_json_string_eq): New. (selftest::expect_json_object_with_string_property): New. (selftest::assert_json_string_property_eq): New. * selftest-json.h (selftest::assert_json_string_eq): New decl. (ASSERT_JSON_STRING_EQ): New macro. (selftest::expect_json_object_with_string_property): New decl. (EXPECT_JSON_OBJECT_WITH_STRING_PROPERTY): New macro. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: add "annotations" property (§3.28.6)David Malcolm5-1/+110
This patch extends our SARIF output so that if a diagnostic has any labelled source ranges, the "location" object gains an "annotations" property capturing them (§3.28.6). For example, given this textual output: ../../src/gcc/testsuite/gcc.dg/bad-binary-ops.c: In function ‘test_2’: ../../src/gcc/testsuite/gcc.dg/bad-binary-ops.c:31:11: error: invalid operands to binary + (have ‘struct s’ and ‘struct t’) 30 | return (some_function () | ~~~~~~~~~~~~~~~~ | | | struct s 31 | + some_other_function ()); | ^ ~~~~~~~~~~~~~~~~~~~~~~ | | | struct t the SARIF output gains this within the result's location[0]: "annotations": [{"startLine": 30, "startColumn": 11, "endColumn": 27, "message": {"text": "struct s"}}, {"startLine": 31, "startColumn": 13, "endColumn": 35, "message": {"text": "struct t"}}]}]}, gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_builder::make_location_object): Add "annotations" property if there are any labelled ranges (§3.28.6). (selftest::test_make_location_object): Verify annotations are added to location_obj. * json.h (json::array::size): New. (json::array::operator[]): New. * selftest-json.cc (selftest::expect_json_object_with_array_property): New. * selftest-json.h (selftest::expect_json_object_with_array_property): New decl. (EXPECT_JSON_OBJECT_WITH_ARRAY_PROPERTY): New macro. gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-Wbidi-chars.c: Verify that we have an "annotations" property for the labelled ranges (§3.28.6). Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: add "{start,end}TimeUtc" properties (§§3.20.7-8)David Malcolm2-0/+33
gcc/ChangeLog: * diagnostic-format-sarif.cc (make_date_time_string_for_current_time): New. (sarif_invocation::sarif_invocation): Set "startTimeUtc" property (§3.20.7). (sarif_invocation::prepare_to_flush): Set "endTimeUtc" property (§3.20.8). gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-1.c: Verify that we have "startTimeUtc" and "endTimeUtc" properties of the correct form. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: add "arguments" property (§3.20.2)David Malcolm7-11/+132
gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_invocation::sarif_invocation): Add "original_argv" param and use it to populate "arguments" property (§3.20.2). (sarif_builder::sarif_builder): Pass argv to m_invocation_obj's ctor. * diagnostic.cc (diagnostic_context::initialize): Initialize m_original_argv. (diagnostic_context::finish): Clean up m_original_argv. (diagnostic_context::set_original_argv): New. * diagnostic.h: Include "unique-argv.h". (diagnostic_context::set_original_argv): New decl. (diagnostic_context::get_original_argv): New decl. (diagnostic_context::m_original_argv): New field. * toplev.cc: Include "unique-argv.h". (general_init): Add "original_argv" param and move it to global_dc. (toplev::main): Stash a copy of the original argv before expansion, and pass it to general_init for use by SARIF output. * unique-argv.h: New file. gcc/jit/ChangeLog: * jit-playback.cc (jit::playback_context::compile) Add a trailing null to argvec. gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-1.c: Verify that we have an "arguments" property (§3.20.2). Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: add "workingDirectory" property (§3.20.19)David Malcolm2-5/+11
gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_builder::make_artifact_location_object): Make public. (sarif_invocation::sarif_invocation): Add param "builder". Use it to potentially populate the "workingDirectory" property with the result of pwd (§3.20.19). (sarif_builder::sarif_builder): Pass *this to m_invocation_obj's ctor. gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-1.c: Verify that we have a "workingDirectory" property. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: potentially add escaped renderings of source ↵David Malcolm14-90/+669
(§3.3.4) This patch adds support to our SARIF output for cases where rich_loc.escape_on_output_p () is true, such as for -Wbidi-chars. In such cases, the pertinent SARIF "location" object gains a property bag with property "gcc/escapeNonAscii": true, and the "artifactContent" within the location's physical location's snippet" gains a "rendered" property (§3.3.4) that escapes non-ASCII text in the snippet, such as: "rendered": {"text": where "text" has a string value such as (for a "trojan source" attack): "9 | /*<U+202E> } <U+2066>if (isAdmin)<U+2069> <U+2066> begin admins only */\n" " | ~~~~~~~~ ~~~~~~~~ ^\n" " | | | |\n" " | | | end of bidirectional context\n" " | U+202E (RIGHT-TO-LEFT OVERRIDE) U+2066 (LEFT-TO-RIGHT ISOLATE)\n" where the escaping is affected by -fdiagnostics-escape-format=; with -fdiagnostics-escape-format=bytes, the rendered text of the above is: "9 | /*<e2><80><ae> } <e2><81><a6>if (isAdmin)<e2><81><a9> <e2><81><a6> begin admins only */\n" " | ~~~~~~~~~~~~ ~~~~~~~~~~~~ ^\n" " | | | |\n" " | U+202E (RIGHT-TO-LEFT OVERRIDE) U+2066 (LEFT-TO-RIGHT ISOLATE) end of bidirectional context\n" The patch also refactors/adds enough selftest machinery to be able to test the snippet generation from within the selftest framework, rather than just within DejaGnu (where the regex-based testing isn't sophisticated enough to verify such properties as the above). gcc/ChangeLog: * Makefile.in (OBJS-libcommon): Add selftest-json.o. * diagnostic-format-sarif.cc: Include "selftest.h", "selftest-diagnostic.h", "selftest-diagnostic-show-locus.h", "selftest-json.h", and "text-range-label.h". (class content_renderer): New. (sarif_builder::m_rules_arr): Convert to std::unique_ptr. (sarif_builder::make_location_object): Add class escape_nonascii_renderer. If rich_loc.escape_on_output_p (), pass a nonnull escape_nonascii_renderer to maybe_make_physical_location_object as its snippet_renderer, and add a property bag property "gcc/escapeNonAscii" to the SARIF location object. For other overloads of make_location_object, pass nullptr for the snippet_renderer. (sarif_builder::maybe_make_region_object_for_context): Add "snippet_renderer" param and pass it to maybe_make_artifact_content_object. (sarif_builder::make_tool_object): Drop "const". (sarif_builder::make_driver_tool_component_object): Likewise. Use typesafe unique_ptr variant of object::set for setting "rules" property on driver_obj. (sarif_builder::maybe_make_artifact_content_object): Add param "r" and use it to potentially set the "rendered" property (§3.3.4). (selftest::test_make_location_object): New. (selftest::diagnostic_format_sarif_cc_tests): New. * diagnostic-show-locus.cc: Include "text-range-label.h" and "selftest-diagnostic-show-locus.h". (selftests::diagnostic_show_locus_fixture::diagnostic_show_locus_fixture): New. (selftests::test_layout_x_offset_display_utf8): Use diagnostic_show_locus_fixture to simplify and consolidate setup code. (selftests::test_diagnostic_show_locus_one_liner): Likewise. (selftests::test_one_liner_colorized_utf8): Likewise. (selftests::test_diagnostic_show_locus_one_liner_utf8): Likewise. * gcc-rich-location.h (class text_range_label): Move to new file text-range-label.h. * selftest-diagnostic-show-locus.h: New file, based on material in diagnostic-show-locus.cc. * selftest-json.cc: New file. * selftest-json.h: New file. * selftest-run-tests.cc (selftest::run_tests): Call selftest::diagnostic_format_sarif_cc_tests. * selftest.h (selftest::diagnostic_format_sarif_cc_tests): New decl. gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-sarif-file-Wbidi-chars.c: Verify that we have a property bag with property "gcc/escapeNonAscii": true. Verify that we have a "rendered" property for a snippet. * gcc.dg/plugin/diagnostic_plugin_test_show_locus.c: Include "text-range-label.h". gcc/ChangeLog: * text-range-label.h: New file, taking class text_range_label from gcc-rich-location.h. libcpp/ChangeLog: * include/rich-location.h (semi_embedded_vec::semi_embedded_vec): Add copy ctor. (rich_location::rich_location): Remove "= delete" from decl of copy ctor. Add deleted decl of move ctor. (rich_location::operator=): Remove "= delete" from decl of copy assignment. Add deleted decl of move assignment. (fixit_hint::fixit_hint): Add copy ctor decl. Add deleted decl of move. (fixit_hint::operator=): Add copy assignment decl. Add deleted decl of move assignment. * line-map.cc (rich_location::rich_location): New copy ctor. (fixit_hint::fixit_hint): New copy ctor. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: JSON output: use std::unique_ptr throughoutDavid Malcolm1-60/+62
No functional change intended. gcc/ChangeLog: * diagnostic-format-json.cc: Include "make-unique.h". (json_output_format::m_toplevel_array): Convert to std::unique_ptr. (json_output_format::json_output_format): Update accordingly. (json_output_format::~json_output_format): Remove manual "delete" of field. (json_from_expanded_location): Convert return type to std::unique_ptr. (json_from_location_range): Likewise. Use nullptr rather than NULL. (json_from_fixit_hint): Convert return type to std::unique_ptr. (json_from_metadata): Likewise. (make_json_for_path): Likewise. (json_output_format::on_end_diagnostic): Use std::unique_ptr throughout. (json_file_output_format::~json_file_output_format): Use nullptr. (selftest::test_unknown_location): Update to use std::unique_ptr. (selftest::test_bad_endpoints): Likewise. Replace NULL with nullptr. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: use std::unique_ptr throughoutDavid Malcolm3-337/+337
No functional change intended. gcc/analyzer/ChangeLog: * checker-event.cc (maybe_add_sarif_properties): Update setting of "original_fndecl" to use typesafe unique_ptr variant of json::object::set. gcc/ChangeLog: * diagnostic-format-sarif.cc: Include "make-unique.h". Convert raw pointers to std::unique_ptr throughout to indicate ownership, adding comments in the few places where pointers are borrowed. Use typesafe unique_ptr variants of json::object::set and json::array::append throughout to make types of properties more explicit, whilst using "auto" to reduce typing. Use "nullptr" rather than "NULL" throughout. * diagnostic-format-sarif.h (make_sarif_logical_location_object): Use std::unique_ptr for return type. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28json: support std::unique_ptr in array::append and object::setDavid Malcolm11-6/+58
This patch uses templates to add overloads of json::array::append and json::object::set taking std::unique_ptr<T> where T is a subclass of json::value. Doing so makes it much easier to track memory ownership and enforce schema validity when constructing non-trivial JSON; using the wrong kind of JSON value leads to compile-time errors like the following: error: cannot convert ‘unique_ptr<sarif_message>’ to ‘unique_ptr<sarif_log>’ 629 | location_obj->set<sarif_log> ("message", std::move (message_obj)); | ~~~~~~~~~~^~~~~~~~~~~~~ | | | unique_ptr<sarif_message> No functional change intended. gcc/ChangeLog: * diagnostic-format-json.cc: Define INCLUDE_MEMORY. * diagnostic-format-sarif.cc: Likewise. * dumpfile.cc: Likewise. * gcov.cc: Likewise. * json.cc: Likewise. Include "make-unique.h". (selftest::test_formatting): Exercise overloads of array::append and object::set that use unique_ptr. * json.h: Require INCLUDE_MEMORY to have been defined. (json::object::set): Add a template to add a family of overloads taking a std::unique_ptr<JsonType> (json::array::append): Likewise. * optinfo-emit-json.cc: Define INCLUDE_MEMORY. * optinfo.cc: Likewise. * timevar.cc: Likewise. * toplev.cc: Likewise. * tree-diagnostic-client-data-hooks.cc: Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: output formats: use references for non-null pointersDavid Malcolm6-123/+122
No functional change intended. gcc/ChangeLog: * diagnostic-format-json.cc (json_from_expanded_location): Make "static". Pass param "context" by reference, as it cannot be null. (json_from_location_range): Likewise for param "context". (json_from_fixit_hint): Likewise. (make_json_for_path): Likewise. (json_output_format::on_end_diagnostic): Update for above changes. (diagnostic_output_format_init_json::diagnostic_output_format_init_json): Pass param "context" by reference, as it cannot be null. (diagnostic_output_format_init_json_stderr): Likewise. (diagnostic_output_format_init_json_file): Likewise. (selftest::test_unknown_location): Update for above changes. (selftest::test_bad_endpoints): Likewise. * diagnostic-format-sarif.cc (sarif_builder::m_context): Convert from pointer to reference. (sarif_invocation::add_notification_for_ice): Convert both params from pointers to references. (sarif_invocation::prepare_to_flush): Likewise for "context". (sarif_result::on_nested_diagnostic): Likewise for "context" and "builder". (sarif_result::on_diagram): Likewise. (sarif_ice_notification::sarif_ice_notification): Likewise. (sarif_builder::sarif_builder): Likewise for "context". (sarif_builder::end_diagnostic): Likewise. (sarif_builder::emit_diagram): Likewise. (sarif_builder::make_result_object): Likewise. (make_reporting_descriptor_object_for_warning): Likewise. (sarif_builder::make_locations_arr): Update for change to m_context. (sarif_builder::get_sarif_column): Likewise. (sarif_builder::make_message_object_for_diagram): Convert "context" from pointer to reference. (sarif_builder::make_tool_object): Likewise for "m_context". (sarif_builder::make_driver_tool_component_object): Likewise. (sarif_builder::get_or_create_artifact): Likewise. (sarif_builder::maybe_make_artifact_content_object): Likewise. (sarif_builder::get_source_lines): Likewise. (sarif_output_format::on_end_diagnostic): Update for above changes. (sarif_output_format::on_diagram): Likewise. (sarif_output_format::sarif_output_format): Likewise. (diagnostic_output_format_init_sarif): Convert param "context" from pointer to reference. (diagnostic_output_format_init_sarif_stderr): Likewise. (diagnostic_output_format_init_sarif_file): Likewise. (diagnostic_output_format_init_sarif_stream): Likewise. * diagnostic.cc (diagnostic_output_format_init): Likewise. * diagnostic.h (diagnostic_output_format_init): Likewise. (diagnostic_output_format_init_json_stderr): Likewise. (diagnostic_output_format_init_json_file): Likewise. (diagnostic_output_format_init_sarif_stderr): Likewise. (diagnostic_output_format_init_sarif_file): Likewise. (diagnostic_output_format_init_sarif_stream): Likewise. (json_from_expanded_location): Delete decl. * gcc.cc (driver_handle_option): Update for change to diagnostic_output_format_init. * opts.cc (common_handle_option): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28diagnostics: SARIF output: add sarif_object subclasses throughoutDavid Malcolm2-215/+399
No functional change intended. gcc/ChangeLog: * diagnostic-format-sarif.cc: Introduce subclasses of sarif_object for all aspects of the spec that we're using. Replace almost all usage of json::object with uses of these subclasses, the only remaining use of json::object being for originalUriBaseIds, as per SARIF 2.1.0 §3.14.14. This stronger typing makes it considerably easier to maintain validity against the schema. * diagnostic-format-sarif.h (class sarif_logical_location): New. (make_sarif_logical_location_object): Convert return type from json::object * to sarif_logical_location *. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28gcov: reduce use of naked "new" for json outputDavid Malcolm1-2/+2
No functional change intended. gcc/ChangeLog: * gcov.cc (output_intermediate_json_line): Use json::object::set_integer to avoid naked "new". Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28analyzer: reduce use of naked "new" for json dumpsDavid Malcolm9-47/+39
No functional change intended. gcc/analyzer/ChangeLog: * call-string.cc (call_string::to_json): Avoid naked "new". * constraint-manager.cc (bounded_range::set_json_attr): Likewise. (equiv_class::to_json): Likewise. (constraint::to_json): Likewise. (bounded_ranges_constraint::to_json): Likewise. * diagnostic-manager.cc (saved_diagnostic::to_json): Likewise. (saved_diagnostic::maybe_add_sarif_properties): Likewise. * engine.cc (exploded_node::to_json): Likewise. (exploded_edge::to_json): Likewise. * program-point.cc (program_point::to_json): Likewise. * program-state.cc (program_state::to_json): Likewise. * sm.cc (state_machine::to_json): Likewise. * store.cc (binding_cluster::to_json): Likewise. (store::to_json): Likewise. * supergraph.cc (supernode::to_json): Likewise. (superedge::to_json): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-07-28json: add array::append_stringDavid Malcolm5-9/+17
No functional change intended. gcc/analyzer/ChangeLog: * supergraph.cc (supernode::to_json): Avoid naked "new" by using json::array::append_string. (supernode::to_json): Likewise. gcc/ChangeLog: * diagnostic-format-sarif.cc (sarif_artifact::populate_roles): Avoid naked "new" by using json::array::append_string. (sarif_builder::maybe_make_kinds_array): Likewise. * json.cc (json::array::append_string): New. (selftest::test_writing_arrays): Use it. * json.h (json::array::append_string): New decl. * optinfo-emit-json.cc (optrecord_json_writer::pass_to_json): Avoid naked "new" by using json::array::append_string. (optrecord_json_writer::optinfo_to_json): Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com>