- PR 94853 and PR 86153 are reoslved
- gfortran.dg/elemental_subroutine_3.f90 seems pass now.
- g++.dg/tls/thread_local4* added to allow list since they might random
fail on qemu, and hard to reproduce.
This testcase is used to check whether the linker is work normally when both
the --wrap=SYMBOL and -flto are set. It seems that the current fix only can
work when the wrapped symbol `SYMBOL` is defined in the other files and will be
linked. See the pr-24406-1 test, the `read` symbol is defined in the glibc’s
libc.so.6, and we will also link the libc.so.6 by the linux toolchain, so it
works. But the `read` symbol isn’t defined in the newlib, or other linked
objects or archives. Therefore, the pr-24406-1 testsuite is always failed
for riscv elf toolchain, but seems to work for riscv linux toolchain.
On the other hand, if the wrapped symbol is `read_p`, it isn't defined in the
other linked files, so we also get the error link for the linux toolchain.
The fix in upstream seems not complete. I suppose that we shoud just skip the
pr-24406-1 testcase until upstream fix or remove it.
I'm not sure what's going on here, but as far as I can tell we're optimizing
this while the test suite thinks we shouldn't be able to.
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
This resets the binutils white lists to the current failure list,
as the vast majority of old failures were fixed long ago. The
regression makefile change requires renaming report-% to report-gcc-%
so I could add an unambiguous report-binutils-% rule. Otherwise report
still works the same, and report-binutils is new.
A blank line in a log file matches nothing, when combined with grep -v it
matches everything, which means we have had no linux regression testing
since this mistake was made Sept 2017. Delete the blank lines, and add
current failures to the list with explanations, so we can re-enable regression
testing, and prevent the problem from getting worse.
This might be an actaul newlib bug: it's not providing a range error
when taking log1p of -1e80, but it appears that this triggered a glibc
bug from a while ago that may have not been fixed in newlib. I'm not
sure why the bug is just manifesting now (the newlib sources haven't
changed for a long time), but the glibc version has some macros that
force the evaluation of particular floating-point expressions (one of
which produces the range error) that don't exist in newlib.
I'm OK whitelisting the error for the next release, despite it
technically being a regression. log1p isn't a standard function, and I
doubt embedded users are going to notice. That said, we should still
fix it.
* Makefile.in (NEWLIB_NANO_TARGET_BOARDS): New.
(build-libc): Change build-newlib to stamps/build-newlib. Add
stamps/build-newlib-nano.
(check-newlib-nano, check-gcc-newlib-nano, check-binutils-newlib-nano)
(check-gdb-newlib-nano, report-newlib-nano): New.
(check-dhrystone-linux, check-dhrystone-newlib): Delete first version
of these rules.
(build-gcc-newlib-stage1): Use --with-sysroot.
(build-newlib-nano, merge-newlib-nano): New.
(build-gcc-newlib-stage2): Depend on merge-newlib-nano. Use
--with-sysroot instead of --with-headers. Also use
--with-native-system-header-dir.
(build-dejagnu): Install it.
(check-gcc-newlib, check-gcc-linux, check-dhrystone-newlib-%)
(check-dhrystone-linux-%, check-binutils-newlib, check-binutils-linux)
(check-gdb-newlib, check-gdb-linux): Drop
DEJAGNULIBS environment variable set.
(check-gcc-newlib-nano, check-dhrystone-newlib-nano)
(check-dhrystone-newlib-nano-%, check-binutils-newlib-nano)
(check-gdb-newlib-nano, report-gcc-newlib-nano)
(report-dhrystone-newlib-nano, report-binutils-newlib-nano)
(report-gdb-newlib-nano): New.
(Makefile): Add rule to rebuild when Makefile.in changes.
(test/benchmarks/dhrystone/check): Add -specs= option. Use it in
$cc commands.
Jiawei
Kito Cheng
Nelson Chu
Palmer Dabbelt
Jim Wilson
Palmer Dabbelt
Andrew Waterman