This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Shared Code Changes for the RISC-V Glibc Port


On Tue, Jan 9, 2018 at 11:16 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.

In view of the complete lack of progress on that bug for over a year,
I think it is inappropriate to describe the -coldfire configuration as
"supported" anymore; my recommendation would be to disable it and to
add the Coldfire-specific code in glibc to a deathwatch list, such
that if there is still no progress after, I dunno, another release or
two, it will be removed.

>  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.

I would rather see the Hurd configuration added to build-many-glibcs
as the final step in upstreaming the required support.

>> 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.

Then they should be tagged either UNSUPPORTED or XFAIL for GCC 7 and
below.  It doesn't do anyone any good to have to carry around the fact
that this is an expected failure (with older toolchains) in their
head.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]