llvm-gcc-4.0/gcc/config/ns32k/STATUS

NS32K Port Status	Last updated 19 Dec 2002

Recent development of the ns32k port has been as a cross compiler. As
such a native bootstrap has not been performed.  Currently the
compiler successfully builds a NetBSD kernel and has been tested on
the testsuite with "make check" configured to remotely execute
tests on a pc532-netbsd.

There are a few remaining failures in the testsuite, none of which
result in incorrect code generation or unexpected ICEs.

Here follows comments on the outstanding testsuite failures:

gcc.c-torture/compile/20001226-1.c,  -Os
This typically fails due to a time out or exhausting available memory.
In the past it has been found to eventually compile in under 6
minutes, with consuming up to 90MB. The timeout in dejagnu is 5
minutes.

gcc.c-torture/execute/builtin-constant.c
I don't understand why this fails. Looking at the generated assembler,
the first invocation of btest returns "1" and the second "0". Presumably
the flow analysis is meant to indicate this is a "builtin constant".
The documentation for __builtin_constant says it is allowed to fail if the
compiler can't deduce that something is a constant, so the compiler is
correct if not ideal.

gcc.dg/debug/debug-1.c scan-assembler xyzzy:
At -O3 level of optimization, variable xyzzy gets eliminated. Isn't it
reasonable that the debugging info is gone too? Indeed, the
documentation says this is expected behavior.

gcc.dg/debug/debug-2.c scan-assembler xyzzy:
As for the above.

gcc.dg/20010912-1.c
PIC is supported for the compiler, but we get a link error until we get a
cross linker which can handle dynamic linking.

gcc.dg/20020304-1.c -O -fssa -fssa-ccp
ICE -fssa and -fssa-ccp are "experimental" options. Assume not a
backend problem.

gcc.dg/20021014-1.c (test for excess errors)
This is a test of the "-p" option. Fails due to lack of mcrt0.o. This
platform support "-pg" but not "-p"

gcc.dg/20021018-1.c (test for excess errors)
Fail due to lack of dynamic link support at link time.

gcc.dg/bitfld-3.c (test for excess errors)
Execution passes, but compilation produces excessive warnings. These warnings
actually seem reasonable. The code uses __attribute__((aligned (8)), and
the maximum alignment which makes any sense for this architecture is 4.

gcc.dg/duff-2.c (test for excess errors)
Execution passes, but compilation produces excessive warnings. Doesn't look
like a backend problem.

gcc.dg/uninit-A.c -O2 -Wall -S
Bogus warnings, almost certainly not backend.

gcc.dg/special/weak-1.c execution test
X  This fails for i386 too. I don't understand what the correct behavior
for this test is.

gcc.dg/special/gcsec-1.c (test for excess errors)
a.out deficiency. -ffunction-sections and -fdata-sections not supported.