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 Sat, Jan 6, 2018 at 2:32 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> Sorry this took a while to get to, but things got a bit busy here when everyone
> came back from vacation.  I believe I've managed to pull out all the shared
> changes and addresses the feedback to them from our v3 submission.  I've
> included ChangeLog entries for all of them, which I wouldn't usually do but I'm
> doing here just to make sure they're OK -- I managed to screw the ChangeLog
> entries up a handful of times in binutils and GCC, so I figure because it's a
> slightly different set of people here it's worth sending them out as part of
> the patches.

We (glibc reviewers) want to see ChangeLog entries with every patch
submission (as part of the commit message, *not* as modifications to
the actual ChangeLog file, which inevitably cause merge conflicts).

> I've run these through build-many-glibcs.py, and while they're not 100% clean I
> think the failures are just problems in my build environment.  I'm getting two
> failures during the compilers stage, which trigger a bunch of UNRESOLVEDs
> during the glibcs stage.  The m68k compiler fails with an ICE
>
>     0x638eb5 emit_library_call_value_1
>             /scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/calls.c:4974
>     0x63cfbe emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, int, ...)

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

The plain m68k-linux-gnu configuration, on the other hand, should work.

> and the sparc compiler fails with a #error that actually comes from a glibc
> header file
...
>      # error "Never include <bits/libio-ldbl.h> directly; use <libio.h> instead."

This was indeed an actual glibc bug, corrected by
4f820792a6217027744d38fc223257914847bbcc; update your source tree and
re-run the "compilers" phase of build-many-glibcs to get working SPARC
compilers.  (It "works for other people" because it only affects SPARC
configurations.)

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.

zw


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