From nobody Fri Feb 17 02:45:06 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PHx4k4pBLz3rHyd for ; Fri, 17 Feb 2023 02:45:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PHx4j1Wqrz3CM8 for ; Fri, 17 Feb 2023 02:45:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZIa+PQll; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676601923; bh=IpgIuPY+2QcrIAz5e5+ADiTLFiT5r5OWWxYfG9ML38Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZIa+PQllMtHqSSaHG/B7pcVQfB9cklsZsBHoK9NnBhtkYUKCzG3NSKxf8ierN/wSeh3z7j5zF5geknHmKhWj0ogGUKV1bY0EWWRwmHRwA3udO1Tc98korxzvUBJK/g55C/TMoVudSV8g0yU7Q662MfI7dn/1OX8CsKPLptak9j0nRt9WNdOPd3Jrtsn4VW8kzPiWbttlh/TpmE795BBW5+OA13axt/Hjk7vp2sreCLpV2QEd/OztjF3lhddtmuN6Ie9OC36ZGaAowU5DIXG7UXOxnP7TBAHHtHper1bZbm6/pjocr+jiay7mwUW/omqVB6yirE1F1VGrw9Z5RYHdJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676601923; bh=Av0meu/wX6bAgIMzoL55Br55J8V6q7ASNQCQeyNSD8l=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QwTuvCBRLfulKDxCZq72JWU7WkT+/zq+lTUXriPgSg1XEfp4SWlUtlPs/+3MQOO2YO7dzOMwaaFYAc/zZgynqZ2Evhm8MSqRw1hIJ5rR8hn1/O1/NvSExYvLWG2nDLZezp2DooFXqBJY2l57JMlm6JB0Ti37VVsYjj9owHIbphjkqEIChahGfJbJUQuFHId/zRnY7xE4TlutP8R10R4Ct0FecwitI8ky+/UPNJSxVqwpMfImLz2oFsPt/H6pSpjq/1ejQ/+oS/c00Kh+ZGsBLiXEtjNmJV2DAP3Cm99EvmfWtRE8tQz3/m9hoFytJsB1KR88ZkHVAbBTY+zSTd/K0g== X-YMail-OSG: l_M9Zc4VM1kuPG.hvY4jrwjIh2mL3c_7qZVq.uG.0.A43mkWvG9ut8pkHQLC9GZ cwVPyF9szGr4.N4_o1IPgwH_a9J2BnixKLkZWOjHAjyDmvpAHB76nwabN0qaaJNyJ9zVuWdP7.I8 7s5HyWQOsZN.94j.2_DCcrsR9Mqv2KDX9_O_qqpOutDhQ3gs9i7l0HKUPWDw_f2uWXr4Ve1FSItZ B_N3mUJYcPIZrr8ZGeoTbSZLFHN5DrJU8Bt.AJbnYpDPaFxJdyrB0um.Swst0AVRUtc..PjXJJER grKVWuRjyuX8h4pSB2YR4QSC0xtWum4q4LPNNS6cPCpz3Ppwsp26ZzuhYMPMVH7MrPFoRjBDU8zZ 8ypzFZUF8eByY6Q2JSmtBluOw9cIvbFvrH_NyWmiBsEElpjbqS87J7yPgD_9AHIyBEnvP1uLRdVF QV9lxH2B04HfxNWbcTLi18ldeyDXOCptQ8XLgQrbyfYhXa99r3dHBi13NGUHTQp8sI0SAS2ORXbf X3tXwTpP76aD3S5RqLKrPfWsaDB_5Mc.Uy4xChaKdNfoikGQ4q4UMdRPE0xKewp8Myl8v6ZqU652 SUF8OIEJL5trgu.NX4uocw.LG7MaVdeCyLWuiEM8Op5Z64MQawus9bMi3iCOeivhikAYuaRcooH8 UMche27Pc.3eu6Gyoay9GJtyTlyj8BFWx0kRJ6hZuLwuKnUUalYK25uNAhjIDI.7mlMHZcyQUGK4 pE0SPMJe8lBOZRG1mZEOlDFJ5mkPbo3lu_untZRfwq7ms1_hASYuB1DMGnF9YYb3paI4uTNNuMjk kOoUfZUTWsaYAFFQKT80TouXTTtrPUabkZoY6X_17333C1zLQxtzxdWD2zp4UGWSW2ot72Z3FJgk YzA8zhmc3rCBpfaNYT2ixJuI3aYm.3kuUW20Ys1HH3iH7oyNr.7lANH2Gqa.VHr8xwSm8ygizxH4 zIaYULi3lUKfWaYG1rFNBffqYfRgZN0_HMd1zd4z6qHPCCm3vCZr2DCJG.QIubsyrcoaPN8BnbL9 8EAeZq2Yjs1q6kdKWOMHZt3qleq31MSAyDUocVXqwxgWDhgNhuKz4pyCAUe5nirCyAyuzswgaxJ. tkg8UI60XzoTmonm6UU6LRNI5bpxHG7EuDUNYT9cP8la7Ze.J9ba49iVSDbPIWma8ojbBV0XVOXk LxmZ6SXWeuMXxvJWe.RIANbuOyKTJAO99LyAl5mJj_YdgYxyy8UJZUvKsBRr1jne.1Pq0p2kWbta MltAdObp4h0SHxHyrreAjnEDs8UWiX6M6oeJQ3QMHzlYpcsNw1c_Db4I7m8F_RzwMNyskXSxyAiX f3tVZL0WJmht.6BI5AniXsy2SqoYsfPWzNO9dFg0hrOtNtUMoSdhVyHNcOhXVujdoeVGMXa2g5SR qnHc3GE2upFSJ3MFIGKGsdjHNHE5qLp2ng03xs7kxys1g1.Ccg7XdkW1E2NdhHryNR2Y482mZRCM j39LfRXCqf65be5EB1zfYgJFy4KzN9NNL45mS1KXnNN6zjIzazKfrg1P0m69oke4zA8b1Q.mXDLH A_ovOlZa3v8FTPQoIdV5crrqjYRRquutjCmRv79aaBRiCj9K.iAy9kI3hQhjD1z2E0U8EvQolmit Su2S8I5P_6IaCOlpN9ocZgDOizIV_QHx_zRdvqvCWA9KN1.w4xbTvJ2LBYLzIrQPCNGam54BFiOZ xGFv5ymgLDRXYOjqLLbAC1xwJbIBb6bauOupXfcCT8YG_l3tdqe0I0QTwxY_PopXjvhvgkyly5fl eVPiqUq.AwvbSHAD3kigHat8Uxxk4vqIILe6DQnXXBFEvx.Mo47G_AwpWx.Q2rFU8Z7FUqy_WbTG A.n6suYM1DwSS26heV3jzuqa93_zjVxvaxMquENiAlQ7eaJBKyZuriWNg_zi8S9X9BXBSvACsAgD JbDdgE0o7WGJrW64p2yMMyJTEmKlXCpwg4xWySxG1bz4Lu9YPynSX_RE7fx_a3ZNvj7lOn3Gz2Kj 5d4BuD6S_3lVY2OsEzICcBv1wtKKZZyDn.i4VqLYa2xotyRGH1vJYbC2xMMW6oWUQcMYl63RKzXb tYTr041pTfxvdcJUhA73QCAI4gu0YAJWJfLQyOxes9fc6k5rmJFgVT0AeDptCZJCbuMmLnJgB1eB IoQoqKbz1pVLjZKbo8ByQ5yEPtt1qfEDDGNPiCnE_scs6euMh9X1C_zc7OKm4k26ZaxH6wf3PZ9T KG1scunJgP9JIR8l2z2tLigoDSTv9DJDcJMGcU2q7AyWUj2wMALvxCYwmHWy32J9ixbUGKhK6hz7 bthvX25Rf X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Feb 2023 02:45:23 +0000 Received: by hermes--production-ne1-746bc6c6c4-8fvwf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4eaae5ef0957820b92b3bb120e1aa972; Fri, 17 Feb 2023 02:45:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: git: 6926e2699ae5 - main - arm: Add support for using VFP in kernel [new: bad floating point data with multi-threading, not a crash] From: Mark Millard In-Reply-To: Date: Thu, 16 Feb 2023 18:45:06 -0800 Cc: Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <72CD283D-8669-4574-B9DA-3CEEB198FFF5@yahoo.com> References: <3A143148-895F-472B-9AFB-5F1AA0FD1FA0@yahoo.com> <782B252E-60AC-4036-BD74-46B95A31B337@yahoo.com> <4F9A3687-9577-4419-AE1B-D02A4C9212ED@yahoo.com> <402AEA29-B895-4031-99A0-876A39C02157@yahoo.com> To: "kd@freebsd.org" , "wma@freebsd.org" , dev-commits-src-main@freebsd.org X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.18 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.68)[-0.679]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from] X-Rspamd-Queue-Id: 4PHx4j1Wqrz3CM8 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [I've updated the program so that which thread is reported in the output and the scale of each value indicates which thread the value is from (unless it runs for a very long time). Thread 0 creates small values (unless it runs for a very long time), thread 1: creates only huge values. Values from the wrong thread are reported.] On Feb 16, 2023, at 15:31, Mark Millard wrote: > I start this message as independent of the prior crash reports: > this is not a crash report. It is a messed-up floating point > data report instead. >=20 > I have a simple C++ program that creates 2 independent threads, > each working on just local variables, where it appears that > after a while one thread ends up with a floating point value > from the other thread. >=20 > The two threads each just have loops incrementing a unsigned > long long and a double by 1 in the range where no information > is lost, initializing to zero. The cross-check for failure is > if it finds an example of n_as_dbl !=3D (double)n . An example > build-then-run showing a failure is: # g++12 -std=3Dc++20 -pedantic -g -O3 -pthread = -Wl,-rpath=3D/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp # ./a.out Thread 1: 34018092.000000 !=3D 4503599674389816 ^C # ./a.out Thread 0: 4503599680497650.000000 !=3D 38453432 ^C So: the floating point values (left hand sides) are the ones from the wrong thread and the unsigned long long values (right hand sides) are from the correct thread. So far this has been uniform. Also: which thread gets the odd value varies. The new C++ source is: // # g++12 -std=3Dc++20 -pedantic -g -O3 -pthread = -Wl,-rpath=3D/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp // # ./a.out // Thread [01]: double_value !=3D unsigned_long_long_value=20 // Use control-C to stop it. #include // std::numeric_limits #include // std::future, std::async, std::launch::async #include // std::to_string #include // std::osyncstream #include // std::cout int main(void) { static_assert(std::numeric_limits::radix=3D=3D2,"double's = radix is not 2 and is unhandled"); constexpr unsigned int ull_width { std::numeric_limits::digits }; constexpr unsigned int dbl_width { = std::numeric_limits::digits }; constexpr unsigned int use_width { (dbl_width