https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95316
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC| |jakub at gcc dot gnu.org,
| |tschwinge at gcc dot gnu.org
Last reconfirmed| |2020-05-26
Summary|[10 Regression] binary |Offload compilation fails
|built with -fopenacc fails |when not all offload
|to run when not all offload |compilers are installed
|compilers are installed |that were configured
|that were configured |
--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
So the report is not "binary built with -fopenacc fails to run when [...]" but
rather "compilation with -fopenacc fails when [...]"? And, same for '-fopenmp'
for OpenMP 'target' offloading? So I'm changing the Summary to: "Offload
compilation fails when [...]". (Please adjust if I've misunderstood.)
I don't think this is a regression: wouldn't you've gotten the same behavior
already before GCC 10 added GCN offloading, for example, when you had built GCC
with '--enable-offload-targets=nvptx-none' but then didn't have the nvptx
offloading compiler installed? I'm thus removing the "regression" tag.
(Please put it back if I've misunderstood.)
I agree that the current driver (?) behavior is not ideal. I suppose the
default offload targets configuration (unless overridden by '-foffload') should
be made so that if an offload compiler is not present, it is silently skipped.
That is, without printing a warning (as has been suggested), as that would
produce a lot of noise. If an offload target has been explicitly requested via
'-foffload=[target]', then that should result in a hard error, of course, if
the respective offload compiler is not available.
