[Bug libgomp/81886] New: Means to determine at runtime foffload targets specified at compile time

["vries at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81886

            Bug ID: 81886
           Summary: Means to determine at runtime foffload targets
                    specified at compile time
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02670.html :
...
<SNIP> currently, the whole offload machinery will not be
run unless we actually have any offloaded data.  This means that the
configured mkoffload programs (-foffload=[...], defaulting to
configure-time --enable-offload-targets=[...]) will not be invoked unless
we actually have any offloaded data.  This means that we will not
actually generate constructor code to call libgomp's
GOMP_offload_register unless we actually have any offloaded data.  At
runtime, in libgomp, we then cannot reliably tell which -foffload=[...]
targets have been specified during compilation.

But: at runtime, I'd like to know which -foffload=[...] targets have been
specified during compilation, so that we can, for example, reliably
resort to host fallback execution for -foffload=disable instead of
getting error message that an offloaded function is missing.  On the
other hand, for example, for -foffload=nvptx-none, even if user program
code doesn't contain any offloaded data (and thus the offload machinery
has not been run), the user program might still contain any executable
directives or OpenACC runtime library calls, so we'd still like to use
the libgomp nvptx plugin.  However, we currently cannot detect this
situation.
...