[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Smoking gun: NetBSD 6.0.1 userland instability
On Sat, Mar 9, 2013 at 9:21 PM, Donald Lee <MacPPC2%c.icompute.com@localhost>
> 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
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
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.
Main Index |
Thread Index |