This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Shared Code Changes for the RISC-V Glibc Port
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Palmer Dabbelt <palmer at dabbelt dot com>, GNU C Library <libc-alpha at sourceware dot org>, <patches at groups dot riscv dot org>
- Date: Tue, 9 Jan 2018 16:16:19 +0000
- Subject: Re: Shared Code Changes for the RISC-V Glibc Port
- Authentication-results: sourceware.org; auth=none
- References: <20180106073231.20491-1-palmer@dabbelt.com> <CAKCAbMjq0=Bb9wKHwFkffW3OEebAcHWUGr=rCiakfQT1r5C5UA@mail.gmail.com>
On Sat, 6 Jan 2018, Zack Weinberg wrote:
> You cut off the top of this error message, but if this is the
> m68k-linux-gnu-coldfire configuration, it's a known and long-standing
> bug in GCC which you are not expected to do anything about. Just
> ignore that configuration. (I don't know why we still include it in
> testing, frankly, it's been broken for more than a year now.)
(This is <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467>.)
build-many-glibcs.py is supposed to test, at least, every ABI supported in
glibc - meaning it's correct for it to show failures when such a
configuration is broken. Similarly, it would be appropriate for a Hurd
configuration to be added to build-many-glibcs.py, and for it to fail
building until all the required support is upstreamed.
> The other expected unexpected failures from a build-many-glibcs run,
> if you see what I mean, are "elf/check-exec-stack" failures for
> hppa-linux-gnu, microblazeel-linux-gnu, and microblaze-linux-gnu.
> This is again a GCC bug (or rather missing feature) and Joseph didn't
> want us to mark them as expected failures for reasons which I no
> longer remember.
The correct handling of a failure should be determined case-by-case. In
these cases, I fixed those failures for GCC 8.
--
Joseph S. Myers
joseph@codesourcery.com