On Fri, 30 Jun 2023 at 09:42, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Fri, 30 Jun 2023 at 04:48, Hans-Peter Nilsson wrote: > > > > > Date: Mon, 26 Jun 2023 11:57:49 -0700 > > > From: Thomas Rodgers via Gcc-patches <gcc-patches@gcc.gnu.org> > > > > > On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely <jwak...@redhat.com> > > > wrote: > > > > All the actual code changes look good. > > > > Unfortunately, this overwrote the fix for PR108672. I take > > it there's a step missing from the synchronization process; > > a check that no local commits are overwritten? Sounds like > > something that can be fully scripted (not volunteering) or > > already available (like, "list all commits affecting > > contents touched by/between two named commits"). > > > > I did *not* check whether any other local commits were also > > overwritten. Also, not sure about whether better try to get > > this upstreamed: __INT32_TYPE__ seems gcc-specific. > > Clang does support it too, but I agree that upstream might not want that > change. > > > > Anyway, r13-5702-g72058eea9d407e was "re-committed" per > > below as obvious after regtesting cris-elf. > > Thanks. > > I'll add an include/pstl/LOCAL_PATCHES file listed the commits we > apply locally after importing the upstream sources. > > Based on git history, the initial list of commits is:
For the record: > r9-6908-g0360f9ad4048ea Upstream: c7c6413119380828d92e8beb5fb2f35d3f2e1572 > r9-6942-g9eda9f9231f287 Upstream: 2e15f4ac572bcf429ec12e8f3efbb8ad254042c7 > r9-7071-ga34d6343a758f6 Upstream: 8a497a958be1f4656eff9664e1be29491f3795d2 and 86d4ec756b5e0bc72d7e78fc574e05802959ead4 > r10-572-g34d878c7bc86d4 Not upstream (GCC-specific). > r10-1314-g32bab8b6ad0a90 Not upstream (probably should be) > r11-7339-g7e647d71d556b7 Upstream: b152f9f392d42e1c8e29f382f876480631575190 > r12-7699-gac73c944eac88f Not upstream (GCC-specific) > r13-3708-ge3b10249119fb4 Not upstream (GCC-specific) > r13-5702-g72058eea9d407e Not upstream (GCC-specific) > > But several of those have been incorporated upstream, or were > reapplied correctly to our downstream copies. We'll go through the > list and find which ones need to stay there. > > It looks like r10-1314-g32bab8b6ad0a90 was lost and should be re-applied.
