From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GBOfEg0TIWYcqDMAWB0awg (envelope-from ) for ; Thu, 18 Apr 2024 08:33:17 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=oDckURyR; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4862F1E0C0; Thu, 18 Apr 2024 08:33:17 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 369551E092 for ; Thu, 18 Apr 2024 08:33:15 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CF1063870863 for ; Thu, 18 Apr 2024 12:33:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CF1063870863 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1713443594; bh=q7JD37jMULbmptVJ9U7zVFpz7q16yDRXT7mXbsqx0oc=; h=Subject:To:CC:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=oDckURyRWEeGvptZ0yQzgprPur6v6SVcfIIVMJXmlwln4v1IARE5Tib+NZy2MoEhf fQbrW7ha0x0MwykAESOG/oc/egA4uf7Pl90c1JHnI7hY1IWp8b0Ee4y+Qe+G4zwI0o uIdOCPaSRjjIaZVPFVXd9901hpZTwlpP2codFqek= Received: from mx-2023-1.gwdg.de (mx-2023-1.gwdg.de [134.76.10.21]) by sourceware.org (Postfix) with ESMTPS id D0C4A3858D33; Thu, 18 Apr 2024 12:32:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0C4A3858D33 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D0C4A3858D33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713443546; cv=none; b=iScQ13OyWD7LHy+aMwL+c0VlGjZOonxR6SJ75v4a5iwntaRPqiDtWWZEIUvENp3x0BDGm7cTfSpdjKCag241e6RXtbB2+yXkKhwL2TsWbrzL5Fky+TTNUV9d8q5b2uHyQaxyVw52dGCvnbPJxWOcnd/duvgJ0kAicqwingXKb8A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713443546; c=relaxed/simple; bh=uIhKYE3fOGb3tIFChy2ezUUmC7x9R6wvk55KWj3Dyfg=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=DkuAln0dPyHUpWNnYgDss8QdEO5cCbKEtJtGBDM6obHwMuSAzcd9k2S5M9kZEd6LUsqjXIRL0fsqh4kQjozFY+1+UJ105UJ1PlQOAF6tTKUshYxOKdfSgt5L/O7fqdiuql/CsoZ7+5r3TqIDTiF2R1IcvehZLYJqcBBK+jxJx1Q= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from xmailer.gwdg.de ([134.76.10.29]:36738) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1rxQwA-00ApDv-25; Thu, 18 Apr 2024 14:32:22 +0200 Received: from excmbx-29.um.gwdg.de ([134.76.9.204] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1rxQwA-00012D-1p; Thu, 18 Apr 2024 14:32:22 +0200 Received: from fbmtpc21.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.37; Thu, 18 Apr 2024 14:32:22 +0200 Message-ID: <56b27622e866daa5871afa1239866d47f23609dc.camel@gwdg.de> Subject: Re: Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans) To: Tobias Burnus , Janne Blomqvist , FX Coudert CC: Thomas Koenig , Mark Wielaard , , , , , , "fortran@gcc.gnu.org" Date: Thu, 18 Apr 2024 14:32:16 +0200 In-Reply-To: <686fac37-698f-4373-9469-ccabe96e702a@baylibre.com> References: <20240417232725.GC25080@gnu.wildebeest.org> <5bde614c-224f-4ec6-8450-7c0911938cf9@netcologne.de> <4353C519-D023-45B0-A254-C7274B7CFC6F@gmail.com> <686fac37-698f-4373-9469-ccabe96e702a@baylibre.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-16.um.gwdg.de (134.76.9.227) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Martin Uecker via Gdb Reply-To: Martin Uecker Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Am Donnerstag, dem 18.04.2024 um 14:01 +0200 schrieb Tobias Burnus: > Hi Janne, >=20 > Janne Blomqvist wrote: > > back when I was active I did think about this > > issue. IMHO the best of my ideas was to convert these into C++ > > templates. I haven't looked at libgfortran but I didn't find it problematic at all to use C in similar numerical code and this helps with portability.=20 Either I use macros, which I keep short and then do not find inferior to templates (having used C++ for years previously) or=C2=A0 - if there is really a lot of code that needs to be specialized=C2=A0 for a type - simply by using includes: #define matmul_type double #include "matmul_impl.c" Martin >=20 > I think this will work =E2=80=93 but we have to be super careful: >=20 > With C++, there is the problem that we definitely do not want to add=20 > dependency on libstdc++ nor to use some features which require special= =20 > hardware support (like exceptions [always bad], symbol aliases, ...). =E2= =80=94=20 > On some systems, a full C++ support might be not available, like=20 > embedded systems (including some odd embedded OS) or offloading devices. >=20 > The libstdc++ dependency would be detected by linking as we currently=20 > do. For in-language features, we have to ensure the appropriate flags=20 > -fno-exceptions (and probably a few more). And it should be clear what= =20 > language features to use. >=20 > If we do, I think that would surely be an option. >=20 > > What we're essentially doing with the M4 stuff and the > > proposed in-house Python reimplementation is to make up for lack of > > monomorphization in plain old C. Rather than doing some DIY templates, > > switch the implementation language to something which has that feature > > built-in, in this case C++. No need to convert the entire libgfortran > > to C++ if you don't want to, just those objects that are generated > > from the M4 templates. Something like > >=20 > > template > > void matmul(T* a, T* b, T* c, ...) > > { > > // actual matmul code here > > } > >=20 > > extern "C" { > > // Instantiate template for every type and export the symbol > > void matmul_r4(gfc_array_r4* a, gfc_array_r4* b, gfc_array_r4* c, ..= .) > > { > > matmul(a, b, c, ...); > > } > > // And so on for other types > > } >=20 > Cheers, >=20 > Tobias