Re: RFC: remove the "tile" architecture from glibc

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 02/12/2017 13:14, John Paul Adrian Glaubitz wrote:
> On 12/01/2017 11:40 PM, Joseph Myers wrote:
>>> I will be happy to provide these results. Adhemerval has also access to one of
>>
>> We need someone to fix any major issues that show up in the results, as 
>> well as running the tests and posting the results on the wiki page during 
>> each release freeze.
> 
> 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).

> 
>>> my SH porterboxes. Also, SH is actually being redeveloped as an open
>>> source architecture called J-Core (http://j-core.org/) and they're working
>>> on releasing new, SH-compatible open source hardware over the next years.
>>> I already have J2 board at home, compatible SH-2.
>>
>> SH-2 isn't relevant to glibc (SH-4 would be).
> 
> J-Core is planning to eventually implement SH-4.
> 
>>> There is also a guy within Debian currently working on ia64 who started
>>> recently. Don't know what the current status is though.
>>
>> Well, we need a maintainer to review and commit patches (like the routine 
>> libm-test-ulps patch that was posted but has not been committed).
> 
> 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).

> 
>>> If m68k support is dropped, I'm either jumping out of the window or I'm
>>> becoming a shepheard or something. Linux/m68k is one of *the* most popular
>>> retro-platforms we have in Linux and there are lots of people in- and outside
>>> Debian working on it. The kernel is still actively maintained on m68k with
>>> at least four active maintainers that I know.
>>
>> If you want to keep m68k support in GCC, moving the port away from cc0 
>> (and then to LRA) is necessary.  The timescale suggested in 
>> <https://gcc.gnu.org/ml/gcc/2017-07/msg00231.html> was that cc0 ports 
>> could be deprecated for GCC 8 and removed for GCC 9 if not converted.  See 
>> <https://gcc.gnu.org/wiki/CC0Transition> for a guide to converting GCC 
>> ports away from cc0.
> 
> Yes, I'm aware of the LRA transition and this scares quite a lot. I don't
> know whether I have the skillset to work on gcc, so far I have committed
> merely one patch to gcc and that was only a small fix.
> 
> There is definitely demand for m68k support in gcc and glibc, the retro
> community is huge, especially because of the Amiga which has been
> refusing to die for 20 years. People have developed FPGA-based CPU
> accelerators which boost the Amiga to 600 MHz and more and with qemu-m68k-system,
> we can now emulate a Macintosh Quadra 800 machine with 1 GiB RAM and
> a 1.5 GHz CPU which helps a lot when it comes to compiling and testing
> code natively. I also have an actual Amiga running Debian unstable with
> a 4.14 kernel and glibc_2.25/gcc-7. I will run the testsuite for
> glibc-master on qemu-m68k-system for now.
> 
> 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).

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