From: Jonathan Wakely <jwakely@redhat.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: libstdc++@gcc.gnu.org
Subject: Re: libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/tinfo.cc'
Date: Thu, 14 Jul 2022 19:39:40 +0100 [thread overview]
Message-ID: <CACb0b4nE4UnAXTaGMci_zFD75o-8x9YNve6iY_yQVD-=T=idwQ@mail.gmail.com> (raw)
In-Reply-To: <875yjzfxxg.fsf@euler.schwinge.homeip.net>
On Thu, 14 Jul 2022 at 19:14, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> 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).
That's only there for backwards compatibility on ARM EABI and other
targets that don't define __GXX_TYPEINFO_EQUALITY_INLINE==1.
My suggestion would be to define that macro for the target.
>
> 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?
Again, is -fno-rtti globally true for all code for this target? Not
just while building libstdc++?
If the answer is yes, then you don't need the symbols in this file.
next prev parent reply other threads:[~2022-07-14 18:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 16:42 Thomas Schwinge
2022-07-14 18:39 ` Jonathan Wakely [this message]
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='CACb0b4nE4UnAXTaGMci_zFD75o-8x9YNve6iY_yQVD-=T=idwQ@mail.gmail.com' \
--to=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
--cc=thomas@codesourcery.com \
/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).