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.
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
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
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.
Thanks,
--
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/
