From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-438101-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24070 invoked by alias); 19 Dec 2013 11:22:24 -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 23866 invoked by uid 48); 19 Dec 2013 11:22:21 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu
Date: Thu, 19 Dec 2013 11:22: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: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59387-4-LkMncCyEqE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59387-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59387-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: 2013-12/txt/msg01756.txt.bz2

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems it is SCCP that breaks this.
We have a loop like:
  <bb 4>:
  c.2_10 = (unsigned char) c_lsm.11_20;
  _11 = c.2_10 + 255;
  c.3_12 = (char) _11;
  _14 = b_f1_lsm.12_7 + 1;

  <bb 5>:
  # c_lsm.11_20 = PHI <c_lsm.11_15(3), c.3_12(4)>
  # b_f1_lsm.12_7 = PHI <0(3), _14(4)>
  if (b_f1_lsm.12_7 <= 23)
    goto <bb 4>;
  else
    goto <bb 6>;

  <bb 6>:
  # b_f1_lsm.12_36 = PHI <b_f1_lsm.12_7(5)>
  # c_lsm.11_40 = PHI <c_lsm.11_20(5)>

where c.2/c.3/c_lsm.11 is signed char.  Note the c decrement done carefully in
unsigned char type.
But then comes sccp and does:
final value replacement:
  c_lsm.11_40 = PHI <c_lsm.11_20(5)>
  with
  c_lsm.11_40 = c_lsm.11_15 + -24;
which is invalid, because it is subtracted in signed type instead of the
unsigned type originally.  Dunno if scev remembers somewhere what type the
arithmetics has been actually performed in.  Richard, can you please have a
look?