Message ID | s2q1q528-18sr-6586-rr35-s2s08s8q116@fhfr.qr |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E04D33857BB3 for <patchwork@sourceware.org>; Tue, 28 Feb 2023 13:47:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E04D33857BB3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677592059; 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=rQ/dtsAc7APAmleQwSGf5JiDt9vdQYFL20iikBl3LCmM8+OspMagj6XTS447lERNx 2c2XdeAFKFALDiRGzjJtFKsw9O1e5Yd0kAIh9ONo4Uk52caLou1JUmzhe6VeExWPq1 cG0gPc1eiz/G7zL886mq9z1sXdOSQ6tMTXMLxbeA= 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 <gcc-patches@gcc.gnu.org>; 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 <rguenther@suse.de>); 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: <s2q1q528-18sr-6586-rr35-s2s08s8q116@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Richard Biener <rguenther@suse.de> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series | Fix irange::legacy_upper_bound | |
Message
Richard Biener
Feb. 28, 2023, 1:47 p.m. UTC
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.