[haiku-development] Re: Disabling Strict Aliasing for GCC4 Builds

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: