OpenCores

Newlib tool chain test results

From OR1K

These are the latest results from newlib tool chain testing. Unless otherwise indicated, the tools are the SVN versions on the date shown, and record the number of tests in each test result category. For each tool an explanation is provided of any tests with a FAIL, XPASS or UNRESOLVED outcome.

Contents

binutils 2.20.1

General

                === binutils Summary ===

# of expected passes		64
# of unsupported tests		2

runtest completed at Tue Nov  2 16:03:16 2010

Linker

                === ld Summary ===

# of expected passes		131
# of unexpected failures	5
# of unexpected successes	11
# of expected failures		12
# of unsupported tests		3

runtest completed at Fri Aug 20 11:47:49 2010

FAIL tests

Check --gc-sections on tls variable
Check --gc-section
Check --gc-section/-q
Check --gc-section/-r/-e
Check --gc-section/-r/-u
--gc-sections is not actually supported for the OpenRISC 1000, yet the linker --help reports that it is, so these tests are run

XPASS tests

ld-discard/extern
ld-discard/start
ld-discard/static
ld-discard/zero-rel
ld-elf/empty2
ld-elf/group1
ld-elf/merge2
ld-elf/orphan3
ld-elf/warn1
ld-elf/warn2
weak symbols
To be investigated.

Assembler

		=== gas Summary ===

# of expected passes		108
# of expected failures		1

runtest completed at Tue Nov  2 16:04:12 2010M

GCC 4.5.1

C compiler

		=== gcc Summary ===

# of expected passes		53377
# of expected failures		84
# of unsupported tests		724

runtest completed at Wed Jun 15 15:01:44 2011

The builtins for applying functions are currently not supported on OpenRISC, which means that the builtin-apply4.c execution test occasionally fails.

C++ compiler

		=== g++ Summary ===

# of expected passes		21112
# of expected failures		149
# of unsupported tests		247

runtest completed at Wed Jun 15 15:01:53 2011

C++ library

		=== libstdc++ Summary ===

# of expected passes		5922
# of expected failures		134
# of unsupported tests		581

runtest completed at Thu Jun 16 18:17:16 2011

A number of tests require file I/O support or gettimeofday support, which is not provided in the OpenRISC newlib implementation. These tests have been marked as expecting to fail when run with OpenRISC.

Two of the standard tests will not work with newlib generically, due to a bug in the handling of wide char stream I/O and is_scan support for wide characters. These tests have been marked as expecting to fail when run with newlib.

GCC 4.8.0

These are the results of the or1k-elf-gcc (newly renamed) that is still under development.

C compiler


		=== gcc Summary ===

# of expected passes		69962
# of unexpected failures	27
# of unexpected successes	1
# of expected failures		97
# of unresolved testcases	17
# of unsupported tests		1342

FAIL tests

gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
/tmp/ccavij90.ltrans1.ltrans.o: In function `memset':
ccavij90.ltrans1.o:(.text+0x834): multiple definition of `memset'
/opt/openrisc-latest/lib/gcc/or1k-elf/4.8.0/../../../../or1k-elf/lib/libc.a(lib_a-memset.o):/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/bd-elf/or1k-elf/newlib/libc/string/../../../../../unisrc/newlib/libc/string/memset.c:47: first defined here
collect2: error: ld returned 1 exit status

The following fail with a similar issue (memset defined in two places - the test code and newlib):

gcc.c-torture/execute/builtins/memmove-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/memops-asm.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/mempcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/memset-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/memset.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/pr23484-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/snprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/stpcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/stpncpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/strcat-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/strcpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/strncat-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/strncpy-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/vsnprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.c-torture/execute/builtins/vsprintf-chk.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
gcc.dg/builtin-object-size-10.c scan-tree-dump objsz "maximum object size 21"

