public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
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.


  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).