From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-455620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11222 invoked by alias); 4 Jul 2014 04:41:57 -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 11156 invoked by uid 48); 4 Jul 2014 04:41:50 -0000
From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61306] [4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
Date: Fri, 04 Jul 2014 04:41: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.10.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thopre01 at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: thopre01 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61306-4-hquCyQoDrq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61306-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61306-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: 2014-07/txt/msg00211.txt.bz2

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

--- Comment #11 from thopre01 at gcc dot gnu.org ---
Confirmed. This is because the compiler will detect that the result of (a >> 8)
depends on the sign of a and thus prevent the optimization. Before this check
incorrect code could be generated. Of course in this case since the high bit or
discarded with a bitwise AND it is safe.

It is possible to detect this by marking the byte with unknown content with a
special marker (say 0xff) instead of cancelling the optimization and modify a
few places which checks for marker. This can be done for 4.10 but seems to me
to invasive for 4.8 and 4.9 where this patch was backported. If you disagree
with this we can discuss with the release manager once the patch made to see if
they would agree for a backport.

Thanks for your report.