Vulkan backend: Add missing include of algorithm

[xuyanwen2012]

Problem

backends/vulkan/runtime/graph/containers/SharedObject.cpp and
backends/vulkan/runtime/graph/ops/impl/Squeeze.cpp call std::find
(and Squeeze.cpp also std::rotate) without including <algorithm>.
This compiled previously because the declarations leaked in
transitively through other headers, but GCC 15's libstdc++ header
reorganization removed that transitive path, breaking the build with:

error: no matching function for call to 'find(...)'
note: candidate 1: ... std::find(istreambuf_iterator<...>, ...)

The remaining candidate is a narrow istreambuf_iterator-only overload
pulled in via an unrelated header (<sstream>/<ostream> chain), not
the generic <algorithm> overload these call sites actually need.

This is the same class of issue as #15220 (missing <cstdint> include
in the Vulkan backend) and relates to the GCC 15 CI build failures
that led to disabling executorch-ubuntu-26.04-gcc15 in favor of
gcc14 (#20304, tracked in #19917).

Fix

Add #include <algorithm> to both files, matching the precedent set
in backends/vulkan/runtime/utils/StorageUtils.h (#15220).

Test Plan

Built the vulkan_backend CMake target with GCC 15 (gcc (Ubuntu 15.x)), which fails to compile on main today with the errors above.
With this fix, cmake --build cmake-out --target vulkan_backend
completes cleanly. Swept the rest of backends/vulkan/runtime for the
same pattern (std::find/sort/rotate/etc. without <algorithm>)
and found no other occurrences outside these two files.

cc @SS-JIA @manuelcandales @digantdesai @cbilgin

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22422

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 15 Awaiting Approval

As of commit 645ccbe with merge base 448fbfe ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build documentation (gh)
• Build Presets (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test Cortex-M Backend (gh)
• Test NXP Backend (gh)
• Test QNN Backend (gh)
• Test QNN Windows MSVC build (gh)
• Test Vulkan Backend (gh)
• Test Vulkan Backend (specialized runners) (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[linux-foundation-easycla]

• ✅ Unknown (645ccbe)
• ❌ - login: @xuyanwen2012 / name: Yanwen Xu. The commit (645ccbe) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please visit our EasyCLA portal and chat with our support bot.

One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via:

Co-authored-by: name <email>

Supported Co-authored-by: formats include:

1. Anything <id+login@users.noreply.github.com> - it will locate your GitHub user by id part.
2. Anything <login@users.noreply.github.com> - it will locate your GitHub user by login part.
3. Anything <public-email> - it will locate your GitHub user by public-email part. Note that this email must be made public on Github.
4. Anything <other-email> - it will locate your GitHub user by other-email part but only if that email was used before for any other CLA as a main commit author.
5. login <any-valid-email> - it will locate your GitHub user by login part, note that login part must be at least 3 characters long.

Alternatively, if the co-author should not be included, remove the Co-authored-by: line from the commit message.

Please update your commit message(s) by doing git commit --amend and then git push [--force] and then request re-running CLA check via commenting on this pull request:

/easycla

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[Copilot]

🟢 Approval recommended

The changes are minimal, localized, and correctly add missing standard library includes required by the existing code paths.

Pull request overview

This PR fixes a GCC 15 build break in the Vulkan backend by making <algorithm> an explicit dependency in the two .cpp translation units that use std::find (and std::rotate), avoiding reliance on transitive standard library includes.

Changes:

• Add #include <algorithm> to Squeeze.cpp to cover std::find / std::rotate.
• Add #include <algorithm> to SharedObject.cpp to cover std::find.

File summaries

File	Description
backends/vulkan/runtime/graph/ops/impl/Squeeze.cpp	Adds <algorithm> include for std::find/std::rotate used in the implementation.
backends/vulkan/runtime/graph/containers/SharedObject.cpp	Adds <algorithm> include for std::find used in SharedObject::has_user.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xuyanwen2012]

Additional data point: this isn't strictly GCC-15-specific. Reproduced the identical build failure on a second, unrelated machine running Rocky Linux 10.2 with GCC 14.3.1 (Red Hat 14.3.1-4):

backends/vulkan/runtime/graph/containers/SharedObject.cpp:16:19: error: no matching function for call to 'find(std::vector<int>::const_iterator, std::vector<int>::const_iterator, const vkcompute::ValueRef&)'

Same root cause, same fix (adding #include <algorithm>) resolves it there too. So this is a case of code that was already relying on fragile transitive includes — GCC 15's libstdc++ reorganization is what surfaced it originally, but at least one downstream libstdc++ packaging (Red Hat's GCC 14 build) exposes the same gap. Worth keeping in mind that this class of fix is protecting against more than just the GCC 15 CI image.