Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

561847 Variable copied when it could be moved in kernel.cpp

Aperta Adatta ai principianti
  • Qualcosa non va?
#23,463 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
backend

Direzione di ricerca

Inizia dall'istruzione return in sycl/source/kernel.cpp, intorno alle righe 246-256, dove Queue viene passato per valore a impl->queryMaxNumWorkGroups. Le altre tre chiamate in sycl/source/detail/kernel_impl.hpp (intorno alle righe 422-444) avvolgono già la coda in std::move, quindi la correzione consiste nell'allinearsi a loro. È completato quando quella chiamata usa std::move(Queue) e la build SYCL e i test esistenti continuano a passare. Il refactoring dei parametri del dispositivo descritto nella issue è facoltativo e più ampio.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug Coverity
Describe the bug
250  impl->getAdapter().call_nocheck<sycl::detail::UrApiKind::urKernelSetExecInfo>(
251      impl->getHandleRef(), UR_KERNEL_EXEC_INFO_CACHE_CONFIG,
252      sizeof(ur_kernel_cache_config_t), nullptr, &(ExecInfo.CacheConfig));
253  sycl::queue Queue{Dev};
254  return impl->queryMaxNumWorkGroups<Dimensions>(

CID 561847: (#undefined of undefined): Variable copied when it could be moved (COPY_INSTEAD_OF_MOVE)
copy_constructor_call: Queue is passed-by-value as parameter to queryMaxNumWorkGroups, when it could be moved instead.[show details]
     	Use std::move(Queue) instead of Queue.

https://github.com/intel/llvm/blob/43d56c72d78f51a24fc25fec4ba4bd295dcb9925/sycl/source/kernel.cpp#L246-L256

To reproduce

Static analysis finding, reported by the Coverity Scan build of intel/llvm. No
runtime reproducer — the effect is a redundant refcount operation, not incorrect
behaviour.

Environment

N/A — static analysis finding, backend independent.

Additional context

The finding is valid. kernel_impl::queryMaxNumWorkGroups
takes its queue by value, and Queue is a local whose last use is this call —
the call is the return statement. So the copy constructor runs for nothing:
an atomic increment on the shared_ptr<queue_impl> plus the matching decrement
when Queue goes out of scope.

The three other call sites of the same function already use the moving form, at
kernel_impl.hpp:422,
:433
and :444,
where the queue-based ext_oneapi_get_info overloads forward with
std::move(Queue). kernel.cpp:255 is the one site of four that doesn't:

  return impl->queryMaxNumWorkGroups<Dimensions>(
      std::move(Queue), Range, Bytes + ExecInfo.DynamicWorkGroupMem);

There is a larger inefficiency at the same spot, which the one-line fix leaves
in place. The only use of the queue in the callee is
kernel_impl.hpp:383:

  auto Device = Queue.get_device();

Everything afterwards uses only Device, including the
exceedsOccupancyResourceLimits fallback. Meanwhile kernel::queryMaxNumWorkGroups
already has the device — it is the Dev parameter — and line 253 constructs a
full sycl::queue from it just so the callee can unwrap it again. That
construction creates a queue_impl and a backend queue handle, i.e. a
urQueueCreate/urQueueRelease round trip per query call, which is far more
expensive than the copy Coverity flagged. It also gives an informational query a
side effect and an unrelated failure mode, since queue construction can throw for
reasons that have nothing to do with the query.

A cleaner fix would be to change kernel_impl::queryMaxNumWorkGroups to take a
const device & and have the three queue-based callers pass
Queue.get_device(), which removes the synthetic queue entirely and makes the
copy question moot. That is ABI-safe: the function is a template defined in a
detail header with no explicit instantiations of its own, so only internal
callers change and the exported instantiations of
kernel::queryMaxNumWorkGroups keep their signatures.

Either fix resolves the CID; the second also removes the queue construction.

AI (Claude Code): the finding is from the Coverity scan; the analysis and suggested fixes above are the agent's.

Lingua principale
LLVM
Stelle
1.5k
Fork
873
Merge medio
3g 6h
PR unite (30g)
204

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di intel/llvm

Tutte le issue di intel/llvm

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.