From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-228913-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10935 invoked by alias); 5 Sep 2007 11:51:14 -0000
Received: (qmail 10523 invoked by alias); 5 Sep 2007 11:50:49 -0000
Date: Wed, 05 Sep 2007 11:51:00 -0000
Message-ID: <20070905115049.10522.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-32575-14787@http.gcc.gnu.org/bugzilla/>
Subject: [Bug middle-end/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite
In-Reply-To: <bug-32575-14787@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "dberlin at dberlin dot org" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2007-09/txt/msg00361.txt.bz2



------- Comment #7 from dberlin at gcc dot gnu dot org  2007-09-05 11:50 -------
Subject: Re:  [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of
code in SQLite

On 28 Aug 2007 15:58:29 -0000, jakub at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #6 from jakub at gcc dot gnu dot org  2007-08-28 15:58 -------
> if (a == 0) a = bar (); isn't necessary either.
>
> salias has:
>
>   # BLOCK 2 freq:10000
>   # PRED: ENTRY [100.0%]  (fallthru,exec)
>   # VUSE <qD.2026_12(D), SMT.25D.2079_13(D)> { qD.2026 SMT.25D.2079 }
>   D.2027_3 = foo ();
>   pD.2025_4 = (struct S *) D.2027_3;
>   if (pD.2025_4 == 0B)
>     goto <bb 3>;
>   else
>     goto <bb 4>;
>   # SUCC: 3 [7.3%]  (true,exec) 4 [92.7%]  (false,exec)
>
>   # BLOCK 3 freq:735
>   # PRED: 2 [7.3%]  (true,exec)
>   # qD.2026_15 = VDEF <qD.2026_12(D)>
>   # SMT.25D.2079_16 = VDEF <SMT.25D.2079_13(D)>
>   # SMT.26D.2080_17 = VDEF <SMT.26D.2080_14(D)> { qD.2026 SMT.25D.2079
> SMT.26D.2080 }
>   __builtin_memset (&qD.2026, 0, 24);
>   # SUCC: 4 [100.0%]  (fallthru,exec)
>
>   # BLOCK 4 freq:10000
>   # PRED: 2 [92.7%]  (false,exec) 3 [100.0%]  (fallthru,exec)
>   # qD.2026_11 = PHI <qD.2026_12(D)(2), qD.2026_15(3)>
>   # pD.2025_1 = PHI <pD.2025_4(2), &qD.2026(3)>
>   # qD.2026_18 = VDEF <qD.2026_11> { qD.2026 }
>   pD.2025_1->s1D.2008 = aD.2021_6(D);
>   # qD.2026_19 = VDEF <qD.2026_18> { qD.2026 }
>   pD.2025_1->s2D.2009 = bD.2022_7(D);
>
> Shouldn't the VDEFs be a PHI of some SMT and qD?
For VDEF/VUSE, you will never have a PHI of anything other than
multiple versions of the same SMT/virtual variable.

The above looks right to me at a glance.
It is probably pruning the result using TBAA which is what p->s isn't
thought to access the SMT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575