From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 5198A3858D1E for ; Thu, 14 Jul 2022 18:18:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5198A3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.92,272,1650960000"; d="scan'208";a="79763740" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 14 Jul 2022 08:42:44 -0800 IronPort-SDR: 3QOE9gHGObeij7VkTUHRrzpmGms/heQhKWixvs0p4GqBMe96xb+JJzI4uvmHMsu/cuog5GXZk7 DpR2fOCW/dc252zN6TNSMJDb+t6t4g2Tpt/AA6b5SkhlpwWDgVV8pZppsEBT6Gf9cIMJg17o5u X/74mVK9m7oI8ssl/5DQ6uO282CRegw03Yn7QdZEp9hf+mjqrAvlxLeEf20pAcsvWruBJWAJcX r16xcY1OTFIbgis/ES6MTGXyun7a8LKPPI6OiobpafZeZhHf3hM3wqMJe0jxiaRb3ZwjcuK2iO 3jY= From: Thomas Schwinge To: , Jonathan Wakely Subject: libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/tinfo.cc' User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Thu, 14 Jul 2022 18:42:35 +0200 Message-ID: <875yjzfxxg.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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:18:51 -0000 Hi! In context of '[OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm =3D "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 no= t supported in this configuration 55 | std::type_info::__equal (const std::type_info& arg) const _GLIB= CXX_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 Identificatio= n. [...] 39 // We can't rely on common symbols being shared between shared objec= ts. 40 bool std::type_info:: 41 operator=3D=3D (const std::type_info& arg) const _GLIBCXX_NOEXCEPT 42 { 43 #if __GXX_MERGED_TYPEINFO_NAMES 44 return name () =3D=3D 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 =3D=3D this) 50 || (__name[0] !=3D '*' && (__builtin_strcmp (name (), arg.name (= )) =3D=3D 0)); 51 #endif 52 } 53 54 bool 55 std::type_info::__equal (const std::type_info& arg) const _GLIBCXX_N= OEXCEPT 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=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955