From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id F02473858C52 for ; Fri, 23 Sep 2022 10:03:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F02473858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28N9cbOE007414; Fri, 23 Sep 2022 12:03:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=Es+fZdAhJhctv3kfm+4W2WPMn6CCjDDpBSVVpiFL590=; b=UEKeqlQDPP7mVOu+n5WpJdGJ4XWP0k5e6h2AhGbt5q3n7gNnBwEgMnWXIukRkrf5WQa5 6LK6hNEhyjwyL4Em8FhESeWU2txRjmuDE3vf0E3x7JlmjPnXVXpj0VNPnZqWVD75uvNb g3LJiTmlOAg/MR3r8gJW6/ZlMxHJTL+NvAIIOy2jwKYpKlruSBghR2uVOjzAq2FUwTaH KJ0gXy2szcNWXiKXqC67CBLgrzdexB03v5ZoY5gr9Qy4UWT7mKfcza5hKFqeOOKDJHCs FhjDKOVvSOT05efDCXc0HeI25qq5Qo5bg0dST+u0FdXRWSjxtui6LBw/h1Kk39y8xiho MA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3jrkmx8cg6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Sep 2022 12:03:47 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id ED3CC10002A; Fri, 23 Sep 2022 12:03:45 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id A874521D388; Fri, 23 Sep 2022 12:03:45 +0200 (CEST) Received: from [10.210.55.83] (10.75.127.123) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.31; Fri, 23 Sep 2022 12:03:42 +0200 Message-ID: Date: Fri, 23 Sep 2022 12:03:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH] testsuite: Sanitize fails for SP FPU on Arm Content-Language: en-US To: Joseph Myers CC: References: <20220922164057.4107373-1-torbjorn.svensson@foss.st.com> From: Torbjorn SVENSSON In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.123] X-ClientProxiedBy: GPXDAG2NODE4.st.com (10.75.127.68) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-23_02,2022-09-22_02,2022-06-22_01 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Joseph, On 2022-09-23 00:42, Joseph Myers wrote: > On Thu, 22 Sep 2022, Torbjörn SVENSSON via Gcc-patches wrote: > >> This patch stops reporting fails for Arm targets with single >> precision floating point unit for types wider than 32 bits (the width >> of float on arm-none-eabi). >> >> As reported in PR102017, fenv is reported as supported in recent >> versions of newlib. At the same time, for some Arm targets, the >> implementation in libgcc does not support exceptions and thus, the >> test fails with a call to abort(). > > It's definitely wrong to have this sort of Arm-specific conditional in > architecture-independent tests. Tests requiring floating-point exceptions > support should have an appropriate dg-require-effective-target; if that > dg-require-effective-target wrongly passes in certain configurations, fix > it (or e.g. add a new check_effective_target_fenv_exceptions_double to > verify that exceptions work for double, as opposed to the present > check_effective_target_fenv_exceptions which checks whether exceptions > work for float, and then adjust tests requiring exceptions for double to > use the new effective-target). > Okay, thanks for your review. I will split this test case into 3 files as for SP FPU, we would like to verify that the exception handling for the float part work, but at the same time we know that exception handling for double and long double should not work. Do you think it's preferable to have the double and long double should be reported as UNSUPPORRTED, or as XFAIL for the SP FPU case?