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 6052C385801F for ; Tue, 18 Jan 2022 12:31:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6052C385801F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-586-jm9eIn1dNJ6P3OMHlQw94Q-1; Tue, 18 Jan 2022 07:31:00 -0500 X-MC-Unique: jm9eIn1dNJ6P3OMHlQw94Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E831B101AFA8 for ; Tue, 18 Jan 2022 12:30:59 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.40.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 815FC29990; Tue, 18 Jan 2022 12:30:59 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20ICUvn73091659 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 18 Jan 2022 13:30:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20ICUvJq3091658; Tue, 18 Jan 2022 13:30:57 +0100 Date: Tue, 18 Jan 2022 13:30:57 +0100 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: Further address_compare fixes [PR89074] Message-ID: <20220118123057.GY2646553@tucnak> Reply-To: Jakub Jelinek References: <20220106092416.GX2646553@tucnak> <494ae254-aff9-8be9-1cee-5ee42b6db593@redhat.com> <20220118101741.GW2646553@tucnak> MIME-Version: 1.0 In-Reply-To: <20220118101741.GW2646553@tucnak> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Tue, 18 Jan 2022 12:31:09 -0000 On Tue, Jan 18, 2022 at 11:17:41AM +0100, Jakub Jelinek via Gcc-patches wrote: > Anyway, the following has been successfully bootstrapped/regtested on > x86_64-linux and i686-linux, ok for trunk? Actually, I missed one regression (thought it is caused by PR104025 patch but it is this one): +FAIL: experimental/source_location/1.cc execution test The test does (in multiple spots): VERIFY( loc.file_name() == __FILE__ ); where file_name() is constexpr and returns const char *. address_compare sees EQ_EXPR where the string literals have exactly the same bytes, but are different tree nodes. The test clearly relies on the string literal merging GCC does... To restore the previous behavior (note, this was !folding_initializer case), I need following incremental patch, i.e. make sure I don't change behavior for the !folding_initializer case. But, perhaps if we think that different STRING_CSTs with identical content should compare equal (which is likely true as expand_expr_constant -> output_constant_def should ensure that), then maybe we should earlier in address_compare for two different STRING_CSTs that have the same TREE_STRING_LENGTH memcmp the content and set equal to 0 earlier. Again, question whether to do that always, or just for !folding_initializer, or just for folding_initializer. --- gcc/fold-const.cc.jj 2022-01-18 13:10:56.864364624 +0100 +++ gcc/fold-const.cc 2022-01-18 13:25:08.057491249 +0100 @@ -16627,8 +16627,10 @@ address_compare (tree_code code, tree ty else if ((TREE_CODE (base0) == FUNCTION_DECL && ioff0) || (TREE_CODE (base1) == FUNCTION_DECL && ioff1)) return 2; - else if ((!DECL_P (base0) && TREE_CODE (base0) != STRING_CST) - || (!DECL_P (base1) && TREE_CODE (base1) != STRING_CST)) + else if ((!DECL_P (base0) + && (!folding_initializer || TREE_CODE (base0) != STRING_CST)) + || (!DECL_P (base1) + && (!folding_initializer || TREE_CODE (base1) != STRING_CST))) return 2; /* If this is a pointer comparison, ignore for now even valid equalities where one pointer is the offset zero @@ -16651,8 +16653,7 @@ address_compare (tree_code code, tree ty poly_int64 size0, size1; if (TREE_CODE (base0) == STRING_CST) { - if (!folding_initializer - || ioff0 < 0 + if (ioff0 < 0 || ioff0 > TREE_STRING_LENGTH (base0)) return 2; size0 = TREE_STRING_LENGTH (base0); @@ -16673,8 +16674,7 @@ address_compare (tree_code code, tree ty if (TREE_CODE (base1) == STRING_CST) { - if (!folding_initializer - || ioff1 < 0 + if (ioff1 < 0 || ioff1 > TREE_STRING_LENGTH (base1)) return 2; size1 = TREE_STRING_LENGTH (base1); Jakub