From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.guenther@gmail.com>
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	by sourceware.org (Postfix) with ESMTPS id A4C8A38515F4
	for <gcc-patches@gcc.gnu.org>; Tue,  6 Sep 2022 12:17:16 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4C8A38515F4
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-ej1-x62a.google.com with SMTP id fg1so651918ejc.2
        for <gcc-patches@gcc.gnu.org>; Tue, 06 Sep 2022 05:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=7o8yPUz+HSdF5hFfn2GlxG4t30V80cCUwdbfn4UtLpU=;
        b=cUf11L2JsOtqT04R0cmvDLdCIZABYXkcaovU0f3m9MAElM8S6C+faurdE8MmaqQeyY
         qagF3WxcRCWwd8ApPoJShx/5bbDhA8Inn2wB88dgYKPIKPtkt6OJLeJGokuum3u+nWLC
         PeM7z8LjziyZ33FCxCau25kRxFsUR3bqGXdWC8eQLcMjmVIybYxfGvzSHCm6byZA5Lg/
         eDlNmiymm1J7fAS4kRms9A2InCQL7zWHT83HbdlrV9P0dCKNFA0+PJy/HbGtB5a4njpo
         H5EFasO4Iz6W/DnQQz2Td2nog1jQHtYj8d9/rX/oc5Mb3G+92FkyQ0OIxcRxY4R+0lXe
         7KvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=7o8yPUz+HSdF5hFfn2GlxG4t30V80cCUwdbfn4UtLpU=;
        b=Xasue4baQ9GTUBtkhLv98osczQ9xSOyYA6zgWfFuHfVgMzw2a4NeT+gu5t6K1EOXne
         mZFQoeBrnYGArzDp1bvPD6fKEOAhU36BpR2aYX4vbBHoawdPkTQgm/uQgIDsy+obcJls
         l8ALQeXh+lMKUrX1X3Dq3YjeKz8adGas6pabHuDHN15N7b9Vaq38d44WhDMKwZa/sHYW
         IVXTJLTqKdJu8ZBkgc2Q6NrOen/b2/bBj1fwQrokuC79xOT57ZV9fXAnTT79T/T73G/z
         flVGvsqTH3DVAbgD2muckJBS9yLKopMU+Bs/A+hz4OgGcTAMMBYylZ4cBIbCsgYLIan9
         e8Hw==
X-Gm-Message-State: ACgBeo3Ibb8rwwA0jKJEYjWvdBImD++med1qaumRTvGgqfk+gNc2vIMs
	oQzB0paBw1Y9E8j0OSsRhl5LWsNuAdaAV2R1VfI=
X-Google-Smtp-Source: AA6agR4QqUP02boK/tvA+q+KFaAkczGi3igtM/klxKchJ2LOpVN7AergHbkm7/nR226T2wfZU9Ezh2SyHr8h+66WdNQ=
X-Received: by 2002:a17:906:8a68:b0:741:56b2:af42 with SMTP id
 hy8-20020a1709068a6800b0074156b2af42mr31712503ejc.488.1662466635293; Tue, 06
 Sep 2022 05:17:15 -0700 (PDT)
MIME-Version: 1.0
References: <20220906072901.3472801-1-aldyh@redhat.com> <Yxb4VcSp1La/sm74@tucnak>
 <CAGm3qMW=36UTV7473_at7AbmXbqy8J7UdzJP9s=ARVkRBrxcLg@mail.gmail.com>
 <Yxb6T6NoDmOQMvRu@tucnak> <CAGm3qMVeTQFbovfbvQwnDkREFW1ZweXEWrM19gTaz9HWF=2YLw@mail.gmail.com>
 <Yxb90MaDBP1FVlTh@tucnak> <CAGm3qMU0Unbm_cdQX_w+S1REUfiWCoNJx+Aaa5cA5+y4AEzPaQ@mail.gmail.com>
 <Yxc30McbGnzIygNX@tucnak>
In-Reply-To: <Yxc30McbGnzIygNX@tucnak>
From: Richard Biener <richard.guenther@gmail.com>
Date: Tue, 6 Sep 2022 14:17:03 +0200
Message-ID: <CAFiYyc3Tsh0aAHZ_H5sN_qfS+vAP=rSfVhhKifE6s3qo1bHe3g@mail.gmail.com>
Subject: Re: [PATCH] Handle > INF and < INF correctly in range-op-float.cc
To: Jakub Jelinek <jakub@redhat.com>
Cc: Aldy Hernandez <aldyh@redhat.com>, GCC patches <gcc-patches@gcc.gnu.org>, 
	Andrew MacLeod <amacleod@redhat.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: <gcc-patches.gcc.gnu.org>

On Tue, Sep 6, 2022 at 2:06 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
> > Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
> > range for the domain is [-MIN, +MAX] for the min and max representable
> > numbers.  What happens for MAX+1?  Is that undefined?  I wonder what
> > real.cc does for that.
>
> I'm afraid I have no idea.
>
> The formats without Inf/NaN are:
> spu_single_format
> vax_{f,d,g}_format
> arm_half_format
>
> Never had the "pleasure" to work with any of these.
> Looking at encode_vax_*, it seems both GCC internal inf and nan are
> most likely are encoded as maximum or minimum representable numbers
> (depending on sign), and encode_ieee_half for !fmt->has_inf does too
> (for !fmt->has_nans it seems to "encode" the nan mantissa bits into
> highest possible exponent).  encode_ieee_single (for spu) uses
> maximum or minimum representable numbers for any infinities or nans.
> What they actually do at runtime is something I can't really check,
> but one would hope it is saturating...

I'd simply do what we do for -ffinite-math-only - just pretend you don't
cross the maximum/minmum value and effectively saturate the range.

Richard.

>         Jakub
>