From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id B461C3858D28 for ; Tue, 11 Apr 2023 10:46:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B461C3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id E07F21FDF0; Tue, 11 Apr 2023 10:46:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1681210016; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YfhAM1Ozy+Ik1UBakUm37qqoocbPZ+P191unmxwuI3Y=; b=POIIhpkYOA/L5LWSUlEtpaqKpgBKjtVjI6kxZNBAbuw88mZjmvLCcaedhh2rhi5ygm6hic u+TKJ17BuaDa0M3Y/j6zVGvjAOi1oo25ln/Ckg0mp/cMFSCLmNRbZ1Ts4iDfUu+ctbDGwt hpSuOPKwhrgaxLGi909rznAOhTtjp9E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1681210016; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YfhAM1Ozy+Ik1UBakUm37qqoocbPZ+P191unmxwuI3Y=; b=8Xlw5C/soxou8xXuqh02pOjZbEEImqwogzSyvPyPtOypyRaMoCwWvfFrBy2KWa7XTOjZ2I SGNG2o14zB8DnZBw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C5ED62C141; Tue, 11 Apr 2023 10:46:56 +0000 (UTC) Date: Tue, 11 Apr 2023 10:46:56 +0000 (UTC) From: Richard Biener To: LIU Hao cc: Andrew Pinski , GCC Mailing List , "Joseph S. Myers" Subject: Re: MIN/MAX and trapping math and NANs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On Tue, 11 Apr 2023, LIU Hao wrote: > ? 2023/4/11 16:00, Richard Biener via Gcc ??: > > I think without NaNs MIN/MAX cannot raise any exceptions (I'm not > > even sure whether MIN/MAX involving NaN will set invalid, but > > most certainly with sNaN it will trap and return a quiet NaN?). > > The C standard doesn't > > document any exceptions for fmax/fmin (even with NaN), but > > meanwhile there's a plethora of min/max function variants ... > > My interpretation is that if one argument is a SNaN and the other is not, > `fmax()` shall return the SNaN unchanged, without converting it to a QNaN. > (F.10.9.2 The fmax functions, ISO/IEC 9899:2017) I see. I'll note that the x86 maxpd instruction (which doesn't conform to IEEE with its handling of NaN) raises INVALID on sNaN and qNaN operands and apperantly also DENORMAL. In the case we ever implement conforming FP exception support either targets would need to be fixed to mask unexpected exceptions or we have to refrain from moving instructions where the target implementation may rise exceptions across operations that might raise exceptions as originally written in source (and across points of FP exception state inspection). That said, the effect to the FP exception state according to IEEE is still unanswered. The NaN handling then possibly allows implementation with unordered compare + mask ops. Richard.