Conversation
inferOffloadToolchains re-derived whether the new offloading driver was enabled by re-checking '--offload-new-driver' directly, instead of using getUseNewOffloadingDriver(), which is already the single source of truth (see BuildCompilation). This meant the diagnostic could incorrectly fire for '-fsycl --offload-arch=...' combined with another offload kind (e.g. OpenMP) that implicitly enables the new driver in the same invocation. Move the OpenMP/explicit-flag part of the default before inferOffloadToolchains(), which also consults getUseNewOffloadingDriver(). Keep the CUDA/HIP part of the default gated on C.isOffloadingHostKind() after toolchains are actually built, so an invalid --offload-arch/--cuda-gpu-arch (which leaves no device toolchain) doesn't spuriously enable the new driver and crash later in BuildOffloadingActions (in test Driver/cuda-options.cu). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Changes look OK - but curious about this comment in the description:
so an invalid --offload-arch/--cuda-gpu-arch (which leaves no device toolchain) doesn't spuriously enable the new driver and crash later in BuildOffloadingActions.
Why would passing --offload-arch spuriously enable the new driver?
Thanks, updated the commit message. |
2 participants
inferOffloadToolchains re-derived whether the new offloading driver was enabled by re-checking '--offload-new-driver' directly, instead of using getUseNewOffloadingDriver(), which is already the single source of truth (see BuildCompilation). This meant the diagnostic could incorrectly fire for '-fsycl --offload-arch=...' combined with another offload kind (e.g. OpenMP) that implicitly enables the new driver in the same invocation.
Move the OpenMP/explicit-flag default ahead of inferOffloadToolchains(),
since it also consults getUseNewOffloadingDriver(). Leave the CUDA/HIP
default gated on C.isOffloadingHostKind() after toolchains are built -
that flag only goes true once a valid device toolchain exists, unlike an
earlier input-kind check, which would stay true even with an invalid
--offload-arch/--cuda-gpu-arch and cause a later crash in
BuildOffloadingActions (see Driver/cuda-options.cu).