From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by sourceware.org (Postfix) with ESMTPS id E404E3894C05 for ; Tue, 1 Sep 2020 19:28:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E404E3894C05 Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id DCC5D3F2D6DB; Tue, 1 Sep 2020 12:28:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pc0hz_PR4t0U; Tue, 1 Sep 2020 12:28:19 -0700 (PDT) Received: from keithp.com (koto.keithp.com [10.0.0.2]) by elaine.keithp.com (Postfix) with ESMTPSA id 797BB3F2D6D3; Tue, 1 Sep 2020 12:28:19 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id 47EB21582201; Tue, 1 Sep 2020 12:28:19 -0700 (PDT) From: "Keith Packard" To: Sebastian Huber , newlib@sourceware.org Subject: Re: [PATCH 0/3] ARM with only 32-bit floats do not have fast 64-bit FMA In-Reply-To: References: <20200808223413.4015633-1-keithp@keithp.com> <1fc07c90-694b-01ea-cedc-0656eccdd827@embedded-brains.de> Date: Tue, 01 Sep 2020 12:28:18 -0700 Message-ID: <87wo1db8kt.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:28:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sebastian Huber writes: > I think the problem is somewhere in the build system: > > find -name s_fma.c > ./newlib/libm/machine/arm/s_fma.c > ./newlib/libm/machine/aarch64/s_fma.c > ./newlib/libm/machine/riscv/s_fma.c > ./newlib/libm/machine/spu/s_fma.c > ./newlib/libm/common/s_fma.c > > I guess the machine-specific file overrides the common file. If the=20 > machine-specific file is empty due to pre-processor magic, then the=20 > default implementation is still not present. newlib shouldn't be calling fma if the underlying hardware support isn't present -- fma is used in some math functions to improve performance where the code can take full advantage of the additional precision of the intermediate value. Are you using fma directly? If your hardware supports it, the C compiler should be directly emitting the relevant instruction sequence so you shouldn't be seeing an undefined function appear. If not, then one of the two versions of fma should be getting compiled as they have opposite tests -- newlib/libm/machine/arm/s_fma.c checks for '#if HAVE_FAST_FMA' while newlib/libm/common/s_fma.c checks for '#if !HAVE_FAST_FMA'. I recently did some work in this area, so it's possible I broke something in your environment that I didn't catch in mine; I don't test newlib builds, only downstream picolibc builds. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAl9OoNIACgkQ2yIaaQAA ABHltw//bFrAHJ+wSTKOENYCH1UaIkAsPmSd3FgjGAs5/8RQNmXKkq1lkAVlgvLI 3WnQhF/OyqQkmrS/jU0iA8yz+BtDbe8mo3hM//m3mGz6kmmLMmjlJ5QRDr5HrYKZ id1n6K1AQmNqMR+1MgDwR/i63GwQu8w9KdNpnMktLqG72ktTn00+xXoc3JPedMXF zQLLNTcZZR6TNH7QfXYNu6+MSdRcnP+KRRvRRY3QIkM3HVjsoQAzm07bIGQuZJCC J9CvD3LuSErKkKfOC4MrPoiZGyyyK482h4dVHhgvvGQ95xHBS972IZjRZ4yrjSlI A/JyKe6MSnP94u7rmBZVDnRU7NMhTZ3UMG4S8HwwWav+ONQ6+OsSSSzT85Y3I6z+ FVLHFVVZVSSUz9Wg9iDhRU60qNUtgWuHhiVSoP1nTQC+Uq9YWEOEdrMY8dfV4hSs TNBb3peBYI9PzQsJ/+5ITQKpLpoJzr3woDkGn2bL0Y342O7FYoNiq8AbeytxhikY pnZMxfPYI0OPj7ws/vFIbT2tBOum+MFSNQ4aC2MJySjYJZDdnHOH9b9SufUpT9q3 xwd6+j1qjLzs675Y/jKe9+k8XzvWe7/ZB6VqBlX33ULwPN0DGqQdoQZIgErQ2MTK Iwotzq22MisKgWi1lOD0QbNC3wcWqSsjjKlpxRIOHBD5LCPgdY0= =V/ab -----END PGP SIGNATURE----- --=-=-=--