From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18361 invoked from network); 3 Dec 2020 16:54:15 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2020 16:54:15 -0000 Received: (qmail 1778 invoked by uid 550); 3 Dec 2020 16:54:10 -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 1760 invoked from network); 3 Dec 2020 16:54:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=7omXrwhtfJASCECdhnYUT78gUNVjxPXn9r7AaVc/znI=; b=eSBc0DonlGbiU7fSKrnJNRhmPYJqD9NTPgZH8xDs9pc3jD+Pkj0ke7LFkAV0BH101AnM I4C2jsj+Sd4ALV6h1hCYLMMM8hFJsd/N9M1MRTUl0PiD5mAn7JzMAng0q5vt4vtdmO08 6vvS3t9ulMsQvWR1m38qgx1Vg6wXdaoQSnp5s8DyIpJO077vUNrJ/1CFL6ICqHLNDUSC WhRqpJhDWJqrXJHJFQN0k4Qa87twa7xFSSJWwtdkB0c57EmBIpm4hPXrrcPbDGAzkfkj PBSxe79CkjohGiGw8Lwc7NFII+a2cckWGLYPiZiZW2VBdo0Ot4N69moWkFtVNsJfHqo0 Lw== To: musl@lists.openwall.com References: <20201201143634.13419-1-mhillen@linux.ibm.com> <20201201205020.GT534@brightrain.aerifal.cx> <3a1b3e6f-3978-4a7a-70b5-9bf18db7704b@linux.ibm.com> <20201202142504.GV534@brightrain.aerifal.cx> <20201202160140.GW534@brightrain.aerifal.cx> <0fda3e37-b513-91fc-f09e-cfca11a76a20@linux.ibm.com> <20201202191306.GX534@brightrain.aerifal.cx> From: Marius Hillenbrand Message-ID: <108407b0-24ac-d3d3-43c1-f394ba6bbebe@linux.ibm.com> Date: Thu, 3 Dec 2020 17:53:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201202191306.GX534@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737 definitions=2020-12-03_09:2020-12-03,2020-12-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1015 adultscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012030098 Subject: Re: [musl] [PATCH] s390x: derive float_t from compiler or default to float On 12/2/20 8:13 PM, Rich Felker wrote: > On Wed, Dec 02, 2020 at 06:09:44PM +0100, Marius Hillenbrand wrote: >> On 12/2/20 5:01 PM, Rich Felker wrote: >>> On Wed, Dec 02, 2020 at 09:25:04AM -0500, Rich Felker wrote: [...] >>> I'm looking at >>> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560225.html >>> which seems to be what you're talking about, and don't understand how >>> it's intended to work. It looks like it's running a test for target >>> behavior on the host compiler (there is no target compiler at the >>> point this test is run). Looking again, I guess that's why it's under >>> a condition for build==host==target. >> >> Right, that's the patch. The check only applies to a "native build", >> with the assumption that the build environment is the same as the >> intended target environment. >> >>> What happens when cross >>> compiling? Do you get the old behavior unless manually setting >>> --disable-s390-excess-float-precision? >> >> When cross compiling, we get the new behavior (the setting starts at >> "auto", which is never resolved to yes or no; so the AC_DEFINE is left out). >> >> In any case, manually setting >> --enable/disable-s390-excess-float-precision takes precedence. > > FWIW this means building GCC 11 for any older version of glibc or musl > will give a broken configuration unless you pass > --disable-s390-excess-float-precision to configure. I'm not sure if > anything should be done about that; at least I might want to handle it > in mcm... I will look into handling cross compiles in a more differentiating way... > > In any case this probably means I should include your patch in this > release cycle so at least current version builds right. > > BTW is there a -m option to override at runtime in order to test both > behaviors, so you don't have to build a new GCC from scratch to do it? Yes, in the current GCC, -fexcess-precision=standard or fast switches between the two behaviors (i.e., both __FLT_EVAL_METHOD__ and emitted code; "fast" corresponds to the "new" behavior). Marius -- Marius Hillenbrand Linux on Z development IBM Deutschland Research & Development GmbH Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294