From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out3.simply.com (smtp-out3.simply.com [94.231.106.210]) by sourceware.org (Postfix) with ESMTPS id 082573858D20 for ; Mon, 15 Jan 2024 14:38:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 082573858D20 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=gaisler.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gaisler.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 082573858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=94.231.106.210 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705329531; cv=none; b=thfyprdoTS6DR4cRZojbUGZlww6hqIAQxE2ppvWt1yU04S5tBMRyxNvh/IhLPldC5FHChVeQ/gf2ixE0b7xyocgsBkyAUEKqcW5Y+t/jKnYcu5EB97UjXFxdeuEmAQjC8wA8sNWLXfvZ+8nNwDapGJbz/RkRXLxhxls4cuX8fkM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705329531; c=relaxed/simple; bh=a8l4nWXw/K8QPa4khnW9lJs47xad+F3uyih9YjWTPaM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=BF1nowV0POgObyyZbjNwRQBNU9PctJE1P2d23gxF1slFD1iz84jkydHXn5+RoP4r1WcyVS20LxB8gwyeUbs064Xmoz6dwUBfsy+4Guk/Gh76PeZmmMFDsAzx1q8+JFpycj436iQUm7nAONEADswGyHuVi700JKag1qs9oGPgIQE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by smtp.simply.com (Simply.com) with ESMTP id 4TDFBc046Bz6803; Mon, 15 Jan 2024 15:38:48 +0100 (CET) Received: from [192.168.0.86] (h-98-128-223-123.NA.cust.bahnhof.se [98.128.223.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.simply.com (Simply.com) with ESMTPSA id 4TDFBb5Gxlz683G; Mon, 15 Jan 2024 15:38:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gaisler.com; s=unoeuro; t=1705329527; bh=eSQHyIj0Wanv/sZcJunNSNH0nmM1ODuSR6EBm3k76MQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=J5AlPihUU8fF3+VgFMp77gnQyRJ3FCiRTuEnLqW70LLgGxjK1G2iyeA9kHpWK6Ym1 qsvhJ7LG8QRbfR1cLVOnj19ubok+fNDPfmY8TmA1vfRVDo09r54pnBb2f9tIwFuBfL sg5f+4CV0hUgpxAQMGsuva9TkIjKnHJ5BXwoEV0s= Message-ID: <48a9eff3-7776-43d4-b316-06a70d5b6670@gaisler.com> Date: Mon, 15 Jan 2024 15:38:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sparc: Fix llrint and llround missing exceptions on SPARC32 Content-Language: en-US To: Adhemerval Zanella Netto , libc-alpha@sourceware.org Cc: daniel@gaisler.com, andreas@gaisler.com References: <20240112092628.2464455-1-cederman@gaisler.com> <20240112092628.2464455-5-cederman@gaisler.com> From: Daniel Cederman Organization: Frontgrade Gaisler AB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 2024-01-12 19:05, Adhemerval Zanella Netto wrote: > > > On 12/01/24 06:26, Daniel Cederman wrote: >> +/* Define these macros to 1 to workaround conversions of out-of-range >> + floating-point numbers to integer types failing to raise the >> + "invalid" exception, or raising spurious "inexact" or other >> + exceptions. */ > > This is not really true for all sparc32, at least with sparcv9 I have > access I have not seen any issues with missing exception overflows or > spurious inexact. Are these some leon3 limitation or issue? > I don't think it is a leon specific issue. I can trigger the same issue with QEMU for other sparcs. Sparcv9 has custom versions of the functions involved so that is probably why it is not affected: ./sysdeps/sparc/sparc32/sparcv9/fpu/multiarch/s_llrint.c ./sysdeps/sparc/sparc32/sparcv9/fpu/multiarch/s_llrintf.c Corresponding patches for other 32-bit architectures references this bugzilla entry: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412 I will have to look into this again, but I remember that it was a similar issue for sparc32. > I think we need to know exactly how/when this happens and only enable > such workaound when required. > >> +#define FIX_FLT_LONG_CONVERT_OVERFLOW 0 >> +#define FIX_FLT_LLONG_CONVERT_OVERFLOW 1 >> +#define FIX_DBL_LONG_CONVERT_OVERFLOW 0 >> +#define FIX_DBL_LLONG_CONVERT_OVERFLOW 1 >> +#define FIX_LDBL_LONG_CONVERT_OVERFLOW 0 >> +#define FIX_LDBL_LLONG_CONVERT_OVERFLOW 0 >> +#define FIX_FLT128_LONG_CONVERT_OVERFLOW 0 >> +#define FIX_FLT128_LLONG_CONVERT_OVERFLOW 0 >> + >> +#endif /* fix-fp-int-convert-overflow.h */