From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 250AD395444E for ; Fri, 6 May 2022 18:07:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 250AD395444E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 246I5RDc002665; Fri, 6 May 2022 13:05:27 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 246I5Q5C002663; Fri, 6 May 2022 13:05:26 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 6 May 2022 13:05:26 -0500 From: Segher Boessenkool To: Matthias Gehre Cc: "gcc@gcc.gnu.org" Subject: Re: [RFC] Adding =?iso-8859-1?Q?division?= =?iso-8859-1?Q?=2Fmodulo_on_arbitrary_precision=A0integers=A0to=A0libgcc?= Message-ID: <20220506180526.GL25951@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Fri, 06 May 2022 18:07:14 -0000 Hi! On Fri, May 06, 2022 at 02:09:21PM +0000, Matthias Gehre via Gcc wrote: > We would like to add support for division/modulo on large arbitrary precision integers to libgcc/compiler-rt > as required by C23's _BitInt type [0]. > > >From what I know, gcc doesn't yet support C23 _BitInt, but we would still > like to ensure that libgcc and compiler-rt can stay compatible in the future. Why? Why would that be useful at all? libgcc is an implementation detail. It is not meant to be used by anything but GCC itself, and then only to implement things that aren't implemented some other way (by target code typically). The names of the functions it implements are based on the GCC-internal RTL names, often identical even. Defining the libgcc names first is not only futile, but also the wrong order. Most functions in libgcc are a not-so-ideal-but-at-least-it-works implementation that target maintainers who cannot be bothered to implement this functionality more optimally can use. Typically what you really want is not a library routine at all! As noted elsewhere (I forgot by whom, sorry) the target ABI will probably have somemthing to say about the actual data representation, so it is very counterproductive if we have something in libgcc that does something else. Segher