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.129.124]) by sourceware.org (Postfix) with ESMTPS id 07CC83858D1E for ; Tue, 21 May 2024 21:01:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 07CC83858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 07CC83858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716325296; cv=none; b=ZjbqIPLI/FTl999qtad7HVoC+OtPiJ3TmOQPiVuj0RBCia8gqbfUrQF2bEkSiFgEf3wi5oidMOL4D/eL0IrJjIT05gLHYQ37byK4vkaE5tXz4heYhAlcZBheXy3las6wHjW1zK6Lz7W6Af7hcXNPWUFSLe6hJqxX0oxUZ/4edtQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716325296; c=relaxed/simple; bh=3nCvrtR9qqMCwP3eIOz80ivsick9kzboOZ9isQYKtZs=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=DFmiGM+zGfbel1tdMNOOKfpASj44W1eMlFSLHiwxpGw9gZjv29z1Ij2UU2ekN+kBEGBxfjMlHlfT+WNOYdtvFQbXc6SVAk79akSfgG6LU45Q8b2Iry+aGKSS93VPC494shrkiO7w+4hlGfJBmwWjgLFrJJhu4ZyuHnCXIz0Uc98= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716325294; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=GgbtnPTwrR4EwpwenXUFz2moo9AZQpR7JcBxpvqP+o8=; b=cffdwB9UtXgml9/mn69IoIcdRZYOUy9NnlR14wl6YU2NIXTFmZ6W6VlEWUNjN8uNVSZHGa 6xrj+yv1rVx4fMveGurYehB3BEmiVulQdK9Q9AgYB48E6Q/jxeN//d3vMEdC5m1Np4n6B9 YDag5HjpSYPAH67FIX8BYvWQVfxMc4o= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-441-yVrqztrkOx-0-1huy4xvzQ-1; Tue, 21 May 2024 17:01:30 -0400 X-MC-Unique: yVrqztrkOx-0-1huy4xvzQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 083A4380673B; Tue, 21 May 2024 21:01:30 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C0B1D3C27; Tue, 21 May 2024 21:01:29 +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 44LL1SgW2417489 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 21 May 2024 23:01:28 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 44LL1RLW2417488; Tue, 21 May 2024 23:01:27 +0200 Date: Tue, 21 May 2024 23:01:27 +0200 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] strlen: Fix up !si->full_string_p handling in count_nonzero_bytes_addr [PR115152] Message-ID: Reply-To: Jakub Jelinek MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 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=-3.6 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_H4,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 List-Id: Hi! The following testcase is miscompiled because strlen_pass::count_nonzero_bytes_addr doesn't handle correctly the !si->full_string_p case. If si->full_string_p, it correctly computes minlen and maxlen as minimum and maximum length of the '\0' terminated stgring and clears *nulterm (ie. makes sure !full_string_p in the ultimate caller) if minlen is equal or larger than nbytes and so '\0' isn't guaranteed to be among those bytes. But in the !si->full_string_p case, all we know is that there are [minlen,maxlen] non-zero bytes followed by unknown bytes, so effectively the maxlen is infinite (but caller cares about only the first nbytes bytes) and furthermore, we never know if there is any '\0' char among those, so *nulterm needs to be always cleared. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and affected release branches? 2024-05-21 Jakub Jelinek PR tree-optimization/115152 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes_addr): If !si->full_string_p, clear *nulterm and set maxlen to nbytes. * gcc.dg/pr115152.c: New test. --- gcc/tree-ssa-strlen.cc.jj 2024-04-29 11:00:45.000000000 +0200 +++ gcc/tree-ssa-strlen.cc 2024-05-21 13:43:31.031208000 +0200 @@ -4829,7 +4829,7 @@ strlen_pass::count_nonzero_bytes_addr (t if (maxlen + 1 < nbytes) return false; - if (nbytes <= minlen) + if (nbytes <= minlen || !si->full_string_p) *nulterm = false; if (nbytes < minlen) @@ -4839,6 +4839,9 @@ strlen_pass::count_nonzero_bytes_addr (t maxlen = nbytes; } + if (!si->full_string_p) + maxlen = nbytes; + if (minlen < lenrange[0]) lenrange[0] = minlen; if (lenrange[1] < maxlen) --- gcc/testsuite/gcc.dg/pr115152.c.jj 2024-05-21 13:46:02.793214348 +0200 +++ gcc/testsuite/gcc.dg/pr115152.c 2024-05-21 12:49:38.791626073 +0200 @@ -0,0 +1,17 @@ +/* PR tree-optimization/115152 */ +/* { dg-do run } */ +/* { dg-options "-O3 -fno-tree-fre -fno-tree-dominator-opts -fno-tree-loop-im" } */ + +int a, b, c, d; +signed char e[1] = { 1 }; + +int +main () +{ + for (a = 0; a < 3; a++) + for (b = 0; b < 2; b++) + c = e[0] = e[0] ^ d; + if (!c) + __builtin_abort (); + return 0; +} Jakub