From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 39AA23854555 for ; Thu, 17 Nov 2022 17:42:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 39AA23854555 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668706958; h=from:from:reply-to:subject:subject: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=RY2oHkmlsw6jLiO3Tv8doYuRj3chdgLts0UNoydSoEU=; b=G94347jXEboxwD12xlmlVosc4e2LcwwtV5kmJhhKGb+4c0BTDYtbZc8N/+LbSapLTjjtX9 d1LEhJmJIGq8BAkpBBgNqtrWmgPIIiZ/5cFoUFm6MVYaza0i84T6yJeeVA5TCRomitG10a SKt8FJ9yA1Iu0DCiJYwmTjkSGcUR5bg= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-16-e2tsuf_KMq2udNeyO0zrKg-1; Thu, 17 Nov 2022 12:42:37 -0500 X-MC-Unique: e2tsuf_KMq2udNeyO0zrKg-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-37010fefe48so24913877b3.19 for ; Thu, 17 Nov 2022 09:42:37 -0800 (PST) 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:message-id :reply-to; bh=RY2oHkmlsw6jLiO3Tv8doYuRj3chdgLts0UNoydSoEU=; b=H3mLQ3CpL/D4F832MSfokS8zEf3OKeYFFbIs4pyNAvJaBxbq1Z7G6/khJOMQvfzN3e U3D7H/oaMfbdqynaD/kmRjHCToWSUzkr9mhgMcj5eLUmiUlRELcgr0lnOdf3LZZQYkL0 jwhQrpHFgAFLMY8RIUIQiwufChhYlWt6OfHvtDQANh22llFv1kkbaonFq4E27xJvl31/ XNWzpRZ4omas2lCqRPlDJLezlApQRwIgpzvJBl+gssi5vvlRoKdNM8NbSZXQbhXxHixa 7fn8RMjDXF6q1SZxnEHBkGRcZ/1p7+yV2zhzrEZjdyvkWTwY9U7dvBz/I942QzJBpRa5 nVDw== X-Gm-Message-State: ANoB5pm/N78/OtBihff4MQEzeh32YVHJyaTOR7/HAru9WC7ekyy27O7d hBDV/V2jE2hz+o7kSasNaaWrhbDFF712C7F0oeUrG/SF46S7iKzW4P5XZxolhs4BN1JWFMUeLP4 QNXxemfdj+hIyvcoCT6v9AExk8RbMj74PTA== X-Received: by 2002:a05:690c:c01:b0:36d:1162:5dd with SMTP id cl1-20020a05690c0c0100b0036d116205ddmr2906412ywb.462.1668706957029; Thu, 17 Nov 2022 09:42:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf4so8XyD5jwNiNGFKOAE/GdT6T7NYPF3b3o+Y9W6zVAS5gjxQi5722xrXteWFbrVfuj1OEqQMu/3w+KhB4n7Jo= X-Received: by 2002:a05:690c:c01:b0:36d:1162:5dd with SMTP id cl1-20020a05690c0c0100b0036d116205ddmr2906395ywb.462.1668706956778; Thu, 17 Nov 2022 09:42:36 -0800 (PST) MIME-Version: 1.0 References: <20221113200553.440728-1-aldyh@redhat.com> <6150f7fd-5a57-c138-f65e-8dc3bf13d11a@codesourcery.com> <29dcbe58-7400-472f-ef22-d416dc18b8a3@redhat.com> In-Reply-To: <29dcbe58-7400-472f-ef22-d416dc18b8a3@redhat.com> From: Aldy Hernandez Date: Thu, 17 Nov 2022 18:42:25 +0100 Message-ID: Subject: Re: [PATCH] [range-ops] Implement sqrt. To: Jakub Jelinek Cc: Joseph Myers , GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: This may be DCE. DOM uses ranger through simplify_using_ranges::fold_cond() to fold the following conditional to false, because we know x_185 is a NAN: x_185 = __builtin_sqrtf (-1.0e+0); if (x_185 ord x_185) I believe we can do that, because there are no user observable effects. But DCE removes the sqrt which could trap: Eliminating unnecessary statements: Deleting : x_185 = __builtin_sqrtf (-1.0e+0); Is DCE allowed to remove that sqrtf call? Thanks. Aldy On Thu, Nov 17, 2022 at 5:48 PM Aldy Hernandez wrote: > > > > On 11/17/22 17:40, Aldy Hernandez wrote: > > To go along with whatever magic we're gonna tack along to the > > range-ops sqrt implementation, here is another revision addressing the > > VARYING issue you pointed out. > > > > A few things... > > > > Instead of going through trees, I decided to call do_mpfr_arg1 > > directly. Let's not go the wide int <-> tree rat hole in this one. > > > > The function do_mpfr_arg1 bails on +INF, so I had to handle it manually. > > > > There's a regression in gfortran.dg/ieee/ieee_6.f90, which I'm not > > sure how to handle. We are failing because we are calculating > > sqrt(-1) and expecting certain IEEE flags set. These flags aren't > > set, presumably because we folded sqrt(-1) into a NAN directly: > > > > // All negatives. > > if (real_compare (LT_EXPR, &lh_ub, &dconst0)) > > { > > real_nan (&lb, "", 0, TYPE_MODE (type)); > > ub = lb; > > maybe_nan = true; > > return; > > } > > FWIW, we could return [-0.0, +INF] +-NAN which would keep us from > eliding the sqrt, but it'd be a pity to keep the sqrt unless it's > mandated by some IEEE canon. > > Aldy