From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C895C2DA8A for ; Wed, 28 Aug 2024 18:32:31 +0200 (CEST) Received: (qmail 23833 invoked by uid 550); 28 Aug 2024 16:32:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23801 invoked from network); 28 Aug 2024 16:32:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexrp.com; s=alexrp; t=1724862738; x=1725467538; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=btdk3M/jIJfj1rGgXLGV0/Uie62lDX/8Ivg3epfCSlc=; b=YKpwwU7hxQAZWBpQj8lW8fln51Nn0hjhRvEanDmjEQgzyVbpNmu4TBPuXHyuCEJgzM evdj/677cuESK8g/B8IolEXhXYK7PgHpBQPWauvnFiCr/iGiG36IOPDZX4HMtrDBX7Gd p2RwYR2SSBXwPVk9/AI2t76eAtzRQiecCbY4hLF70iQd8xO4QkOJtDOnPLKewmKrBV48 0RJMLluzESDLww2EtagCAf7q0E+tFwfuXj92HeOPFUBq5zkFL8/8hnC57v52kMJlR3Rx tXWbbkqNlt1m0FS58uoY83Wvpkwq6ylhRlP7B1o9LbOgMnD7r+2h+OEN9laBi8DkjcKF elVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724862738; x=1725467538; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=btdk3M/jIJfj1rGgXLGV0/Uie62lDX/8Ivg3epfCSlc=; b=DiwJ9FArwukdvEHsDvPnurA8SnUzvngLYbm94KTaClf+6RnplqMwXL5u26HGu9NqaM 6qqElIDN37oVuFBIyuRpUiBdFE4ia90G9PujzIfXnMn62piKLfHPHnHRXZwDs77UUoSy yBFHAEwI9R7z/VgsCRrNri3q5RAsa8GwqV8K1SC46F2chrd+rYGXvpsNcgrOFagWIlZU Xv+HJDPCc0YWKFrMZ4lpotfj53J0HQ6Al0rfmPZExoM1F+kPm1yLH4oAolJNc3B4BA0v Rat2L5fCodOVqhGSPLjhTQZ9RltTjLzJViACN0kHsj+LgxIIiEyHkL0XUDn6PbQQ68ti sCcQ== X-Gm-Message-State: AOJu0YxaWo+li7x8+ku7odAEEu+oJzi4/3wpPS9pAFqqKSgHwhLuGxum 5EAqcwth8WXlYmKble67vnntCrhKR3HqvmI7J3ClFSE112ufVhh7mhTc+2rYZpCj7j94GMi6Qh7 RRHqlP3gtX4X+868N64GDul1I6tfVQKRXsAckkw== X-Google-Smtp-Source: AGHT+IEPfUImQjxb6NkjueG5fN7Mn3ytKr11ZREA8v30uzlHwy/5ySKO58dpR11CGUMeCWLXY44yLUdMPcYVgyKX/q0= X-Received: by 2002:a05:600c:4512:b0:426:6320:226a with SMTP id 5b1f17b1804b1-42bb02efd5cmr1523935e9.15.1724862737839; Wed, 28 Aug 2024 09:32:17 -0700 (PDT) MIME-Version: 1.0 References: <20240828152826.826990-1-alex@alexrp.com> In-Reply-To: From: =?UTF-8?Q?Alex_R=C3=B8nne_Petersen?= Date: Wed, 28 Aug 2024 18:31:42 +0200 Message-ID: To: Alexander Monakov Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] configure: prevent compilers from turning a * b + c into fma(a, b, c) On Wed, Aug 28, 2024 at 5:53=E2=80=AFPM Alexander Monakov wrote: > > > On Wed, 28 Aug 2024, Alex R=C3=B8nne Petersen wrote: > > > I've seen Clang do this for expressions in the fma() implementation its= elf, > > which of course led to infinite recursion. This happened when targeting > > arm-linux-musleabi with full soft float mode and -march=3Darmv8-a. I im= agine > > it's possible for GCC to do similar silliness. > > musl passes -std=3Dc99 to the compiler, and in all GCC releases so far* t= hat > disables FMA contraction (as opposed to -std=3Dgnu99 or whichever -std=3D= gnuXX > is enabled by default, where unrestricted contraction is implicitly enabl= ed, > i.e. the non-standard and dangerous -ffp-contract=3Dfast mode). OK, that part can definitely be left out. I only added it for good measure; I haven't actually seen the issue occur with GCC. > > Clang respects #pragma STDC FP_CONTRACT OFF, so that is available as > a smaller hammer than disabling fma across the board. Breaking up > contractable expression in fma*.c will work too. That pragma indeed seems to work. I suppose we could just add it to the fma*() implementations and call it a day? I'm unsure if there are other functions that might be affected by this. > > [*] maybe modulo bugs in old releases where the backend doesn't respect > -ffp-contract=3Doff and which Glibc worked around with -mno-fused-madd. > > Alexander