[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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #8 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
I looked into this, with the goal of estimating the effort necessary for what
you might call "GPU support for minimal C++ library".  That is, allow use of
standard C++ for host code (in particular, no '-fno-exceptions' required for
host code, etc.), and in offloaded regions support a "reasonable subset of C++"
(not exactly defined at this time).

For my experimenting, I default GCN, nvptx to '-fno-rtti', '-fno-exceptions',
address a few bugs and offload target misconfigurations, small libsupc++
changes, configure GCN, nvptx libstdc++ "freestanding" (manually specifying
'--disable-hosted-libstdcxx'; thus just 'libsupc++.a'), hard-code
'-foffload-options=nvptx-none=-mptx=6.3\ -malias' to work around GCC PR105018
"[nvptx] Need better alias support", and with some more manual hand-holding
etc., I do have the code working that originated this issue, which uses C++
'new' in OpenMP 'target'.  (Yay.)  Resolving all these things properly, I'm
estimating to easily turn into a multi-week effort -- but hey, it's C++, so... 
;-)

---

However...  As soon as you start doing a little bit more C++ in offloaded
regions (like, defining a simple 'std::vector<int> v(100);', how dare you...),
it becomes apparent that the configuration mismatch between host and offload
targets is problematic: GCC/C++ synthesizes/emits constructs that the offload
targets are not prepared for, leading to a good mixture ICEs, 'sorry's,
undefined symbols.  While certainly there are genuine bugs to be addressed, I'm
not convinced anymore that such a setup is going to work easily.

Building full libstdc++ for the offload targets runs into similar ICEs,
'sorry's, still with default '-fno-rtti', '-fno-exceptions'.  We'd need to
resolve these issues, by improving the offload target back ends etc., and/or
GCC/C++ front end down to libstdc++, as appropriate.  This sounds doable, but
not trivial, but we'd still have the issue of, for example, mismatching
'-fexceptions' in host code (thus, exceptions codes may appear in the
offloading code stream), and '-fno-exceptions' configuration for offload
targets.

I'm toying with the idea of looking into "sanitizing" the offloading code
stream (easly pass in offload compilation pipeline), so that it's more
"amenable" for offload compilation, but again I don't know whether that's going
to work out, and how much effort that requires.

---

So, this is just a brain-dump, to report where we are, and/or in case anyone
has any great ideas.  :-)