From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121580 invoked by alias); 18 May 2018 08:10:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 121491 invoked by uid 89); 18 May 2018 08:10:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=unshare_strinfo, complication, sk:get_str X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 May 2018 08:10:01 +0000 Received: by mail-wm0-f66.google.com with SMTP id a8-v6so12596858wmg.5 for ; Fri, 18 May 2018 01:10:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:subject:date:message-id :user-agent:mime-version; bh=aLxhYF8JHljuElYWjJVyizKidf177ayuhmNkZnJHqG4=; b=XaquF1D3Jx8UeMWSU1PUuuHe/bb4qbPfK+ZQlQZg9QrX0ik+4GV6X+iiYR7W6HiDkV iOkFcdC5yMds80uBqp/OU9fG0YB/7Z9NNBHhx+6LCgFJKE+wDJhzq0zcyDYyM+LMaIWU dUj+N4mGKZzf4CywssjQyWonq4be6pUnhEe1cd0SNnmPJfq2ua5SzVKTSPUjyED/OTA4 kcB0Ke4HxXl+b1i/BkWaVk22c7snh0RxFluGWk4Ax/R2D5TPDLntrKNykGwNwj6Aqcde ldwVt940aoYQag1KmxxVDkIXLc5Pjc9YQ7PPZ6dGoV6MgPyeBjScAkhqU9xE7dL2URVi mdeA== X-Gm-Message-State: ALKqPwcY8sW2psz+bEfGDjhs7Yodf2nelSOO93rKFBfKl7uqEdXy7h3b Y/qfSmhiRqDEB5XnMJSwNG14LIeG9l8= X-Google-Smtp-Source: AB8JxZrkGfOAs2IUmc0S8DgJuSh6y+UuWmrsSsntvrzeNjF0pUYwMEMF5M7jUeiBZsSYNU0Qt+FoCQ== X-Received: by 2002:a1c:4518:: with SMTP id s24-v6mr4074796wma.50.1526630999307; Fri, 18 May 2018 01:09:59 -0700 (PDT) Received: from localhost (116.58.7.51.dyn.plus.net. [51.7.58.116]) by smtp.gmail.com with ESMTPSA id v15-v6sm5111847wmf.47.2018.05.18.01.09.58 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 May 2018 01:09:58 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Fix tree-ssa-strlen handling of partial clobber (PR85814) Date: Fri, 18 May 2018 08:41:00 -0000 Message-ID: <87po1tmlka.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-05/txt/msg00879.txt.bz2 In this PR we have: c_5 = c_4(D) + 4; c_12 = c_5 + 1; *c_5 = 2; a = 2; // A c_21 = c_12 + 1; *c_12 = 2; a = 2; // B c_28 = c_21 + 1; *c_21 = 2; a = 2; c_7 = c_28 + 1; *c_28 = 2; where a is a global int. We decide that A can't clobber *c_5 == c_4[4] because the latter implies that c_4 is an object of 5 bytes or more, whereas a has exactly 4 bytes. The assumption for B and *c_5 is the same, but when considering B and *c_12, we only follow the definition of c_12 to c_5 + 1 (for good reason) and so have *c_12 == c_5[1]. We then don't have the same size guarantee and so assume that B could clobber *c_12. This leads to a situation in which the strinfo for c_5 is still valid but the next strinfo (c_12) isn't. We then segfaulted while trying to get the strinfo for c_21 + 1 == c_5 + 3 because get_stridx_plus_constant assumed that c_5's next strinfo (c_12) would be valid too. And of course it should be valid really. It doesn't make sense for the string based at c_5 to be valid but a substring of it to be invalid. I don't think we can guarantee that such weird corner cases never happen though, even if we tried to avoid this one. One possibility would be to mark c_12 as valid on the basis that c_5 is valid, but I'm not sure the complication is worth it given that it seems to trigger very rarely. A better optimisation would be to get the unroller to clean up after itself a bit more... Although this particular instance of the bug relies on r249880, I think we could have similar problems in GCC 7. It would be much harder to trigger though, especially since it relies on unfolded IR like the above. Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu. OK for trunk and GCC 8? Richard 2018-05-18 Richard Sandiford gcc/ PR tree-optimization/85814 * tree-ssa-strlen.c (get_stridx_plus_constant): Cope with a null return from get_strinfo when unsharing the next strinfo in the chain. gcc/testsuite/ PR tree-optimization/85814 * gcc.dg/torture/pr85814.c: New test. Index: gcc/tree-ssa-strlen.c =================================================================== --- gcc/tree-ssa-strlen.c 2018-03-13 15:06:00.657514354 +0000 +++ gcc/tree-ssa-strlen.c 2018-05-18 09:05:44.691476297 +0100 @@ -795,9 +795,9 @@ get_stridx_plus_constant (strinfo *bases si = new_strinfo (ptr, idx, build_int_cst (size_type_node, nonzero_chars), basesi->full_string_p); set_strinfo (idx, si); - if (chainsi->next) + if (strinfo *nextsi = get_strinfo (chainsi->next)) { - strinfo *nextsi = unshare_strinfo (get_strinfo (chainsi->next)); + nextsi = unshare_strinfo (nextsi); si->next = nextsi->idx; nextsi->prev = idx; } Index: gcc/testsuite/gcc.dg/torture/pr85814.c =================================================================== --- /dev/null 2018-04-20 16:19:46.369131350 +0100 +++ gcc/testsuite/gcc.dg/torture/pr85814.c 2018-05-18 09:05:44.689476382 +0100 @@ -0,0 +1,7 @@ +int a; +void b(char *c) +{ + c += 4; + for (int i = 0; i < 4; i++) + a = *c++ = 2; +}