It looks like in the generated dump file (not sure how it's created) we have the following line:

dpkt_1: maximum object size 24

and so must be failing the check for max object size of 21.

I think this may be a problem with or1k_struct_alignment, but I'm not sure Pgavin 02:48, 25 May 2012 (CEST)
gcc.dg/pr45259.c (test for excess errors)
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr45259.c: In function 'foo':
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr45259.c:14:3: error: taking the address of a label is non-standard [-pedantic]
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr45259.c:14:3: error: taking the address of a label is non-standard [-pedantic]
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr45259.c:21:2: error: ISO C forbids 'goto *expr;' [-pedantic]

This test appears to want to generate position independent code (PIC) but I don't think we fully support that yet.

I think the problem here is that the header of pr45259.c includes:
/* { dg-options "-g -O2 -fpic -w" { target fpic } } */
which means those flags are only used when PIC is enabled. When PIC isn't use, the default flags (which includes -pedantic) are used, which causes those errors to be emitted. Adding the line:
/* { dg-options "-g -O2 -w" } */
allows the test case to pass Pgavin 02:48, 25 May 2012 (CEST)
gcc.dg/pr49994-3.c (test for excess errors)
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr49994-3.c:15:7: warning: unsupported argument to '__builtin_return_address' [enabled by default]
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr49994-3.c:17:7: warning: unsupported argument to '__builtin_return_address' [enabled by default]
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr49994-3.c:19:7: warning: unsupported argument to '__builtin_return_address' [enabled by default]
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/pr49994-3.c:21:7: warning: unsupported argument to '__builtin_return_address' [enabled by default]
We need to define INITIAL_FRAME_ADDRESS_RTX Pgavin 02:54, 25 May 2012 (CEST)
gcc.dg/stack-usage-1.c (test for excess errors)
/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/gcc/testsuite/gcc.dg/stack-usage-1.c:70:1: warning: stack usage computation not supported for this target [enabled by default]
gcc.dg/stack-usage-1.c scan-file foo\t(256|264)\tstatic
gcc.dg/stack-usage-2.c (test for bogus messages, line 9)
gcc.dg/stack-usage-2.c (test for warnings, line 16)
gcc.dg/stack-usage-2.c (test for warnings, line 26)
gcc.dg/stack-usage-2.c (test for warnings, line 33)

All of these stack tests are dubious as to whether they should be run or not. As we don't have stack usage computation (so the compiler says) maybe we can ignore these for now?

gcc.dg/visibility-14.c scan-hidden hidden[ \t_]*foo

It's not obvious what is wrong with this one. The source file has a comment:

Test that called external functions are marked.

and the generated disassembly has a call to the foo() function with just a l.jal:

l.jal foo
l.nop # nop delay slot

and is the only reference to the function there.

XPASS tests

gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized "link_error" 0/

C++ compiler

                === g++ Summary ===

# of expected passes            44118
# of unexpected failures        4
# of expected failures          278
# of unresolved testcases       2
# of unsupported tests          774

runtest completed at Tue Apr 10 06:19:43 2012

FAIL tests

g++.dg/lookup/builtin5.C scan-assembler _ZSt5atanhd

It looks like this one is failing because the generated assembly code looks like this:

.section .text.atanh,"axG",@progbits,atanh,comdat

whereas the correct output should be (generated with the -std=c++98 flag):

.section .text._ZSt5atanhd,"axG",@progbits,_ZSt5atanhd,comdat


g++.dg/lto/20090303 cp_lto_20090303_0.o assemble, -flto -flto-partition=1to1 -fPIC
/tmp/ccxdrUjL.s: Assembler messages:
/tmp/ccxdrUjL.s:246: Error: missing `)' `l.movhi r10,hi(_GLOBAL_OFFSET_TABLE_@GOTPC+1)'
/tmp/ccxdrUjL.s:247: Error: missing `)' `l.addi r10,r10,lo(_GLOBAL_OFFSET_TABLE_@GOTPC)'
/tmp/ccxdrUjL.s:250: Error: syntax error (expected char `(', found `@') `l.lwz r3,__gxx_personality_sj0@GOTOFF(r10)'
/tmp/ccxdrUjL.s:252: Error: syntax error (expected char `(', found `@') `l.lwz r3,.LLSDA1@GOTOFF(r10)'
/tmp/ccxdrUjL.s:257: Error: syntax error (expected char `(', found `@') `l.lwz r4,.L4@GOTOFF(r10)'
/tmp/ccxdrUjL.s:263: Error: syntax error (expected char `(', found `@') `l.lwz r3,j@GOTOFF(r10)'
/tmp/ccxdrUjL.s:266: Error: syntax error (expected char `(', found `@') `l.lwz r5,test_ints@GOTOFF(r10)'
Yeah, the assembler doesn't understand PIC yet. I think the @ symbol is confusing it. Pgavin 02:55, 25 May 2012 (CEST)

The following gave no output errors and appear to be due to warnings which weren't generated by the compiler:

g++.old-deja/g++.jason/rfg22.C -std=c++98 (test for errors, line 2)
g++.old-deja/g++.jason/rfg22.C -std=c++11 (test for errors, line 2)

C++ library


		=== libstdc++ Summary ===

# of expected passes		6726
# of unexpected failures	13
# of expected failures		61
# of unsupported tests		597

FAIL tests

21_strings/basic_string/append/wchar_t/3.cc execution test
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
exit(1)
21_strings/basic_string/capacity/char/18654.cc execution test
21_strings/basic_string/capacity/wchar_t/18654.cc execution test
21_strings/basic_string/cons/wchar_t/6.cc execution test
22_locale/collate/transform/char/28277.cc execution test
22_locale/collate/transform/wchar_t/28277.cc execution test
23_containers/vector/profile/vector.cc execution test
26_numerics/valarray/28277.cc execution test
27_io/basic_stringbuf/overflow/wchar_t/1.cc execution test
27_io/basic_stringbuf/setbuf/wchar_t/4.cc execution test
27_io/basic_ostream/inserters_arithmetic/wchar_t/4402.cc execution test
assertion "os2 && os2.str() == largebuf" failed: file "/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/4402.cc", line 64, function: void test02()
exit(1)
27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc execution test
assertion "oss_01.good()" failed: file "/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc", line 37, function: void test01()
exit(1)
27_io/basic_ostream/inserters_character/wchar_t/28277-2.cc execution test
assertion "oss_01.good()" failed: file "/localhome/jules/svn/opencores/openrisc/trunk/gnu-src/unisrc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-2.cc", line 40, function: void test01()
exit(1)

GDB 7.2

		=== gdb Summary ===

# of expected passes		12003
# of unexpected failures	253
# of expected failures		42
# of untested testcases		12
# of unresolved testcases	6
# of unsupported tests		107

runtest completed at Wed Jun 15 09:02:32 2011

FAIL tests

This is a work in progress, with failures currently being addressed.

UNRESOLVED tests

gdb.base/valgrind-db-attach.exp: valgrind started
valgrind not available for OpenRISC.
gdb.dwarf2/dw2-modula2-self-type.exp: set language modula-2 ptype v
Modula 2 is not supported on OpenRISC.
gdb.dwarf2/dw2-noloc.exp: no-run: print file_locaddr_resolvable
Failure to find DWARF abbreviation (number 101).
gdb.dwarf2/dw2-ref-missing-frame.exp: setting breakpoint at func_nofb
gdb.dwarf2/dw2-ref-missing-frame.exp: setting breakpoint at func_loopfb
Failure to find DWARF abbreviation (number 43).
gdb.dwarf2/dw2-unresolved.exp: setting breakpoint at main
Failure to find DWARF abbreviation (number 108).

Newlib 1.18.0

		=== newlib Summary ===

# of expected passes		23
# of unexpected failures	1

runtest completed at Tue Nov  2 16:06:59 2010

FAIL tests

newlib.locale/UTF-8.c output
This is a failure to select a new language locale. This may be due to the absence of a file system, but more investigation is needed.

© copyright 1999-2016 OpenCores.org, equivalent to ORSoC AB, all rights reserved. OpenCores®, registered trademark.