I currently am keeping the Haiku operating system up to date with GCC 4.4 and
trunk, with plans of eventually getting the code for our GCC port committed
into GCC's repository.
I was keeping up to date by doing builds periodically based on 4.4 snapshots,
and assumed all would be well when 4.4.1 rolled around. However, I noticed on
some Haiku revisions with later 4.4 builds, Haiku's Tracker could be easily
crashed, as well as some icons were missing. Via binary searches, I narrowed
down problematic revisions such as r31471 and r31829 in Haiku's repository.
Looking at backtraces for these crashes provides nothing that makes any sense
(and the nature of the changes didn't remotely set off any alarms), so I
decided to do a debug build of the Tracker. This built fine and worked as
expected. I then tried an -O1 build, and the Tracker was broken again. Via
binary search through the -O1 optimizations, I found that -fcprop-registers was
the problem. If I passed -fno-cprop-registers, the Tracker would build as
expected.
So, this led me to find out where things went awry. Keep in mind that I tested
the Tracker code in GCC 2.95.3, GCC 4.3.3, GCC 4.4.0, and the current trunk, up
to revision 149615. I seriously doubt the quality of the Haiku code is to
blame in this case, but I have been known to be wrong from time to time.
I did a binary search on the 4.4 branch, and noticed the change in
gcc/tree-ssa-operands.c in revision 148601 was the root of the problem. I can
build Haiku's Tracker just fine up through 148600. Not so with 148601.
I know you appreciate test code, but I don't know how easy that will be to
achieve. I admit I'm not familiar with the Tracker code or know a good way to
reduce it down to a test case. I can always try if need be though.
I also know Haiku isn't a supported port as of now, but we have to start
somewhere. I'm hoping this report can at least help out in some way in case
this issue is creeping up on other targets. :)
For reference this was a non-Graphite all static cross-compile from Linux, but
the issue also crept up when I did a full-on Graphite build of GCC. I admit I
still need to try a native build again from Haiku, but I suspect the same issue
will arise. Like I said, only GCC 4.4 branch revision 148601 and up seem
affected, and only when the cprop-registers optimization is used.
Also, here are the dependencies versions used while building:
GMP 4.3.1
MPFR 2.4.1
PPL 0.10.2
ClooG-PPL 0.15.4
(Like I said though, I didn't do many test builds with Graphite due to the
volume of builds I had to do during my binary searches.)
Lastly the only things we ever really disable in our GCC builds of Haiku are
strict-aliasing and tree-vrp optimizations if those matter.
When configuring GCC, we disable shared, nls, and multilib, and enable
languages c, c++.
Thanks a lot for any possible insight!
--
Summary: cprop-registers optimization produces invalid code as of
r148601
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joe dot prostko+gcc at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i586-pc-haiku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40896
