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 6751B3858D35; Mon, 11 Oct 2021 20:11:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6751B3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: n3vNyCGpWslcdEx/96eWRDdMplR5fABfPHr370QgQ+d1zU572/Wfp0h/SMDQGJIAM+nMfIM34G Ni5wC9vC+fh3XQNYeau/JdM0SJo/RvdB1TulcBybzyYItp6rS7ZIgFhIRAAj7EnpR5k16V6OYA z5PGx5pvgMcbZsShptFDAmZJYcmQNdWl8KY+x1IRb18hCwqkOm4gJqTz2VRSJp8H9ksaEheNEK cT05E6lacRH04ZSBE0WeOvFgTp3FpXYDqgh7G+3JYKlEbgHDhrS4JcCGJaWe0BDcC4nXm4rWcz FaFbFhdPTj9GFsQ4/utZZgD2 X-IronPort-AV: E=Sophos;i="5.85,365,1624348800"; d="scan'208";a="67077850" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 11 Oct 2021 12:11:57 -0800 IronPort-SDR: ShV3azkLUvNefycThy0IsDKJHiUjfoJW7i3pKxsMKUXnGj/VBHqO7DtEZuWpNe7MJeBA1t4CtJ xjPryIFc3D8xFy451+oxH2dasL776MPn0UveHQIQ2/NZtkScg9R7LBxJRsL38GrZ4cYhFFkwpL oIVQqIq13uVUJicuYM0eNPlGaxfyY5sNxk9gPk1r2vYyFxaYIabpncUF/ypqqte2XT51G4L54J SA+sjZii0TOvwZD/hOy+F8bEplwJn8/8I4lqDalhcV/8wehOIoMC0S8ACPn4zqzc4/opJYUY/q Rpw= Date: Mon, 11 Oct 2021 20:11:50 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Segher Boessenkool CC: Jakub Jelinek , Michael Meissner , , Thomas Koenig , , Tobias Burnus , Jonathan Wakely Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes In-Reply-To: <20211008175335.GS10333@gate.crashing.org> Message-ID: References: <90df1250-9b3f-4a55-bc67-e3e05e54f7ef@netcologne.de> <20211006151744.GE10333@gate.crashing.org> <20211006154107.GK304296@tucnak> <20211006160730.GG10333@gate.crashing.org> <20211006163433.GM304296@tucnak> <20211006183919.GK10333@gate.crashing.org> <20211006205717.GL10333@gate.crashing.org> <20211008175335.GS10333@gate.crashing.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 20:12:00 -0000 On Fri, 8 Oct 2021, Segher Boessenkool wrote: > But many CPUs do not have hardware floating point in any variant, and > their ABIs / calling conventions do not mention floating point at all. > Still, this works with GCC just fine: it passes floats and doubles the > same as 32-bit resp. 64-bit integers. > > binary16 and bfloat16 would be easy to support the same way, but it is a > bit harder for binary128, because we do not have a 128-bit integer type Supporting passing arguments (and return values) the same as an integer type of the same size is a *choice* (which comes with other choices - in particular, whether to say some or all the higher bits in the register or stack slot are sign-extended, zero-extended or undefined). It's a choice that should be made explicitly, and documented (in the relevant ABI if one is maintained), and coordinated between implementations when there's more than one implementation for the architecture trying to be compatible. We've had plenty of problems in the past with ABIs that were just what happened to fall out of the implementation (e.g. ABIs that depended on the details of what machine mode was assigned to a structure type...). On a related note, I'd encourage architecture maintainers to start thinking now about what exactly their ABIs should be for _BitInt (, accepted as a required feature for C23 up to at least the width of unsigned long long), and documenting it and coordinating with other implementations where appropriate. There's a concrete proposal for x86_64 (see origin/usr/hjl/bitint branch at https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an indication of the sort of issues to address in such an ABI. -- Joseph S. Myers joseph@codesourcery.com