From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 0D85E385800D for ; Mon, 22 Nov 2021 08:41:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D85E385800D Received: by mail-ed1-x52d.google.com with SMTP id x6so61629076edr.5 for ; Mon, 22 Nov 2021 00:41:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=91xqRYCkg33LtRJauNi8DNxugEXu9SsTJpu37W40mCI=; b=PG9G+VmlLHxtfgbGx8Iagmw99mUv95Yl1WYia6DB84RoOnLkB8D7aEPY8u3y0Sd7yL UjmHdKUHdMZeqe9bRwWAHqs6mtu6eqQ7Oyi62WaLkxzHsi4+VCJWL44fazQrDuUZPzkt ZpCrs03ppOWH+ZOI2VQpFtrKUCOwX+kmJ+Fg15pO1nj2G39K6f80w/kpgpzr9hBZ37pm Rac5+yUb6LY9SFDX1g97hfPR+TOwYtzycpmrsbP1uBTLd5v8rmkEfil4EsWgqXAbmBHn 2gf78N3sqecAfNdXfIa2PEvti6QXnSfN8g+rX1eszNw7mqZBYEpH1JBio8XhIZNa5vp9 HE6Q== X-Gm-Message-State: AOAM533kUNWt9nzTMPkyplz/zCcbtq7jvQBRBOIHkX4n1u6UT0CjfS5/ 9HUIDqJTIIPr3H9tQpqxx6wuf05Xg32YnxnvNJo= X-Google-Smtp-Source: ABdhPJxqMmCeY2YSbA3XCNHTXFYLBVTwfsOldTtxV8n+Re37B+nVQ3LnWO1+9Q4pcVCNPKT84+wzvohHyavJTu595+w= X-Received: by 2002:a17:906:c301:: with SMTP id s1mr37888074ejz.56.1637570475774; Mon, 22 Nov 2021 00:41:15 -0800 (PST) MIME-Version: 1.0 References: <20211109190137.1107736-1-siddhesh@gotplt.org> <20211109190137.1107736-4-siddhesh@gotplt.org> <20211119170639.GT2646553@tucnak> <7915f97c-54ca-1d23-506a-bc916620c12a@gotplt.org> <20211119191637.GU2646553@tucnak> In-Reply-To: <20211119191637.GU2646553@tucnak> From: Richard Biener Date: Mon, 22 Nov 2021 09:41:04 +0100 Message-ID: Subject: Re: [PATCH 03/10] tree-object-size: Use tree instead of HOST_WIDE_INT To: Jakub Jelinek Cc: Siddhesh Poyarekar , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 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 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 22 Nov 2021 08:41:18 -0000 On Fri, Nov 19, 2021 at 8:17 PM Jakub Jelinek via Gcc-patches wrote: > > On Sat, Nov 20, 2021 at 12:31:19AM +0530, Siddhesh Poyarekar wrote: > > > Neither of these are equivalent to what it used to do before. > > > If some target has e.g. pointers wider than size_t, then previously we could > > > compute bytes that doesn't fit into size_t and would return NULL which > > > eventually would result in object_sizes_execute or expand_builtin_object_size > > > resolving it to the unknown value. But fold_convert will perform modulo > > > arithmetics on it, so say if size_t is 24-bit and bytes is 0x1000001, it > > > will fold to (size_t) 1. I think we should still punt if it doesn't fit. > > > Or do we ensure that what it returns always has sizetype type? > > > > compute_builtin_object_size should always return sizetype. I probably > > haven't strictly ensured that but I could do that. Would it be necessary to > > check for fit in sizetype -> size_type_node conversion too? I've been > > assuming that they'd have the same precision. > > sizetype and size_type_node should be indeed always the same precision. I don't think so. vms.h has /* Always a 32 bit type. */ #undef SIZE_TYPE #define SIZE_TYPE "unsigned int" ... #define SIZETYPE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? \ "unsigned int" : "long long unsigned int") interestingly that's the _only_ SIZETYPE override we have, so it does look like we might want to try removing the 'SIZETYPE' target macro. I'm not sure the above does anything good - it looks more like a ptr_mode vs Pmode thing. Richard. > Jakub >