On Fri, Oct 9, 2026 at 2:16 PM Christopher Bazley <[email protected]> wrote: > > On 09/10/2026 09:31, Richard Biener wrote: > > On Mon, Oct 5, 2026 at 3:29 PM Christopher Bazley <[email protected]> > > wrote: > >> > >> Gentle ping. We'd really like to get this in before the end of stage 1. > > > > The series doesn't git am anymore and I cannot figure out which GCC > > rev it was based on. > > Sorry about that. The cover letter says 'Based on commit d6bac80f3dd'. > On my machine, git branch -r --contains d6bac80f3dd tells me that commit > is indeed in upstream trunk.
Oops, not sure how I failed to see that. > > Can you re-base please (or tell me a revision it ams on?) > > I have started to rebase the patch series. So far, I see conflicts with > 5dde4aa27ecf, your fix for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127195 (which I already > fixed independently as part of my patch series), and with your other > commit d528b3e5314fde, 'Make vect_build_slp_tree_1 compute a set of > matches[]'. I don't yet know how many other conflicts might come to light. > > I believe I approved parts of the series already, but I see no indication > > which patches were already fully reviewed/acked which causes extra > > work for me. Please indicate this appropriately. Maybe add > > some acked-by attribution or at _least_ in the cover letter mark > > patches that are approved (and whether they had any changes > > after being approved). > > Based on your comment 'This looks independent enough and is OK to push > separately' in > https://gcc.gnu.org/pipermail/gcc-patches/2026-June/721406.html > I will push '[PATCH v15 08/19] vect: Fix vectorizable_live_operation for > BB SLP with a VLA type' upstream: > https://gcc.gnu.org/pipermail/gcc-patches/2026-September/732114.html Thanks. > I will also record approvals in the next revision, but as far as I can > tell, there is only one other candidate for that: you wrote 'consider > 1/n approved, but as-is it has to stay part of the series' in > https://gcc.gnu.org/pipermail/gcc-patches/2026-September/730416.html OK, as said, I didn't exactly remember. > But the approved v14 version of that patch (01/19) added an optional > slp_tree parameter to the mask/length interfaces, whereas the v15 > version (03/19) adds an optional unsigned int parameter in which to pass > the active lane count, with corresponding changes to its assertions and > documentation. > > I therefore assume it needs re-approval. Hmm, yes. Again sorry this takes so long. Richard. > > Thanks, > -- > Christopher Bazley > Staff Software Engineer, GNU Tools Team. > Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK. > http://www.arm.com/
