[haiku-development] Re: Disabling Strict Aliasing for GCC4 Builds
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 18 Apr 2008 23:06:10 +0200
Hi Andreas, Rene and others
>> Unfortunately, I can't claim the same :/ Radeon driver fails in the
>> exact same way as before, and after removing that I wound up KDLing
> > in
>> the nforce driver ~30 seconds after starting Vision. So I'm afraid
> > I'm
>> going to have to report no discernable difference in behavior on my
>> hardware.
>
> Similar here: Today I already got three vm_page_fault KDLs, non-
> reproducible and, as before, also with SMP disabled.
>
> Any suggestion what to do about this? Any KDL output of interest?
> Might it make sense to log and start going through all the remaining
> build warnings? I noticed some about float vs. int parameters,
> uninitialized variables, comparisons of signed and unsigned,
> comparisons true due to limited range, non-virtual destructors,
> missing prototypes, among others.
Parameter format, potentially uninitialized variables (as opposed to
actually uninitialzied variables - GCC4 reports those), signedness
issues and non-virtual destructors are usually not a problem that would
throw you into KDL. These are all errors that also existed with GCC2
and they didn't trigger as many issues as seen with GCC4. This is not
to say that those shouldn't be fixed, it's just unlikely to cause as
severe problems as you are seeing.
I have now built several images (7) with different compiler options.
The second thing (after compiling with "-fno-strict-aliasing") was to
compile simply with -O0. This turned up some stuff that apparently is
inlined in normal cases and we do not provide library functions for
(__toupper, c_tolower, __ntoh and the like) which I hacked around
(enabling the inlined version or throwing the non-compiling stuff out
of the image). The binaries produced by -O0 increased by some factor,
so I also had to enlarge the image size so they would fit ;-). Despite
those issues this image seemed to work better than any other (GCC4
built) image I tested so far. Usually when I boot a GCC4 built image
with QEMU one of the first things is that the media_server crashes.
Then when starting Magnify for example this will crash too with a
similar stack crawl. With the non-optimized image this was not the case
anymore, although the reproducible crash of Tracker on shutdown stayed
the same. I therefore looked at the GCC docs and built a list of
optimizations enabled by -O2 and compared that to what GCC2 had and
would enable with -O2 (which is considerably less). I then started to
selectivly disable these options and building images until I got an
image without the crashes. And the winner is "-fno-tree-vrp -fno-tree-
pre". I checked that with the GCC bugzilla and around 4.1 (we're using
4.1.2) there are quite a lot of bug reports reporting that wrong code
is generated when using "-ftree-vrp" (value range propagation; see link
to the query below). I didn't find any relevant references to "-ftree-
pre" so I'd assume that it actually is "-ftree-vrp". I don't want to
just shove of the problem to GCC, but considering the numerous issues
that this feature apparently had I could well imagine that our GCC
4.1.2 is affected by it.
So what those with unstable GCC4 builds could try as a first step is to
add "-fno-tree-vrp" to the patch I sent in the original mail, or update
to something at or above r25016 and add this switch after "-fno-strict-
aliasing" in "build/jam/BuildSetup". You'll need to completely rebuild
the image (either through "jam -a haiku-image" or by deleting the
"generated/objects" directory). I'd be interested in the results.
In any case it would be nice if we could update our GCC4 cross-
compiler, but I assume that Ingo is going to do that anyway when he
does the native Haiku port? The current GCC4 is GCC 4.3.0 from 20080305
BTW.
Link to GCC documentation giving switches that are enabled with -O2:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options
Link to GCC bugzilla query with value range propagation problems:
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=vrp&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=product&type0-0-0=substring&value0-0-0=vrp&field0-0-1=component&type0-0-1=substring&value0-0-1=vrp&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=vrp&field0-0-3=status_whiteboard&type0-0-3=substring&valu
e0-0-3=vrp
allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=
allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc
=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&
gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=
allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=
ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&
bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=
substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id
=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=
Reuse+same+sort+as+last+time&field0-0-0=product&type0-0-0=substring&
value0-0-0=vrp&field0-0-1=component&type0-0-1=substring&value0-0-1=vrp&
field0-0-2=short_desc&type0-0-2=substring&value0-0-2=vrp&field0-0-3=
status_whiteboard&type0-0-3=substring&value0-0-3=vrp
Regards
Michael
Other related posts:
