public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ams at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"
Date: Wed, 21 Jul 2021 10:03:32 +0000	[thread overview]
Message-ID: <bug-101544-4-En5bTu6jaF@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-101544-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from Andrew Stubbs <ams at gcc dot gnu.org> ---
[Note: all of my comments refer to the amdgcn case. nvptx has somewhat
different support in this area.]

(In reply to Jonathan Wakely from comment #4)
> But it's a waste of space in the .so to build lots of symbols that use the
> stubs.

DSOs are not supported. This is strictly for static linking only.

> There are other reasons it might be nice to be able to configure libstdc++
> for something in between a full hosted environment and a minimal
> freestanding one.

If it isn't a horrible hack, like libgfortran minimal mode, then fine.

> > I believe static constructors work (libgfortran uses some), but exception
> > handling does not. I'm not sure what other exotica C++ might need?
> 
> Ideally, __cxa_atexit and __cxa_thread_atexit for static and thread-local
> destructors, but we can survive without them (and have not-fully-conforming
> destruction ordering).

Offload kernels are just fragments of programs, so this is tricky in those
cases. Libgomp explicitly calls _init_array and _fini_array as single-threaded
kernel launches. Actually, it's not clear that deconstruction is in any way
interesting, given that code running on the GPU has no external access and the
resources are all released when the host program exits.

Similarly, C++ threads are not interesting in the GPU-offload case. There are a
fixed number or threads launched on entry and they are managed by libgomp. In
theory it would be possible to code gthreads/libstdc++ to use them in
standalone mode, but really that mode only exists to facilitate compiler
testing.

  parent reply	other threads:[~2021-07-21 10:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  6:40 [Bug c++/101544] New: [OpenMP] 'declare target' block around class – " burnus at gcc dot gnu.org
2021-07-21  7:58 ` [Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: " burnus at gcc dot gnu.org
2021-07-21  8:05 ` jakub at gcc dot gnu.org
2021-07-21  9:06 ` ams at gcc dot gnu.org
2021-07-21  9:33 ` redi at gcc dot gnu.org
2021-07-21 10:03 ` ams at gcc dot gnu.org [this message]
2021-07-21 13:27 ` rguenth at gcc dot gnu.org
2021-07-21 13:37 ` redi at gcc dot gnu.org
2021-07-26 12:01 ` tschwinge at gcc dot gnu.org
2022-07-22 13:32 ` tschwinge at gcc dot gnu.org
2022-07-22 14:04 ` tschwinge at gcc dot gnu.org
2022-07-25 11:20 ` rguenth at gcc dot gnu.org
2023-06-01 19:27 ` tschwinge at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-101544-4-En5bTu6jaF@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).