[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

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

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

--- Comment #9 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
One concrete question, on example of:

(In reply to myself from comment #8)
> hard-code '-foffload-options=nvptx-none=-mptx=6.3\ -malias' to work around GCC PR105018 "[nvptx] Need better alias support"

... this.

Simplified, the GCC/nvptx back end currently doesn't support symbol aliases.

Now, I found that there is a misconfiguration in the GCC/nvptx back end, so
that GCC proper thinks that it actually does support these even if the
experimental/limited support is disabled (details to be shared later).  This
means: with that GCC/nvptx back end misconfiguration fixed, I get libsupc++
built, and the GCC/C++ front end for nvptx target (real target, not offload
target!) works fine with the '!TARGET_SUPPORTS_ALIASES' configuration (just
like for other "embedded" targets, etc., I suppose).  For example, see
'gcc/cp/optimize.cc:can_alias_cdtor':

    /* Returns true iff we can make the base and complete [cd]tor aliases of
       the same symbol rather than separate functions.  */

    static bool
    can_alias_cdtor (tree fn)
    {
      /* If aliases aren't supported by the assembler, fail.  */
      if (!TARGET_SUPPORTS_ALIASES)
        return false;
    [...]

That's fine for GCC/C++ for nvptx target.  However, in a nvptx offload
configuration, the GCC/C++ front end runs on the host (x86_64-pc-linux-gnu or
whatever), and thus has a 'TARGET_SUPPORTS_ALIASES' configuration, and GCC/C++
front end happily generates symbol aliases -- which the nvptx offload
compilation then later falls over.

This problem (and I suspect a few other similar ones) could be avoided if the
GCC/C++ front end didn't look up target properties (such as
'TARGET_SUPPORTS_ALIASES'), and instead left such things in some "defer" state,
and they get resolved/lowered per actual target properties once the offloading
code stream has been spawned off.  (We've similarly changed a few other items,
where the lowering was "too early", as far as I remember.)  At that point then,
the host would decide for 'TARGET_SUPPORTS_ALIASES', and the nvptx offload
target would decide for '!TARGET_SUPPORTS_ALIASES', and lower the "defer"
construct as appropriate.  This of course is more difficult if the target
property causes more compilcated decisions in the GCC/C++ front end.

But, generally (and of course I understand it eventually has to be decided case
by case), is it acceptable to defer such early target property lookup until
later?  Of course, next problem then is potential missed optimizations due to
later lowering, diagnostics changes, and all these things, uh...

(Like, poison all "early" target macro etc. usage, and then selectively
re-enable when appropriate (data types have to match between host and offload
targets, etc.), and otherwise adjust code to resolve "late".  Sounds like a fun
multi-year project, doesn't it...)

Thoughts, on this specific example as well as generally?