From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-475363-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12611 invoked by alias); 29 Jan 2015 09:27:00 -0000
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
Received: (qmail 11921 invoked by uid 48); 29 Jan 2015 09:26:55 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64853] [5 Regression] wrong code at -Os and above on x86_64-linux-gnu
Date: Thu, 29 Jan 2015 09:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64853-4-uwLqyxkp62@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64853-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64853-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg03357.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64853

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Simulating block 2
Simulating block 2
Simulating block 25
Simulating block 15
Simulating block 4
Simulating block 3
Simulating block 5
Simulating block 6
Simulating block 4
Simulating block 12
Simulating block 13
Simulating block 26
Simulating block 14
Simulating block 8
Simulating block 7
Simulating block 15
Simulating block 16
Simulating block 17
Simulating block 10
Simulating block 8
Simulating block 9
Simulating block 18
Simulating block 19
Simulating block 23
Simulating block 11
Simulating block 21
Simulating block 10
Simulating block 20
Simulating block 22
Simulating block 11

So, we indeed simulate block 5 only the first time after simulating block 15
(i.e. when edge 25 -> 15 is executable and 14 -> 15 is not), and never again
(block 15 itself is simulated again with both incoming edges executable).

Wonder if for match-and-simplify during the VRP folding that looks at other
statements we shouldn't somehow note at which statements we've actually looked
when making the decision (but how?) and mark the statement for resimulation.