From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id CB1A1385703F for ; Mon, 10 Aug 2020 11:47:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CB1A1385703F Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-548-yDHtxseVPa-ESDz7e6hkqQ-1; Mon, 10 Aug 2020 07:47:33 -0400 X-MC-Unique: yDHtxseVPa-ESDz7e6hkqQ-1 Received: by mail-wr1-f71.google.com with SMTP id z12so4126985wrl.16 for ; Mon, 10 Aug 2020 04:47:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WmpLj5j9shNW/fO/baJ2KEN90EfAQTZcNGcwOLW8a/Y=; b=VndAltI/BN5TZIj+1aV/IDET7MwJIw4vnBuzuh/0EMu6xns9dnf6Oir51gg0TIGajj dkcEK7iyj081wdjdB+Plbo43O13NLCX836gp7IGAdUs4Rut586Gz0VjiXgTBxWPX/U8a SHpMICI8KbRV3vju+JpnZTTuGvwNQdi/SX0EP52StT/+pTnvXveDlSvPgilh7E26PWa/ 9ps5ZcNHYJtEioDVuS7Qk4Rds7Bo0XSPZ46T6xepwymrORHhdgb/7wphWSiS6zxTRwhJ taPGIzRFLTFueNzbLKDKM2P0SvQHV2b+sMlE/JN7FlhI+Qineu5y4efu3XZ1y9PABHLN kbnA== X-Gm-Message-State: AOAM530Jd123QmsMjvbUzk0NXeMgJR2ag9eineYKg1hfLEyLawZkkKty RCIirlGqz3NyTjJ+DMXS9kTJcosCTYx22M87yzTv0pDqKPnFKfVpjXRa6XyV2Pn69uzExHuC6sn PZfLn6WVUBjjLB10Tvw== X-Received: by 2002:a1c:5413:: with SMTP id i19mr25339211wmb.139.1597060051874; Mon, 10 Aug 2020 04:47:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5XuxBV0d8QcrzmK0sQmlLWm4mxB5OXifTl66srh3LpND5vFQicnb+Cxm8iO0NvZTEEHw9XA== X-Received: by 2002:a1c:5413:: with SMTP id i19mr25339192wmb.139.1597060051638; Mon, 10 Aug 2020 04:47:31 -0700 (PDT) Received: from abulafia.quesejoda.com ([37.29.229.181]) by smtp.gmail.com with ESMTPSA id a10sm20590840wrx.15.2020.08.10.04.47.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 04:47:30 -0700 (PDT) Subject: Re: [PATCH] Rewrite get_size_range for irange API. To: Martin Sebor , gcc-patches@gcc.gnu.org Cc: msebor@redhat.com References: <20200806145350.864962-1-aldyh@redhat.com> <790f18b6-c75f-e91b-3ea5-087a38f67b54@gmail.com> From: Aldy Hernandez Message-ID: <394a608f-a1cd-5688-7fad-53aad3fe16c2@redhat.com> Date: Mon, 10 Aug 2020 13:47:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <790f18b6-c75f-e91b-3ea5-087a38f67b54@gmail.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 11:47:36 -0000 On 8/6/20 9:30 PM, Martin Sebor wrote: > On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote: >> +  // Remove the unknown parts of a multi-range. >> +  // This will transform [5,10][20,MAX] into [5,10]. > > Is this comment correct?  Wouldn't this result in returning smaller > sizes than the actual value allows?  If so, I'd expect that to cause > false positives (and in that case, if none of our tests fail we need > to add some that would). > > By my reading of the code below it seems to return the upper range > (i.e., [20, MAX]) but I'm not fully acquainted with the new ranger > APIs yet. I believe the comment is correct. What I'm trying to do is remove [X,TYPE_MAX_VALUE] from the range >> +  int pairs = positives.num_pairs (); >> +  if (pairs > 1 >> +      && positives.upper_bound () == wi::to_wide (TYPE_MAX_VALUE >> (exptype))) >>       { >> -      if (integral) >> -    { >> -      /* Use the full range of the type of the expression when >> -         no value range information is available.  */ >> -      range[0] = TYPE_MIN_VALUE (exptype); >> -      range[1] = TYPE_MAX_VALUE (exptype); >> -      return true; >> -    } >> - >> -      range[0] = NULL_TREE; >> -      range[1] = NULL_TREE; >> -      return false; >> +      value_range last_range (exptype, >> +                  positives.lower_bound (pairs - 1), >> +                  positives.upper_bound (pairs - 1), VR_ANTI_RANGE); >> +      positives.intersect (last_range); >>       } Notice that we start with positives == vr (where vr is the range returned by determine_value_range). Then we build last_range which is the *opposite* of [X,TYPE_MAX_VALUE]. Notice the VR_ANTI_RANGE in the constructor. (Note that the nomenclature VR_ANTI_RANGE is being used in the constructor to keep with the original API. It means "create the inverse of this range". Ideally, when the m_kind field disappears along with VR_ANTI_RANGEs, the enum could become RANGE_INVERSE or something less confusing.) Finally, last_range is intersected with positives, which will become whatever VR had, minus the last sub-range. Those that make sense, or did I miss something? If you have a testcase that yields a false positive in my proposed patch, but not in the original code, please let me know so I can adjust the patch. Thanks for your feedback. Aldy