From: Thomas Schwinge <thomas@codesourcery.com>
To: <libstdc++@gcc.gnu.org>, Jonathan Wakely <jwakely@redhat.com>
Subject: libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/tinfo.cc'
Date: Thu, 14 Jul 2022 18:42:35 +0200 [thread overview]
Message-ID: <875yjzfxxg.fsf@euler.schwinge.homeip.net> (raw)
Hi!
In context of <https://gcc.gnu.org/PR101544> '[OpenMP][AMDGCN][nvptx]
C++ offloading: unresolved _Znwm = "operator new(unsigned long)"'
I'm looking into building GCN, nvptx offloading libstdc++ "freestanding"
('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions'.
(I've basically got these things wired up; details to be shared later.)
While there is some experimental/incomplete/not-to-be-relied-on support
for PTX symbol aliases, we're currently generally running into
"error: alias definitions not supported in this configuration"
for certain GCC/C++-front-end-generated code, for example:
"complete object destructor" aliasing "base object destructor"
(<https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-special-ctor-dtor>
-- per my understanding, at least). ;-)
It'll ultimately be possible to implement more complete symbol aliasing
support for nvptx, but I found that this specific issue actually is due
to a nvptx back end mis-configuration; fixed with adequate
'TARGET_USE_LOCAL_THUNK_ALIAS_P' and/or 'TARGET_SUPPORTS_ALIASES'
definitions (details to be shared later).
However, we then still run into:
[...]/libstdc++-v3/libsupc++/tinfo.cc:55:1: error: alias definitions not supported in this configuration
55 | std::type_info::__equal (const std::type_info& arg) const _GLIBCXX_NOEXCEPT
| ^~~
make[4]: *** [Makefile:777: tinfo.lo] Error 1
That's 'libstdc++-v3/libsupc++/tinfo.cc':
1 // Methods for type_info for -*- C++ -*- Run Time Type Identification.
[...]
39 // We can't rely on common symbols being shared between shared objects.
40 bool std::type_info::
41 operator== (const std::type_info& arg) const _GLIBCXX_NOEXCEPT
42 {
43 #if __GXX_MERGED_TYPEINFO_NAMES
44 return name () == arg.name ();
45 #else
46 /* The name() method will strip any leading '*' prefix. Therefore
47 take care to look at __name rather than name() when looking for
48 the "pointer" prefix. */
49 return (&arg == this)
50 || (__name[0] != '*' && (__builtin_strcmp (name (), arg.name ()) == 0));
51 #endif
52 }
53
54 bool
55 std::type_info::__equal (const std::type_info& arg) const _GLIBCXX_NOEXCEPT
56 __attribute__((alias("_ZNKSt9type_infoeqERKS_")));
57 #endif
[...]
..., so there's a manual alias from the line 55 function to the line 41
function (if I got that right).
Now we may surely address that in some different way, but I do wonder if
we need this whole file at all, given this is
"Methods for type_info for -*- C++ -*- Run Time Type Identification",
RTTI, and we're generally assuming '-fno-rtti'? Do certain things simply
need to be '#if'-conditionalized, or similar, for example? I've not yet
looked into the details; hoping that's maybe easy for you to answer?
Grüße
Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
next reply other threads:[~2022-07-14 18:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 16:42 Thomas Schwinge [this message]
2022-07-14 18:39 ` Jonathan Wakely
2023-11-06 14:57 ` nvptx: Use the usual '#define MAKE_DECL_ONE_ONLY(DECL) (DECL_WEAK (DECL) = 1)' (was: libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/tinfo.cc') Thomas Schwinge
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=875yjzfxxg.fsf@euler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=jwakely@redhat.com \
--cc=libstdc++@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).