This is the mail archive of the 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: RFC: remove the "tile" architecture from glibc

On 12/04/2017 12:10 PM, Adhemerval Zanella wrote:
I will be happy to provide these test runs. I just came from OpenJDK were
I fixed many issues with non-stream architectures and I'm happy to pick
up glibc next and try to help fix issues.

There is some time I checked glibc status on m68k (and looks like I can't
access the machine now) and I can try to see if I can make/check glibc on
the machine (I am trying to recall why exactly prevented me to so on 2.26
release window).

This particular machine (an Aranym instance) is down at the moment. I do
have an Amiga 4000 here now up and running and I also did a testsuite
run on qemu-m68k-system which eventually bails out with:

gcc /srv/glibc/build/math/test-tgmath3.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants -fno-stack-protector -frounding-math -g -Wstrict-prototypes -Wold-style-definition   -fno-builtin       -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/srv/glibc/build/math  -I/srv/glibc/build  -I../sysdeps/unix/sysv/linux/m68k/m680x0  -I../sysdeps/unix/sysv/linux/m68k  -I../sysdeps/m68k/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/m68k/m680x0/m68020  -I../sysdeps/m68k/m680x0/fpu  -I../sysdeps/m68k/m680x0  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/m68k/fpu  -I../sysdeps/m68k  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.   -D_LIBC_REENTRANT -include /srv/glibc/build/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -o /srv/glibc/build/math/test-tgmath3.o -MD -MP -MF /srv/glibc/build/math/test-tgmath3.o.dt -MT /srv/glibc/build/math/test-tgmath3.o
virtual memory exhausted: Cannot allocate memory
../ recipe for target '/srv/glibc/build/math/test-tgmath3.o' failed
make[2]: *** [/srv/glibc/build/math/test-tgmath3.o] Error 1
make[2]: Leaving directory '/srv/glibc/math'
Makefile:215: recipe for target 'math/xtests' failed
make[1]: *** [math/xtests] Error 2
make[1]: Leaving directory '/srv/glibc'
Makefile:9: recipe for target 'xcheck' failed
make: *** [xcheck] Error 2

The source code file in question is 11 MiB large:

root@pacman:/srv/glibc/build# ls -lh /srv/glibc/build/math/test-tgmath3.c
-rw-r--r-- 1 root root 11M Dec  2 19:37 /srv/glibc/build/math/test-tgmath3.c

I have already contacted the guy who has started with ia64 again on
Debian and warned him about the deprecation issue.

I would be nice if we could get access to real ia64 hardware (I tried to
use ski with mixed results).  ia64 thread stack allocation was broken
since 2.24 (d615a4735) and we just fixed it recently on master (01b87c656f)
and only though reports of Sergei Trofimovich (my ski environment did not
trigger the issue).

The guy working on ia64 in Debian is Jason Duerstock. He said, he will be
willing to provide a porterbox for ia64 soonish. I put him up in the CC
of this mail.

SH has LRA support in gcc already, if I remember correctly.

I see Linux/m68k being deprecated if and when we move to a minimum required
GCC version which does not support m68k (I do not think we have a policy
to remove deprecated architecture in GCC latest version where there is still
compiler support in older releases).

I want to try my best to avoid this. There are many people currently hacking
on Linux/m68k and there has been a tremendous effort in the past 5-6 years
to resurrect the port. We are currently successfully building 10500 source
packages on Linux/m68k out of approximately 12000 packages which I don't
think is a too bad coverage.

Now back to thread topic, Chris Metcalf gave us some indications that
tilepro userbase and support do not justify the maintaining effort.  It
already has kernel ABI incompatibilities (for instance ca768667d873 fix on
linux and some atomic unsupported operations that broke the build on
recent glibc fixes).  I think we could at least remove old tilepro

FWIW, Debian is focusing on tilegx which is currently bootstrappable
with gcc-7, see:


 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer -
`. `'   Freie Universitaet Berlin -
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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