From patchwork Mon Sep 11 17:33:41 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 75672 Return-Path: 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 30A7D3858421 for ; Mon, 11 Sep 2023 17:34:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 30A7D3858421 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1694453655; bh=mEJ0GgBrkAVezdGGUSLqmBCKKp7o5VrOCthRDBcxbLw=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=kpyQHMAiUSxDYF3ecimE3jUZA5jE/TkLN6lpefp/v9xJgaxTg2NfyEF5R7wBaYIfm NnFeUHB8U63GjXp8rlPeTGUSJZIHEj/VqdQABf0yF7vZsCt1lWtZ9qiW60jDGZlET2 mcYKwZDFvoJ5GfXzCs1wl21EorIXvVezXGTkg0KA= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 DABA53858D38 for ; Mon, 11 Sep 2023 17:33:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DABA53858D38 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-490-qS-5gKeyNeOykPDgCZLmcA-1; Mon, 11 Sep 2023 13:33:44 -0400 X-MC-Unique: qS-5gKeyNeOykPDgCZLmcA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 06E8A1026447; Mon, 11 Sep 2023 17:33:44 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.209]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BDC672156701; Mon, 11 Sep 2023 17:33:43 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 38BHXf1X3694262 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 11 Sep 2023 19:33:42 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 38BHXfAu3694261; Mon, 11 Sep 2023 19:33:41 +0200 Date: Mon, 11 Sep 2023 19:33:41 +0200 To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] sccvn: Avoid ICEs on _BitInt load BIT_AND_EXPR mask [PR111338] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! The following testcase ICEs, because vn_walk_cb_data::push_partial_def uses a fixed size buffer (64 target bytes) for its construction/deconstruction of partial stores and fails if larger precision than that is needed, and the PR93582 changes assert push_partial_def succeeds (and check the various other conditions much earlier when seeing the BIT_AND_EXPR statement, like CHAR_BIT == 8, BITS_PER_UNIT == 8, BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN, etc.). So, just removing the assert and allowing it fail there doesn't really work and ICEs later on. The following patch moves the bufsize out of the method and tests it together with the other checks. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? BTW, perhaps we could increase the bufsize as well or in addition to increasing it make the buffer allocated using XALLOCAVEC, but still I think it is useful to have some upper bound and so I think this patch is useful even in that case. 2023-09-11 Jakub Jelinek PR middle-end/111338 * tree-ssa-sccvn.cc (struct vn_walk_cb_data): Add bufsize non-static data member. (vn_walk_cb_data::push_partial_def): Remove bufsize variable. (visit_nary_op): Avoid the BIT_AND_EXPR with constant rhs2 optimization if type's precision is too large for vn_walk_cb_data::bufsize. * gcc.dg/bitint-37.c: New test. Jakub --- gcc/tree-ssa-sccvn.cc.jj 2023-09-06 17:28:24.232977433 +0200 +++ gcc/tree-ssa-sccvn.cc 2023-09-08 13:22:27.928158846 +0200 @@ -1903,6 +1903,7 @@ struct vn_walk_cb_data alias_set_type first_base_set; splay_tree known_ranges; obstack ranges_obstack; + static constexpr HOST_WIDE_INT bufsize = 64; }; vn_walk_cb_data::~vn_walk_cb_data () @@ -1973,7 +1974,6 @@ vn_walk_cb_data::push_partial_def (pd_da HOST_WIDE_INT offseti, HOST_WIDE_INT maxsizei) { - const HOST_WIDE_INT bufsize = 64; /* We're using a fixed buffer for encoding so fail early if the object we want to interpret is bigger. */ if (maxsizei > bufsize * BITS_PER_UNIT @@ -5414,6 +5414,7 @@ visit_nary_op (tree lhs, gassign *stmt) && CHAR_BIT == 8 && BITS_PER_UNIT == 8 && BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN + && TYPE_PRECISION (type) <= vn_walk_cb_data::bufsize * BITS_PER_UNIT && !integer_all_onesp (gimple_assign_rhs2 (stmt)) && !integer_zerop (gimple_assign_rhs2 (stmt))) { --- gcc/testsuite/gcc.dg/bitint-37.c.jj 2023-09-08 13:27:51.676882523 +0200 +++ gcc/testsuite/gcc.dg/bitint-37.c 2023-09-08 13:27:22.460268614 +0200 @@ -0,0 +1,11 @@ +/* PR middle-end/111338 */ +/* { dg-do compile { target bitint575 } } */ +/* { dg-options "-O1" } */ + +_BitInt(575) e; + +_BitInt(575) +foo (void) +{ + return e & 1; +}