From patchwork Tue Feb 28 13:47:09 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 5940 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3021937wrd; Tue, 28 Feb 2023 05:48:14 -0800 (PST) X-Google-Smtp-Source: AK7set+Q35oadblwCBDe7Ke9fbqyEXDhiWMQr5nK6U9+5SIsKSOW0+8RrG7loBVs33UIGwYGc+8b X-Received: by 2002:aa7:dbc6:0:b0:4ac:c690:d637 with SMTP id v6-20020aa7dbc6000000b004acc690d637mr3776787edt.31.1677592094707; Tue, 28 Feb 2023 05:48:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677592094; cv=none; d=google.com; s=arc-20160816; b=cUavEMkWFJ6s0fj3nGYb8dIIE0mu3iaEmhvJGB6iG9BcTD6FkZhIHJ1TEK5Eu80sa9 57QcuI2W1Fl+lts1zxSKS2n7vTaPZRm9zIYbst2TNnex6CJ6PWohvmkTi+YSryeY7wjQ htTm+dNA8V7TIoMPWN8ZggWV3Q95isDvwuKI5T6iJHmk4lwI+27R1hKqIvEUi6lqrfmW vVwM5x3c+Ojhh9oCV1PgsO4VmIMqGy9ioRADIVee1h4EVhKGnQ6aCDhfEMdi92W9IL4a LkYGU+yxtfTUhiJzAETd8lGx61iiRYMi/zjKrHKOA4aNcZ15Y+W/f/xDluJ7G9W9OA3H Usvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:mime-version :message-id:subject:cc:to:date:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=lV6EwHhXh1OGsX0CoSXNMQzx2wA5QZZ/DaqJ1dsNqX8=; b=NrVh/FPa6xGb7GCkQm/GYJeEmzbh6Ao8R3jr8xD33rAJGeF/k56BNuEDO0rFzp0RDj jNbQS0YgRjdNEwgs1G2nCVcFFgglujQGS5Sw0STGp8mQYXTL+H1XtjFuUkACzCnZVSIB OsinpigId0rtD4ITmpIgducjGuVzjrPHvWKzi7RHDgzsoL01O8hrrReLQNcOnABpC1Zo QMd31PUvwfOkMChuNJ84KwYmgYh1nQYBb6QvnJKHb2JB6gW+wn5tCgz3R7PllhB/+mTd BC1kE61PCxeMJkcgWV4PzULcVxKnUQ/ksl/AYlJBqxjph8VrNtFWDR8jPg3TCbQj/R3M sVPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=lCulm+NP; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id r12-20020a056402018c00b004ad79746598si1646825edv.173.2023.02.28.05.48.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 05:48:14 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=lCulm+NP; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5DE413850867 for ; Tue, 28 Feb 2023 13:47:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DE413850867 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677592075; bh=lV6EwHhXh1OGsX0CoSXNMQzx2wA5QZZ/DaqJ1dsNqX8=; h=Date:To:cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=lCulm+NP9Q8Nx2Wc05TqnsIAH3pOAESAQxWZBNtkKwx7uU/tRH7wnXLSr2c4y+ESL 7O0ky3rTqB0lb0av/UOQm4rkZGitAY8/cP7RmCTpaMUyS9y4ExD5Ap8ii2jYghjEho 99K4Jl6/363r8E4d3SpX5Vd5wH3awYc2HYgMmM84= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 3EE3C3858D33 for ; Tue, 28 Feb 2023 13:47:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3EE3C3858D33 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 14E5A1FDC1; Tue, 28 Feb 2023 13:47:10 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id EB4BC13440; Tue, 28 Feb 2023 13:47:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id mhtaON0F/mMEPwAAMHmgww (envelope-from ); Tue, 28 Feb 2023 13:47:09 +0000 Date: Tue, 28 Feb 2023 14:47:09 +0100 (CET) To: gcc-patches@gcc.gnu.org cc: aldyh@redhat.com, amacleod@redhat.com Subject: [PATCH 0/5] Fix irange::legacy_upper_bound Message-ID: MIME-Version: 1.0 X-Spam-Status: No, score=-5.7 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 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-Patchwork-Original-From: Richard Biener via Gcc-patches From: Richard Biener Reply-To: Richard Biener Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759082808109360037?= X-GMAIL-MSGID: =?utf-8?q?1759082808109360037?= This series fixes irange::legacy_upper_bound behavior for VR_ANTI_RANGE (actually [4/5] does). It turns out the interesting behavior is relied on in multiple spots (maybe not so many but fixing things lead to fixing more things when trying to understand what happens). So apart from fixing this possible wrong-code issue it removes the odd behavior of calling the functions with pair == 1 which is because VR_ANTI_RANGE get num_pairs () == 2 which is because of "reasons" (the other parts of the series show what I ran into). I have bootstrapped and tested patches 1-4 together on x86_64-unknown-linux-gnu and am now testing patch 5 ontop which looked like natural cleanup here. I didn't try to construct a wrong-code testcase, ranger probably never builds legacy ranges, so I'm not sure how easy it is to get an anti-range we end up querying upper_bound on. OK for trunk or stage1? Thanks, Richard.