From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C0A593858D37 for ; Thu, 14 Jul 2022 18:39:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0A593858D37 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-661-TQV251KzP6ifC9VC82mR8A-1; Thu, 14 Jul 2022 14:39:52 -0400 X-MC-Unique: TQV251KzP6ifC9VC82mR8A-1 Received: by mail-qt1-f198.google.com with SMTP id bb14-20020a05622a1b0e00b0031eb88da7d0so2117021qtb.3 for ; Thu, 14 Jul 2022 11:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RcW9k/jvmaB+OeGzvk/yVVGRtDOo/X88C9UhDFm/la8=; b=Qx1vid7ClLWEMfrI5l8leG77xKEl7RT55tjTsLqALKyfeuOEUA4a/ad0U9jb5FT9OG VJsKzm/oG4TbpwP7Ev4pk5UFTdxnM2lgJtmhfObuRp/PDwW5kh/Pxdvf7RXB+8D1g51V bZ1dRZGpk4+6kQBzDozdHoozqzi9ZnEFUMY1J83Zd5nT/MHeeoe2i2g51enrPw/LpT6H pApdPz/gl4RdN2E8xKUQ88RnwnKtLbWvpP83BYS3t/ZMT4rxnSzHsgwK3oGwRG6FUPD/ axCOqytP3VIw5cAsSihn9chz3KpgdKztMxUubBPAtTuoo2iPaZb8mehDmQS919QcbAnR C/+g== X-Gm-Message-State: AJIora/xk/KmZQex7cPls99l+i9hpHTHzc1R+kiLGyYm/6/WYhFpbkdd qAjh8ddgm9rroO2QtETA69+Lq8kDgI8p2CidMjeREFxVk777SOX8zpjD/fYzje5F8oVeldPafjt Y2IrYcy/llt9kJN8oodMqJTAywLXCFAg= X-Received: by 2002:a05:620a:4514:b0:6af:25f2:489d with SMTP id t20-20020a05620a451400b006af25f2489dmr6815347qkp.728.1657823991611; Thu, 14 Jul 2022 11:39:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uAVizwe0Vb9pGQZCD3q/Mlc0bVhHNM2MWn9S9v4IspnIcR+MiwTYgbYUflFO1LzbFw/QIHtcEJoAMknrBZlUc= X-Received: by 2002:a05:620a:4514:b0:6af:25f2:489d with SMTP id t20-20020a05620a451400b006af25f2489dmr6815333qkp.728.1657823991356; Thu, 14 Jul 2022 11:39:51 -0700 (PDT) MIME-Version: 1.0 References: <875yjzfxxg.fsf@euler.schwinge.homeip.net> In-Reply-To: <875yjzfxxg.fsf@euler.schwinge.homeip.net> From: Jonathan Wakely Date: Thu, 14 Jul 2022 19:39:40 +0100 Message-ID: Subject: Re: libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/tinfo.cc' To: Thomas Schwinge Cc: libstdc++@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2022 18:39:55 -0000 On Thu, 14 Jul 2022 at 19:14, Thomas Schwinge wrote: > > Hi! > > In context of '[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" > ( > -- 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.