From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32839 invoked by alias); 24 Aug 2019 10:55:29 -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 32828 invoked by uid 89); 24 Aug 2019 10:55:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 24 Aug 2019 10:55:27 +0000 Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D9C1881F10 for ; Sat, 24 Aug 2019 10:55:25 +0000 (UTC) Received: by mail-io1-f71.google.com with SMTP id i6so14907866ioi.3 for ; Sat, 24 Aug 2019 03:55:25 -0700 (PDT) Received: from abulafia.quesejoda.com ([2607:fea8:a260:81::2ed3]) by smtp.gmail.com with ESMTPSA id g12sm4163890ioe.50.2019.08.24.03.55.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Aug 2019 03:55:24 -0700 (PDT) Subject: Re: types for VR_VARYING To: Martin Sebor , Richard Biener Cc: Jeff Law , gcc-patches , Andrew MacLeod References: <7719cab1-5e3a-be7a-0260-d89add495c3e@redhat.com> <9586e8af-4552-9535-5bcd-a754fa1d7ccd@redhat.com> <7357e66e-3ca6-dae1-5d22-067f5975677f@redhat.com> <65260983-0f30-d3a8-8fec-a8ccfc97db71@gmail.com> From: Aldy Hernandez Message-ID: <2e26802d-620e-151d-d334-f30ed0177eb6@redhat.com> Date: Sat, 24 Aug 2019 21:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <65260983-0f30-d3a8-8fec-a8ccfc97db71@gmail.com> Content-Type: multipart/mixed; boundary="------------C5F71B666CD0719724791630" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg01709.txt.bz2 This is a multi-part message in MIME format. --------------C5F71B666CD0719724791630 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-length: 3105 On 8/23/19 4:27 PM, Martin Sebor wrote: > On 8/15/19 10:06 AM, Aldy Hernandez wrote: >> > > Hey Aldy, > > After enabling EVRP for the strlen pass (as part of the sprintf > integration) I get a SEGV in the return statement in the function > below.  Backing out this change gets rid of the ICE and lets my > tests pass, but I have no idea what the root cause of the SEGV > might be.  The only mildly suspicious thing is the assertion in > the function: > > @@ -355,9 +369,7 @@ value_range_base::singleton_p (tree *result) const >  tree >  value_range_base::type () const >  { > -  /* Types are only valid for VR_RANGE and VR_ANTI_RANGE, which are > -     known to have non-zero min/max.  */ > -  gcc_assert (min ()); > +  gcc_assert (m_min || undefined_p ()); >    return TREE_TYPE (min ()); >  } type() should really be: tree value_range_base::type () const { gcc_assert (m_min); return TREE_TYPE (min ()); } I should post a patch to fix this. However, UNDEF should never have a type, so the assert will fail anyhow. The code asking for the type of an UNDEF is wrong. > > *this looks like so: > >   (gdb) p *this >   $55 = {m_kind = VR_UNDEFINED, m_min = 0x0, m_max = 0x0} > > so the assertion passes but the dererefence in TREE_TYPE fails. > > The test case is trivial: > >   void g (const char *a, const char *b) >   { >     if (__builtin_memcmp (a, b, 8)) >       __builtin_abort (); >   } > > The ICE happens when updating the range for the second statement > below: > >   _1 = __builtin_memcmp (a_3(D), b_4(D), 8); >   _1 = (int) _8; > > Any ideas? > > Martin > > > during GIMPLE pass: strlen > u.c: In function ‘g’: > u.c:1:6: internal compiler error: Segmentation fault >     1 | void g (const char *a, const char *b) >       |      ^ > 0x11c4d08 crash_signal >     /src/gcc/svn/gcc/toplev.c:326 > 0x815519 contains_struct_check(tree_node*, tree_node_structure_enum, > char const*, int, char const*) >     /src/gcc/svn/gcc/tree.h:3376 > 0x15e9391 value_range_base::type() const >     /src/gcc/svn/gcc/tree-vrp.c:373 > 0x16bdad6 vr_values::update_value_range(tree_node const*, value_range*) >     /src/gcc/svn/gcc/vr-values.c:237 According to your backtrace, it looks like the call to type comes from here: /* Do not allow transitions up the lattice. The following is slightly more awkward than just new_vr->type < old_vr->type because VR_RANGE and VR_ANTI_RANGE need to be considered the same. We may not have is_new when transitioning to UNDEFINED. If old_vr->type is VARYING, we shouldn't be called, if we are anyway, keep it VARYING. */ if (old_vr->varying_p ()) { new_vr->set_varying (new_vr->type ()); is_new = false; } So new_vr is UNDEFINED and we're asking for it's type. That should probably be: new_vr->set_varying (TREE_TYPE (var)); Would you mind testing the attached patch? If it passes, feel free to commit it as obvious. Thanks for catching this. Aldy --------------C5F71B666CD0719724791630 Content-Type: text/x-patch; name="p.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="p.patch" Content-length: 791 diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 8067f8560cd..97a82e6ee24 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -369,7 +369,7 @@ value_range_base::singleton_p (tree *result) const tree value_range_base::type () const { - gcc_assert (m_min || undefined_p ()); + gcc_assert (m_min); return TREE_TYPE (min ()); } diff --git a/gcc/vr-values.c b/gcc/vr-values.c index 6f9a3612931..96c764c987b 100644 --- a/gcc/vr-values.c +++ b/gcc/vr-values.c @@ -234,7 +234,7 @@ vr_values::update_value_range (const_tree var, value_range *new_vr) called, if we are anyway, keep it VARYING. */ if (old_vr->varying_p ()) { - new_vr->set_varying (new_vr->type ()); + new_vr->set_varying (TREE_TYPE (var)); is_new = false; } else if (new_vr->undefined_p ()) --------------C5F71B666CD0719724791630--