Re: Smoking gun: NetBSD 6.0.1 userland instability

[Donald Lee <MacPPC2%c.icompute.com@localhost>]

At 1:18 PM -0700 3/12/13, Jake Hamby wrote:
>On Sat, Mar 9, 2013 at 9:21 PM, Donald Lee <MacPPC2%c.icompute.com@localhost> 
>wrote:
>> I looked more carefully at the results with the analog built with
>> "gcc -O0 ...".  It still fails, and in very similar ways to the
>> optimized version.
>>
>> It appears to fail with less frequency, but it still fails.
>>
>> I might try the -no-altivec options now....
>
>
>There's definitely at least one GCC bug related to Altivec code
>generation that I know is present in GCC versions > 4.2. I did some
>work last year to try to port the V8 JavaScript engine to PowerPC. I
>don't have anything to share yet, but what I've done so far was to
>find and fix a bunch of byte ordering issues by using the ARM code
>generator with the ARM simulator (a real port needs to generate PPC
>instructions).
>
>I got all of the V8 self-tests to pass on Mac OS X, but only with GCC
>4.2.1 (which doesn't seem to emit Altivec instructions for normal
>code) or with newer versions of GCC plus "-mno-altivec" (I was using
>"-mcpu=G5" in either case). There are a few additional test cases that
>failed on Linux/PPC that might be glibc-related.
>
>There are also a few specific V8 test cases that are failing with
>Altivec enabled that I haven't had time to debug. There are only a few
>places in the V8 code where Altivec instructions are generated when
>compiled for an Altivec-supporting CPU, so the bug must be in one of
>those locations. It seems to affect GCC 4.6, 4.7, and 4.8, but not
>4.2.1 (which generates the same code with or without "-mno-altivec").
>
>I'm trying to figure out a GCC bug on VAX right now, and then I'll
>probably return to this Altivec issue on PPC, since it's going to
>affect a lot of people. In the meantime, I'm building everything with
>"-mno-altivec" and I would recommend that approach to everyone until
>this bug is tracked down. "-mno-altivec" should probably be added to
>the default CFLAGS for NetBSD builds, in fact.
>
>Regards,
>Jake

Thank you for your note.

Two things:

First, I'm confused about "-mno-altivec".  On NetBSD 6.0.1, the compiler appears
to be 4.5.3:

mercy$ cc -v
Using built-in specs.
COLLECT_GCC=cc
Target: powerpc--netbsd
Configured with: /usr/src2/tools/gcc/../../external/gpl3/gcc/dist/configure 
--target=powerpc--netbsd --enable-long-long --enable-threads 
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD 
nb2 20111202' --enable-__cxa_atexit 
--with-mpc=/var/obj/mknative/macppc/usr/src2/destdir.macppc/usr 
--with-mpfr=/var/obj/mknative/macppc/usr/src2/destdir.macppc/usr 
--with-gmp=/var/obj/mknative/macppc/usr/src2/destdir.macppc/usr --enable-tls 
--disable-multilib --disable-symvers --disable-libstdcxx-pch 
--build=x86_64-unknown-netbsd5.99.56 --host=powerpc--netbsd
Thread model: posix
gcc version 4.5.3 (NetBSD nb2 20110806) 

From what you write above, it sounds like "-mno-altivec" may not do anything.
My gcc version is not listed.  What would you expect -mno-altivec to do on
4.5.3, and how should I expect the resulting code to behave?

Second, the problem I am seeing is not likely to be a compiler problem,
unless the compiler generates code that is non-deterrministic.
I do not deny that that is possible, but it is supposed to be at least
hard.  No matter what code gcc generates, good or bad, running the
code should result in the same execution given the same environment and
input.  I am seeing differnt results on every run.  My most recent runs
are done with an analog built with "-O0", which I sort of presume
avoids alti-vec completely, right?

Should I try "-mno-altivec" on the CFLAGS and build another analog?

Thanks,

-dgl-