{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":22711503,"defaultBranch":"master","name":"gcc","ownerLogin":"gcc-mirror","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-08-07T06:50:37.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/8382043?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1716279098.0","currentOid":""},"activityList":{"items":[{"before":"19827831516023f2dff449af0b228b2d60190a28","after":"ba57a52dbf6a64ba66f72c20064c5c0e8cc9dbbb","ref":"refs/heads/releases/gcc-12","pushedAt":"2024-05-24T16:24:39.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++: __is_constructible ref binding [PR100667]\n\nThe requirement that a type argument be complete is excessive in the case of\ndirect reference binding to the same type, which does not rely on any\nproperties of the type.  This is LWG 2939.\n\n\tPR c++/100667\n\ngcc/cp/ChangeLog:\n\n\t* semantics.cc (same_type_ref_bind_p): New.\n\t(finish_trait_expr): Use it.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/ext/is_constructible8.C: New test.\n\n(cherry picked from commit 8bb3ef3f6e335e8794590fb712a2661d11d21973)","shortMessageHtmlLink":"c++: __is_constructible ref binding [PR100667]"}},{"before":"782ad2033ea0709a25ef3e899cbb9491406146d5","after":"9031c027827bff44e1b55c366fc7034c43501b4c","ref":"refs/heads/releases/gcc-14","pushedAt":"2024-05-24T15:32:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++: deleting array temporary [PR115187]\n\nDecaying the array temporary to a pointer and then deleting that crashes in\nverify_gimple_stmt, because the TARGET_EXPR is first evaluated inside the\nTRY_FINALLY_EXPR, but the cleanup point is outside.  Fixed by using\nget_target_expr instead of save_expr.\n\nI also adjust the stabilize_expr comment to prevent me from again thinking\nit's a suitable replacement.\n\n\tPR c++/115187\n\ngcc/cp/ChangeLog:\n\n\t* init.cc (build_delete): Use get_target_expr instead of save_expr.\n\t* tree.cc (stabilize_expr): Update comment.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/cpp1z/array-prvalue3.C: New test.","shortMessageHtmlLink":"c++: deleting array temporary [PR115187]"}},{"before":"dae606a11eb99814e452b49241fa76f7678f53b8","after":"9f1798c1a93257526196a3c19828e40fb28ac551","ref":"refs/heads/trunk","pushedAt":"2024-05-24T15:06:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c: Fix for some variably modified types not being recognized [PR114831]\n\nWe did not evaluate expressions with variably modified types correctly\nin typeof and did not produce warnings when jumping over declarations\nusing typeof.  After addressof or array-to-pointer decay we construct\nnew pointer types that have to be marked variably modified if the pointer\ntarget is variably modified.\n\n2024-05-18 Martin Uecker  <uecker@tugraz.at>\n\n\tPR c/114831\ngcc/c/\n\t* c-typeck.cc (array_to_pointer_conversion, build_unary_op):\n\tPropagate flag to pointer target.\n\ngcc/testsuite/\n\t* gcc.dg/pr114831-1.c: New test.\n\t* gcc.dg/pr114831-2.c: New test.\n\t* gcc.dg/gnu23-varmod-1.c: New test.\n\t* gcc.dg/gnu23-varmod-2.c: New test.","shortMessageHtmlLink":"c: Fix for some variably modified types not being recognized [PR114831]"}},{"before":"dae606a11eb99814e452b49241fa76f7678f53b8","after":"9f1798c1a93257526196a3c19828e40fb28ac551","ref":"refs/heads/master","pushedAt":"2024-05-24T15:06:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c: Fix for some variably modified types not being recognized [PR114831]\n\nWe did not evaluate expressions with variably modified types correctly\nin typeof and did not produce warnings when jumping over declarations\nusing typeof.  After addressof or array-to-pointer decay we construct\nnew pointer types that have to be marked variably modified if the pointer\ntarget is variably modified.\n\n2024-05-18 Martin Uecker  <uecker@tugraz.at>\n\n\tPR c/114831\ngcc/c/\n\t* c-typeck.cc (array_to_pointer_conversion, build_unary_op):\n\tPropagate flag to pointer target.\n\ngcc/testsuite/\n\t* gcc.dg/pr114831-1.c: New test.\n\t* gcc.dg/pr114831-2.c: New test.\n\t* gcc.dg/gnu23-varmod-1.c: New test.\n\t* gcc.dg/gnu23-varmod-2.c: New test.","shortMessageHtmlLink":"c: Fix for some variably modified types not being recognized [PR114831]"}},{"before":"5429e6a6467951e3ffc626e6aa40fb32fcc43681","after":"782ad2033ea0709a25ef3e899cbb9491406146d5","ref":"refs/heads/releases/gcc-14","pushedAt":"2024-05-24T14:40:40.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++: Propagate using decls from partitions [PR114868]\n\nThe modules code currently neglects to set OVL_USING_P on the dependency\ncreated for a using-decl, which causes it not to remember that the\nOVL_EXPORT_P flag had been set on it when emitted from the primary\ninterface unit. This patch ensures that it occurs.\n\n\tPR c++/114868\n\ngcc/cp/ChangeLog:\n\n\t* module.cc (depset::hash::add_binding_entity): Propagate\n\tOVL_USING_P for using-declarations.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/modules/using-15_a.C: New test.\n\t* g++.dg/modules/using-15_b.C: New test.\n\t* g++.dg/modules/using-15_c.C: New test.\n\nSigned-off-by: Nathaniel Shead <nathanieloshead@gmail.com>\n(cherry picked from commit 0d0215b10dbbe39d655ceda4af283f288ec7680c)","shortMessageHtmlLink":"c++: Propagate using decls from partitions [PR114868]"}},{"before":"401994d60ab38ffa9e63f368f0456eb7b08599be","after":"dae606a11eb99814e452b49241fa76f7678f53b8","ref":"refs/heads/trunk","pushedAt":"2024-05-24T14:15:40.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++/modules: Improve errors for bad module-directives [PR115200]\n\nThis fixes an ICE when a module directive is not given at global scope.\nAlthough not explicitly mentioned, it seems implied from [basic.link] p1\nand [module.global.frag] that a module-declaration must appear at the\nglobal scope after preprocessing.  Apart from this the patch also\nslightly improves the errors given when accidentally using a module\ncontrol-line in other situations where it is not expected.\n\n\tPR c++/115200\n\ngcc/cp/ChangeLog:\n\n\t* parser.cc (cp_parser_error_1): Special-case unexpected module\n\tdirectives for better diagnostics.\n\t(cp_parser_module_declaration): Check that the module\n\tdeclaration is at global scope.\n\t(cp_parser_import_declaration): Sync error message with that in\n\tcp_parser_error_1.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/modules/mod-decl-1.C: Update error messages.\n\t* g++.dg/modules/mod-decl-6.C: New test.\n\t* g++.dg/modules/mod-decl-7.C: New test.\n\t* g++.dg/modules/mod-decl-8.C: New test.\n\nSigned-off-by: Nathaniel Shead <nathanieloshead@gmail.com>\nReviewed-by: Jason Merrill <jason@redhat.com>","shortMessageHtmlLink":"c++/modules: Improve errors for bad module-directives [PR115200]"}},{"before":"401994d60ab38ffa9e63f368f0456eb7b08599be","after":"dae606a11eb99814e452b49241fa76f7678f53b8","ref":"refs/heads/master","pushedAt":"2024-05-24T14:15:40.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++/modules: Improve errors for bad module-directives [PR115200]\n\nThis fixes an ICE when a module directive is not given at global scope.\nAlthough not explicitly mentioned, it seems implied from [basic.link] p1\nand [module.global.frag] that a module-declaration must appear at the\nglobal scope after preprocessing.  Apart from this the patch also\nslightly improves the errors given when accidentally using a module\ncontrol-line in other situations where it is not expected.\n\n\tPR c++/115200\n\ngcc/cp/ChangeLog:\n\n\t* parser.cc (cp_parser_error_1): Special-case unexpected module\n\tdirectives for better diagnostics.\n\t(cp_parser_module_declaration): Check that the module\n\tdeclaration is at global scope.\n\t(cp_parser_import_declaration): Sync error message with that in\n\tcp_parser_error_1.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/modules/mod-decl-1.C: Update error messages.\n\t* g++.dg/modules/mod-decl-6.C: New test.\n\t* g++.dg/modules/mod-decl-7.C: New test.\n\t* g++.dg/modules/mod-decl-8.C: New test.\n\nSigned-off-by: Nathaniel Shead <nathanieloshead@gmail.com>\nReviewed-by: Jason Merrill <jason@redhat.com>","shortMessageHtmlLink":"c++/modules: Improve errors for bad module-directives [PR115200]"}},{"before":"a1ff3171c3b8d1d13e241fde28a84ae11c10bd87","after":"19827831516023f2dff449af0b228b2d60190a28","ref":"refs/heads/releases/gcc-12","pushedAt":"2024-05-24T13:49:40.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++: unroll pragma in templates [PR111529]\n\nWe were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading to\nproblems with substitution of any wrapped expressions.\n\nLet's also not tell users that lambda templates are available in C++14.\n\n\tPR c++/111529\n\ngcc/cp/ChangeLog:\n\n\t* parser.cc (cp_parser_lambda_declarator_opt): Don't suggest\n\t-std=c++14 for lambda templates.\n\t* pt.cc (tsubst_expr): Move ANNOTATE_EXPR handling...\n\t(tsubst_copy_and_build): ...here.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/ext/unroll-4.C: New test.\n\n(cherry picked from commit 9c62af101e11e1cce573c2b3d2e18b403412dbc8)","shortMessageHtmlLink":"c++: unroll pragma in templates [PR111529]"}},{"before":"a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba","after":"401994d60ab38ffa9e63f368f0456eb7b08599be","ref":"refs/heads/trunk","pushedAt":"2024-05-24T13:49:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"[to-be-committed,v2,RISC-V] Use bclri in constant synthesis\n\nTesting with Zbs enabled by default showed a minor logic error.  After\nthe loop clearing things with bclri, we can only use the sequence if we\nwere able to clear all the necessary bits.  If any bits are still on,\nthen the bclr sequence turned out to not be profitable.\n\n--\n\nSo this is conceptually similar to how we handled direct generation of\nbseti for constant synthesis, but this time for bclr.\n\nIn the bclr case, we already have an expander for AND.  So we just\nneeded to adjust the predicate to accept another class of constant\noperands (those with a single bit clear).\n\nWith that in place constant synthesis is adjusted so that it counts the\nnumber of bits clear in the high 33 bits of a 64bit word.  If that\nnumber is small relative to the current best cost, then we try to\ngenerate the constant with a lui based sequence for the low half which\nimplicitly sets the upper 32 bits as well.  Then we bclri one or more of\nthose upper 33 bits.\n\nSo as an example, this code goes from 4 instructions down to 3:\n\n > unsigned long foo_0xfffffffbfffff7ff(void) { return\n0xfffffffbfffff7ffUL; }\n\nNote the use of 33 bits above.  That's meant to capture cases like this:\n\n > unsigned long foo_0xfffdffff7ffff7ff(void) { return\n0xfffdffff7ffff7ffUL; }\n\nWe can use lui+addi+bclri+bclri to synthesize that in 4 instructions\ninstead of 5.\n\nI'm including a handful of cases covering the two basic ideas above that\nwere found by the testing code.\n\nAnd, no, we're not done yet.  I see at least one more notable idiom\nmissing before exploring zbkb's potential to improve things.\n\nTested in my tester and waiting on Rivos CI system before moving forward.\ngcc/\n\n\t* config/riscv/predicates.md (arith_operand_or_mode_mask): Renamed to..\n\t(arith_or_mode_mask_or_zbs_operand): New predicate.\n\t* config/riscv/riscv.md (and<mode>3): Update predicate for operand 2.\n\t* config/riscv/riscv.cc (riscv_build_integer_1): Use bclri to clear\n\tbits, particularly bits 31..63 when profitable to do so.\n\ngcc/testsuite/\n\n\t* gcc.target/riscv/synthesis-6.c: New test.","shortMessageHtmlLink":"[to-be-committed,v2,RISC-V] Use bclri in constant synthesis"}},{"before":"a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba","after":"401994d60ab38ffa9e63f368f0456eb7b08599be","ref":"refs/heads/master","pushedAt":"2024-05-24T13:49:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"[to-be-committed,v2,RISC-V] Use bclri in constant synthesis\n\nTesting with Zbs enabled by default showed a minor logic error.  After\nthe loop clearing things with bclri, we can only use the sequence if we\nwere able to clear all the necessary bits.  If any bits are still on,\nthen the bclr sequence turned out to not be profitable.\n\n--\n\nSo this is conceptually similar to how we handled direct generation of\nbseti for constant synthesis, but this time for bclr.\n\nIn the bclr case, we already have an expander for AND.  So we just\nneeded to adjust the predicate to accept another class of constant\noperands (those with a single bit clear).\n\nWith that in place constant synthesis is adjusted so that it counts the\nnumber of bits clear in the high 33 bits of a 64bit word.  If that\nnumber is small relative to the current best cost, then we try to\ngenerate the constant with a lui based sequence for the low half which\nimplicitly sets the upper 32 bits as well.  Then we bclri one or more of\nthose upper 33 bits.\n\nSo as an example, this code goes from 4 instructions down to 3:\n\n > unsigned long foo_0xfffffffbfffff7ff(void) { return\n0xfffffffbfffff7ffUL; }\n\nNote the use of 33 bits above.  That's meant to capture cases like this:\n\n > unsigned long foo_0xfffdffff7ffff7ff(void) { return\n0xfffdffff7ffff7ffUL; }\n\nWe can use lui+addi+bclri+bclri to synthesize that in 4 instructions\ninstead of 5.\n\nI'm including a handful of cases covering the two basic ideas above that\nwere found by the testing code.\n\nAnd, no, we're not done yet.  I see at least one more notable idiom\nmissing before exploring zbkb's potential to improve things.\n\nTested in my tester and waiting on Rivos CI system before moving forward.\ngcc/\n\n\t* config/riscv/predicates.md (arith_operand_or_mode_mask): Renamed to..\n\t(arith_or_mode_mask_or_zbs_operand): New predicate.\n\t* config/riscv/riscv.md (and<mode>3): Update predicate for operand 2.\n\t* config/riscv/riscv.cc (riscv_build_integer_1): Use bclri to clear\n\tbits, particularly bits 31..63 when profitable to do so.\n\ngcc/testsuite/\n\n\t* gcc.target/riscv/synthesis-6.c: New test.","shortMessageHtmlLink":"[to-be-committed,v2,RISC-V] Use bclri in constant synthesis"}},{"before":"cf76815d93f065a48c06963b396e2d543e75b7a3","after":"53cdaa755de57e57ba9e787f232adc3cfde88209","ref":"refs/heads/releases/gcc-13","pushedAt":"2024-05-24T13:49:40.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++: unroll pragma in templates [PR111529]\n\nWe were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading to\nproblems with substitution of any wrapped expressions.\n\nLet's also not tell users that lambda templates are available in C++14.\n\n\tPR c++/111529\n\ngcc/cp/ChangeLog:\n\n\t* parser.cc (cp_parser_lambda_declarator_opt): Don't suggest\n\t-std=c++14 for lambda templates.\n\t* pt.cc (tsubst_expr): Move ANNOTATE_EXPR handling...\n\t(tsubst_copy_and_build): ...here.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/ext/unroll-4.C: New test.\n\n(cherry picked from commit 9c62af101e11e1cce573c2b3d2e18b403412dbc8)","shortMessageHtmlLink":"c++: unroll pragma in templates [PR111529]"}},{"before":"886cb5e9524362c898d6eada8009c282e49ecdfa","after":"b35afe75674ff9f79cf9685d099bc80f10442216","ref":"refs/heads/releases/gcc-11","pushedAt":"2024-05-24T13:49:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"c++: binding reference to comma expr [PR114561]\n\nWe represent a reference binding where the referent type is more qualified\nby a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried\nto undo it with STRIP_NOPS, but that doesn't work if the conversion is\nburied in COMPOUND_EXPR.  So instead let's avoid performing that fake\nconversion in the first place.\n\n\tPR c++/114561\n\tPR c++/114562\n\ngcc/cp/ChangeLog:\n\n\t* call.c (convert_like_internal): Avoid adding qualification\n\tconversion in direct reference binding.\n\ngcc/testsuite/ChangeLog:\n\n\t* g++.dg/conversion/ref10.C: New test.\n\t* g++.dg/conversion/ref11.C: New test.\n\n(cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)","shortMessageHtmlLink":"c++: binding reference to comma expr [PR114561]"}},{"before":"6d6f324bda1ccb51cd43ff9d4d017eb71bb2d690","after":"a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba","ref":"refs/heads/trunk","pushedAt":"2024-05-24T12:59:39.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"vect: Fix access size alignment assumption [PR115192]\n\ncreate_intersect_range_checks checks whether two access ranges\na and b are alias-free using something equivalent to:\n\n  end_a <= start_b || end_b <= start_a\n\nIt has two ways of doing this: a \"vanilla\" way that calculates\nthe exact exclusive end pointers, and another way that uses the\nlast inclusive aligned pointers (and changes the comparisons\naccordingly).  The comment for the latter is:\n\n      /* Calculate the minimum alignment shared by all four pointers,\n\t then arrange for this alignment to be subtracted from the\n\t exclusive maximum values to get inclusive maximum values.\n\t This \"- min_align\" is cumulative with a \"+ access_size\"\n\t in the calculation of the maximum values.  In the best\n\t (and common) case, the two cancel each other out, leaving\n\t us with an inclusive bound based only on seg_len.  In the\n\t worst case we're simply adding a smaller number than before.\n\nThe problem is that the associated code implicitly assumed that the\naccess size was a multiple of the pointer alignment, and so the\nalignment could be carried over to the exclusive end pointer.\n\nThe testcase started failing after g:9fa5b473b5b8e289b6542\nbecause that commit improved the alignment information for\nthe accesses.\n\ngcc/\n\tPR tree-optimization/115192\n\t* tree-data-ref.cc (create_intersect_range_checks): Take the\n\talignment of the access sizes into account.\n\ngcc/testsuite/\n\tPR tree-optimization/115192\n\t* gcc.dg/vect/pr115192.c: New test.","shortMessageHtmlLink":"vect: Fix access size alignment assumption [PR115192]"}},{"before":"6d6f324bda1ccb51cd43ff9d4d017eb71bb2d690","after":"a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba","ref":"refs/heads/master","pushedAt":"2024-05-24T12:59:39.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"vect: Fix access size alignment assumption [PR115192]\n\ncreate_intersect_range_checks checks whether two access ranges\na and b are alias-free using something equivalent to:\n\n  end_a <= start_b || end_b <= start_a\n\nIt has two ways of doing this: a \"vanilla\" way that calculates\nthe exact exclusive end pointers, and another way that uses the\nlast inclusive aligned pointers (and changes the comparisons\naccordingly).  The comment for the latter is:\n\n      /* Calculate the minimum alignment shared by all four pointers,\n\t then arrange for this alignment to be subtracted from the\n\t exclusive maximum values to get inclusive maximum values.\n\t This \"- min_align\" is cumulative with a \"+ access_size\"\n\t in the calculation of the maximum values.  In the best\n\t (and common) case, the two cancel each other out, leaving\n\t us with an inclusive bound based only on seg_len.  In the\n\t worst case we're simply adding a smaller number than before.\n\nThe problem is that the associated code implicitly assumed that the\naccess size was a multiple of the pointer alignment, and so the\nalignment could be carried over to the exclusive end pointer.\n\nThe testcase started failing after g:9fa5b473b5b8e289b6542\nbecause that commit improved the alignment information for\nthe accesses.\n\ngcc/\n\tPR tree-optimization/115192\n\t* tree-data-ref.cc (create_intersect_range_checks): Take the\n\talignment of the access sizes into account.\n\ngcc/testsuite/\n\tPR tree-optimization/115192\n\t* gcc.dg/vect/pr115192.c: New test.","shortMessageHtmlLink":"vect: Fix access size alignment assumption [PR115192]"}},{"before":"7acd5d71547f74a2af35bab1b17a518197d25d23","after":"6d6f324bda1ccb51cd43ff9d4d017eb71bb2d690","ref":"refs/heads/trunk","pushedAt":"2024-05-24T12:34:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"MATCH: Look through VIEW_CONVERT when folding VEC_PERM_EXPRs.\n\nThe match.pd patterns to merge two vector permutes into one fail when a\npotentially no-op view convert expressions is between the two permutes.\nThis change lifts this restriction.\n\ngcc/ChangeLog:\n\n\t* match.pd: Allow no-op view_convert between permutes.\n\ngcc/testsuite/ChangeLog:\n\n\t* gcc.dg/fold-perm-2.c: New test.","shortMessageHtmlLink":"MATCH: Look through VIEW_CONVERT when folding VEC_PERM_EXPRs."}},{"before":"7acd5d71547f74a2af35bab1b17a518197d25d23","after":"6d6f324bda1ccb51cd43ff9d4d017eb71bb2d690","ref":"refs/heads/master","pushedAt":"2024-05-24T12:34:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"MATCH: Look through VIEW_CONVERT when folding VEC_PERM_EXPRs.\n\nThe match.pd patterns to merge two vector permutes into one fail when a\npotentially no-op view convert expressions is between the two permutes.\nThis change lifts this restriction.\n\ngcc/ChangeLog:\n\n\t* match.pd: Allow no-op view_convert between permutes.\n\ngcc/testsuite/ChangeLog:\n\n\t* gcc.dg/fold-perm-2.c: New test.","shortMessageHtmlLink":"MATCH: Look through VIEW_CONVERT when folding VEC_PERM_EXPRs."}},{"before":"85e2ce10f76aee93e43aab6558cf8e39cec911e4","after":"7acd5d71547f74a2af35bab1b17a518197d25d23","ref":"refs/heads/trunk","pushedAt":"2024-05-24T11:43:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"testsuite: adjust iteration count for ppc costmodel 76b\n\nFor some hardware which doesn't support unaligned vector memory access,\ntest case costmodel-vect-76b.c expects to see cost modeling would make\nthe decision that it's not profitable for peeling, according to the\ncommit history, test case comments and the way to check.\n\nFor now, the existing loop bound 14 works well for Power7, but it does\nnot for some targets on which the cost of operation vec_perm can be\ndifferent from Power7, such as: Power6, it's 3 vs. 1.  This difference\nfurther causes the difference (10 vs. 12) on the minimum iteration for\nprofitability and cause the failure.  To keep the original test point,\nthis patch is to tweak the loop bound to ensure it's not profitable\nto be vectorized for !vect_no_align with peeling.\n\n\nCo-Authored-By: Kewen Lin <linkw@linux.ibm.com>\n\nfor  gcc/testsuite/ChangeLog\n\n\t* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (N): Tweak.","shortMessageHtmlLink":"testsuite: adjust iteration count for ppc costmodel 76b"}},{"before":"85e2ce10f76aee93e43aab6558cf8e39cec911e4","after":"7acd5d71547f74a2af35bab1b17a518197d25d23","ref":"refs/heads/master","pushedAt":"2024-05-24T11:43:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"testsuite: adjust iteration count for ppc costmodel 76b\n\nFor some hardware which doesn't support unaligned vector memory access,\ntest case costmodel-vect-76b.c expects to see cost modeling would make\nthe decision that it's not profitable for peeling, according to the\ncommit history, test case comments and the way to check.\n\nFor now, the existing loop bound 14 works well for Power7, but it does\nnot for some targets on which the cost of operation vec_perm can be\ndifferent from Power7, such as: Power6, it's 3 vs. 1.  This difference\nfurther causes the difference (10 vs. 12) on the minimum iteration for\nprofitability and cause the failure.  To keep the original test point,\nthis patch is to tweak the loop bound to ensure it's not profitable\nto be vectorized for !vect_no_align with peeling.\n\n\nCo-Authored-By: Kewen Lin <linkw@linux.ibm.com>\n\nfor  gcc/testsuite/ChangeLog\n\n\t* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (N): Tweak.","shortMessageHtmlLink":"testsuite: adjust iteration count for ppc costmodel 76b"}},{"before":"51f4b47c4f4f61fe31a7bd1fa80e08c2438d76a8","after":"85e2ce10f76aee93e43aab6558cf8e39cec911e4","ref":"refs/heads/trunk","pushedAt":"2024-05-24T11:17:39.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Fix gcc.dg/vect/vect-gather-4.c for cascadelake\n\nThere's not really a good way to test what the testcase wants to\ntest, the following exchanges one dump scan for another (imperfect)\none.\n\n\t* gcc.dg/vect/vect-gather-4.c: Scan for not vectorizing using\n\tSLP.","shortMessageHtmlLink":"Fix gcc.dg/vect/vect-gather-4.c for cascadelake"}},{"before":"51f4b47c4f4f61fe31a7bd1fa80e08c2438d76a8","after":"85e2ce10f76aee93e43aab6558cf8e39cec911e4","ref":"refs/heads/master","pushedAt":"2024-05-24T11:17:39.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Fix gcc.dg/vect/vect-gather-4.c for cascadelake\n\nThere's not really a good way to test what the testcase wants to\ntest, the following exchanges one dump scan for another (imperfect)\none.\n\n\t* gcc.dg/vect/vect-gather-4.c: Scan for not vectorizing using\n\tSLP.","shortMessageHtmlLink":"Fix gcc.dg/vect/vect-gather-4.c for cascadelake"}},{"before":"3e06763a695d97aa46c9de71573ec6a43bb92449","after":"51f4b47c4f4f61fe31a7bd1fa80e08c2438d76a8","ref":"refs/heads/trunk","pushedAt":"2024-05-24T07:53:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Fix typo in the testcase.\n\ngcc/testsuite/ChangeLog:\n\n\tPR target/114148\n\t* gcc.target/i386/pr106010-7b.c: Refine testcase.","shortMessageHtmlLink":"Fix typo in the testcase."}},{"before":"3e06763a695d97aa46c9de71573ec6a43bb92449","after":"51f4b47c4f4f61fe31a7bd1fa80e08c2438d76a8","ref":"refs/heads/master","pushedAt":"2024-05-24T07:53:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Fix typo in the testcase.\n\ngcc/testsuite/ChangeLog:\n\n\tPR target/114148\n\t* gcc.target/i386/pr106010-7b.c: Refine testcase.","shortMessageHtmlLink":"Fix typo in the testcase."}},{"before":"c71886f2ca2e46ce1449c7064d6f1b447d02fcba","after":"3e06763a695d97aa46c9de71573ec6a43bb92449","ref":"refs/heads/trunk","pushedAt":"2024-05-24T07:02:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Use simple_dce_from_worklist in phiprop\n\nI noticed that phiprop leaves around phi nodes which\ndefines a ssa name which is unused. This just adds a\nbitmap to mark those ssa names and then calls\nsimple_dce_from_worklist at the very end to remove\nthose phi nodes and all of the dependencies if there\nwas any. This might allow us to optimize something earlier\ndue to the removal of the phi which was taking the address\nof the variables.\n\nBootstrapped and tested on x86_64-linux-gnu with no regressions.\n\ngcc/ChangeLog:\n\n\t* tree-ssa-phiprop.cc (phiprop_insert_phi): Add\n\tdce_ssa_names argument. Add the phi's result to it.\n\t(propagate_with_phi): Add dce_ssa_names argument.\n\tUpdate call to phiprop_insert_phi.\n\t(pass_phiprop::execute): Update call to propagate_with_phi.\n\tCall simple_dce_from_worklist if there was a change.\n\nSigned-off-by: Andrew Pinski <quic_apinski@quicinc.com>","shortMessageHtmlLink":"Use simple_dce_from_worklist in phiprop"}},{"before":"c71886f2ca2e46ce1449c7064d6f1b447d02fcba","after":"3e06763a695d97aa46c9de71573ec6a43bb92449","ref":"refs/heads/master","pushedAt":"2024-05-24T07:02:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Use simple_dce_from_worklist in phiprop\n\nI noticed that phiprop leaves around phi nodes which\ndefines a ssa name which is unused. This just adds a\nbitmap to mark those ssa names and then calls\nsimple_dce_from_worklist at the very end to remove\nthose phi nodes and all of the dependencies if there\nwas any. This might allow us to optimize something earlier\ndue to the removal of the phi which was taking the address\nof the variables.\n\nBootstrapped and tested on x86_64-linux-gnu with no regressions.\n\ngcc/ChangeLog:\n\n\t* tree-ssa-phiprop.cc (phiprop_insert_phi): Add\n\tdce_ssa_names argument. Add the phi's result to it.\n\t(propagate_with_phi): Add dce_ssa_names argument.\n\tUpdate call to phiprop_insert_phi.\n\t(pass_phiprop::execute): Update call to propagate_with_phi.\n\tCall simple_dce_from_worklist if there was a change.\n\nSigned-off-by: Andrew Pinski <quic_apinski@quicinc.com>","shortMessageHtmlLink":"Use simple_dce_from_worklist in phiprop"}},{"before":"ee492101c2e51b58e926307448d35f539aec0b2c","after":"c71886f2ca2e46ce1449c7064d6f1b447d02fcba","ref":"refs/heads/trunk","pushedAt":"2024-05-24T06:12:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Avoid splitting store dataref groups during SLP discovery\n\nThe following avoids splitting store dataref groups during SLP\ndiscovery but instead forces (eventually single-lane) consecutive\nlane SLP discovery for all lanes of the group, creating VEC_PERM\nSLP nodes merging them so the store will always cover the whole group.\n\nWith this for example\n\nint x[1024], y[1024], z[1024], w[1024];\nvoid foo (void)\n{\n  for (int i = 0; i < 256; i++)\n    {\n      x[4*i+0] = y[2*i+0];\n      x[4*i+1] = y[2*i+1];\n      x[4*i+2] = z[i];\n      x[4*i+3] = w[i];\n    }\n}\n\nwhich was previously using hybrid SLP can now be fully SLPed and\nSSE code generated looks better (but of course you never know,\nI didn't actually benchmark).  We of course need a VF of four here.\n\n.L2:\n        movdqa  z(%rax), %xmm0\n        movdqa  w(%rax), %xmm4\n        movdqa  y(%rax,%rax), %xmm2\n        movdqa  y+16(%rax,%rax), %xmm1\n        movdqa  %xmm0, %xmm3\n        punpckhdq       %xmm4, %xmm0\n        punpckldq       %xmm4, %xmm3\n        movdqa  %xmm2, %xmm4\n        shufps  $238, %xmm3, %xmm2\n        movaps  %xmm2, x+16(,%rax,4)\n        movdqa  %xmm1, %xmm2\n        shufps  $68, %xmm3, %xmm4\n        shufps  $68, %xmm0, %xmm2\n        movaps  %xmm4, x(,%rax,4)\n        shufps  $238, %xmm0, %xmm1\n        movaps  %xmm2, x+32(,%rax,4)\n        movaps  %xmm1, x+48(,%rax,4)\n        addq    $16, %rax\n        cmpq    $1024, %rax\n        jne     .L2\n\nThe extra permute nodes merging distinct branches of the SLP\ntree might be unexpected for some code, esp. since\nSLP_TREE_REPRESENTATIVE cannot be meaningfully set and we\ncannot populate SLP_TREE_SCALAR_STMTS or SLP_TREE_SCALAR_OPS\nconsistently as we can have a mix of both.\n\nThe patch keeps the sub-trees form consecutive lanes but that's\nin principle not necessary if we for example have an even/odd\nsplit which now would result in N single-lane sub-trees.  That's\nleft for future improvements.\n\nThe interesting part is how VLA vector ISAs handle merging of\ntwo vectors that's not trivial even/odd merging.  The strathegy\nof how to build the permute tree might need adjustments for that\n(in the end splitting each branch to single lanes and then doing\neven/odd merging would be the brute-force fallback).  Not sure\nhow much we can or should rely on the SLP optimize pass to handle\nthis.\n\nThe gcc.dg/vect/slp-12a.c case is interesting as we currently split\nthe 8 store group into lanes 0-5 which we SLP with an unroll factor\nof two (on x86-64 with SSE) and the remaining two lanes are using\ninterleaving vectorization with a final unroll factor of four.  Thus\nwe're using hybrid SLP within a single store group.  After the change\nwe discover the same 0-5 lane SLP part as well as two single-lane\nparts feeding the full store group.  But that results in a load\npermutation that isn't supported (I have WIP patchs to rectify that).\nSo we end up cancelling SLP and vectorizing the whole loop with\ninterleaving which is IMO good and results in better code.\n\nThis is similar for gcc.target/i386/pr52252-atom.c where interleaving\ngenerates much better code than hybrid SLP.  I'm unsure how to update\nthe testcase though.\n\ngcc.dg/vect/slp-21.c runs into similar situations.  Note that when\nwhen analyzing SLP operations we discard an instance we currently\nforce the full loop to have no SLP because hybrid detection is\nbroken.  It's probably not worth fixing this at this moment.\n\nFor gcc.dg/vect/pr97428.c we are not splitting the 16 store group\ninto two but merge the two 8 lane loads into one before doing the\nstore and thus have only a single SLP instance.  A similar situation\nhappens in gcc.dg/vect/slp-11c.c but the branches feeding the\nsingle SLP store only have a single lane.  Likewise for\ngcc.dg/vect/vect-complex-5.c and gcc.dg/vect/vect-gather-2.c.\n\ngcc.dg/vect/slp-cond-1.c has an additional SLP vectorization\nwith a SLP store group of size two but two single-lane branches.\n\n\t* tree-vect-slp.cc (vect_build_slp_instance): Do not split\n\tstore dataref groups on loop SLP discovery failure but create\n\ta single SLP instance for the stores but branch to SLP sub-trees\n\tand merge with a series of VEC_PERM nodes.\n\n\t* gcc.dg/vect/pr97428.c: Expect a single store SLP group.\n\t* gcc.dg/vect/slp-11c.c: Likewise, if !vect_load_lanes.\n\t* gcc.dg/vect/vect-complex-5.c: Likewise.\n\t* gcc.dg/vect/slp-12a.c: Do not expect SLP.\n\t* gcc.dg/vect/slp-21.c: Remove not important scanning for SLP.\n\t* gcc.dg/vect/slp-cond-1.c: Expect one more SLP if !vect_load_lanes.\n\t* gcc.dg/vect/vect-gather-2.c: Expect SLP to be used.\n\t* gcc.target/i386/pr52252-atom.c: XFAIL test for palignr.","shortMessageHtmlLink":"Avoid splitting store dataref groups during SLP discovery"}},{"before":"ee492101c2e51b58e926307448d35f539aec0b2c","after":"c71886f2ca2e46ce1449c7064d6f1b447d02fcba","ref":"refs/heads/master","pushedAt":"2024-05-24T06:12:39.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Avoid splitting store dataref groups during SLP discovery\n\nThe following avoids splitting store dataref groups during SLP\ndiscovery but instead forces (eventually single-lane) consecutive\nlane SLP discovery for all lanes of the group, creating VEC_PERM\nSLP nodes merging them so the store will always cover the whole group.\n\nWith this for example\n\nint x[1024], y[1024], z[1024], w[1024];\nvoid foo (void)\n{\n  for (int i = 0; i < 256; i++)\n    {\n      x[4*i+0] = y[2*i+0];\n      x[4*i+1] = y[2*i+1];\n      x[4*i+2] = z[i];\n      x[4*i+3] = w[i];\n    }\n}\n\nwhich was previously using hybrid SLP can now be fully SLPed and\nSSE code generated looks better (but of course you never know,\nI didn't actually benchmark).  We of course need a VF of four here.\n\n.L2:\n        movdqa  z(%rax), %xmm0\n        movdqa  w(%rax), %xmm4\n        movdqa  y(%rax,%rax), %xmm2\n        movdqa  y+16(%rax,%rax), %xmm1\n        movdqa  %xmm0, %xmm3\n        punpckhdq       %xmm4, %xmm0\n        punpckldq       %xmm4, %xmm3\n        movdqa  %xmm2, %xmm4\n        shufps  $238, %xmm3, %xmm2\n        movaps  %xmm2, x+16(,%rax,4)\n        movdqa  %xmm1, %xmm2\n        shufps  $68, %xmm3, %xmm4\n        shufps  $68, %xmm0, %xmm2\n        movaps  %xmm4, x(,%rax,4)\n        shufps  $238, %xmm0, %xmm1\n        movaps  %xmm2, x+32(,%rax,4)\n        movaps  %xmm1, x+48(,%rax,4)\n        addq    $16, %rax\n        cmpq    $1024, %rax\n        jne     .L2\n\nThe extra permute nodes merging distinct branches of the SLP\ntree might be unexpected for some code, esp. since\nSLP_TREE_REPRESENTATIVE cannot be meaningfully set and we\ncannot populate SLP_TREE_SCALAR_STMTS or SLP_TREE_SCALAR_OPS\nconsistently as we can have a mix of both.\n\nThe patch keeps the sub-trees form consecutive lanes but that's\nin principle not necessary if we for example have an even/odd\nsplit which now would result in N single-lane sub-trees.  That's\nleft for future improvements.\n\nThe interesting part is how VLA vector ISAs handle merging of\ntwo vectors that's not trivial even/odd merging.  The strathegy\nof how to build the permute tree might need adjustments for that\n(in the end splitting each branch to single lanes and then doing\neven/odd merging would be the brute-force fallback).  Not sure\nhow much we can or should rely on the SLP optimize pass to handle\nthis.\n\nThe gcc.dg/vect/slp-12a.c case is interesting as we currently split\nthe 8 store group into lanes 0-5 which we SLP with an unroll factor\nof two (on x86-64 with SSE) and the remaining two lanes are using\ninterleaving vectorization with a final unroll factor of four.  Thus\nwe're using hybrid SLP within a single store group.  After the change\nwe discover the same 0-5 lane SLP part as well as two single-lane\nparts feeding the full store group.  But that results in a load\npermutation that isn't supported (I have WIP patchs to rectify that).\nSo we end up cancelling SLP and vectorizing the whole loop with\ninterleaving which is IMO good and results in better code.\n\nThis is similar for gcc.target/i386/pr52252-atom.c where interleaving\ngenerates much better code than hybrid SLP.  I'm unsure how to update\nthe testcase though.\n\ngcc.dg/vect/slp-21.c runs into similar situations.  Note that when\nwhen analyzing SLP operations we discard an instance we currently\nforce the full loop to have no SLP because hybrid detection is\nbroken.  It's probably not worth fixing this at this moment.\n\nFor gcc.dg/vect/pr97428.c we are not splitting the 16 store group\ninto two but merge the two 8 lane loads into one before doing the\nstore and thus have only a single SLP instance.  A similar situation\nhappens in gcc.dg/vect/slp-11c.c but the branches feeding the\nsingle SLP store only have a single lane.  Likewise for\ngcc.dg/vect/vect-complex-5.c and gcc.dg/vect/vect-gather-2.c.\n\ngcc.dg/vect/slp-cond-1.c has an additional SLP vectorization\nwith a SLP store group of size two but two single-lane branches.\n\n\t* tree-vect-slp.cc (vect_build_slp_instance): Do not split\n\tstore dataref groups on loop SLP discovery failure but create\n\ta single SLP instance for the stores but branch to SLP sub-trees\n\tand merge with a series of VEC_PERM nodes.\n\n\t* gcc.dg/vect/pr97428.c: Expect a single store SLP group.\n\t* gcc.dg/vect/slp-11c.c: Likewise, if !vect_load_lanes.\n\t* gcc.dg/vect/vect-complex-5.c: Likewise.\n\t* gcc.dg/vect/slp-12a.c: Do not expect SLP.\n\t* gcc.dg/vect/slp-21.c: Remove not important scanning for SLP.\n\t* gcc.dg/vect/slp-cond-1.c: Expect one more SLP if !vect_load_lanes.\n\t* gcc.dg/vect/vect-gather-2.c: Expect SLP to be used.\n\t* gcc.target/i386/pr52252-atom.c: XFAIL test for palignr.","shortMessageHtmlLink":"Avoid splitting store dataref groups during SLP discovery"}},{"before":"1a6c1c85b7ab1ad4bdf9573fcdc04dcce894ba82","after":"5429e6a6467951e3ffc626e6aa40fb32fcc43681","ref":"refs/heads/releases/gcc-14","pushedAt":"2024-05-24T00:41:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Daily bump.","shortMessageHtmlLink":"Daily bump."}},{"before":"e87c00b0d34359b8696fc4c73e5f08c3d87d4e02","after":"886cb5e9524362c898d6eada8009c282e49ecdfa","ref":"refs/heads/releases/gcc-11","pushedAt":"2024-05-24T00:41:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Daily bump.","shortMessageHtmlLink":"Daily bump."}},{"before":"df191554a59364da04c169dd02e44368ca1811ca","after":"a1ff3171c3b8d1d13e241fde28a84ae11c10bd87","ref":"refs/heads/releases/gcc-12","pushedAt":"2024-05-24T00:41:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Daily bump.","shortMessageHtmlLink":"Daily bump."}},{"before":"6f8933ce3fa83482b62d1b6e50d2a8f36addf73e","after":"cf76815d93f065a48c06963b396e2d543e75b7a3","ref":"refs/heads/releases/gcc-13","pushedAt":"2024-05-24T00:41:42.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"hubot","name":"Hubot","path":"/hubot","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/480938?s=80&v=4"},"commit":{"message":"Daily bump.","shortMessageHtmlLink":"Daily bump."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEUznyXAA","startCursor":null,"endCursor":null}},"title":"Activity · gcc-mirror/gcc"}