IA-64 GCC deprecation?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

IA-64 GCC deprecation?

Jim Wilson
There is a proposal to deprecate the IA-64 GCC port as it no longer
has a maintainer.  I resigned as maintainer a few weeks ago as I don't
have time for IA-64 work anymore.  See
    https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

John Paul Adrian Glaubitz
On 6/13/19 8:06 PM, Jim Wilson wrote:
> There is a proposal to deprecate the IA-64 GCC port as it no longer
> has a maintainer.  I resigned as maintainer a few weeks ago as I don't
> have time for IA-64 work anymore.  See
>     https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html

I don't understand why it would be so important to deprecate ia64 so quickly
now given the fact that both Debian and Gentoo are actively working on the
port.

Is there anything that the ia64 backend is currently blocking in gcc?

Adrian

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

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
On Thu, Jun 13, 2019 at 11:31 AM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> I don't understand why it would be so important to deprecate ia64 so quickly
> now given the fact that both Debian and Gentoo are actively working on the
> port.

The IA-64 port has been broken on and off ever since we added some
qsort checking.  That happened in Sept 2017.  So the port has been
broken for about a year and a half now.

Intel has already announced EOL for IA-64 in Fall of 2020.  The next
gcc release is spring 2020, so not clear that we need support for a
soon to be dead processor.  You can still use old gcc versions for
IA-64, it just wouldn't be supported in new releases if it gets
deprecated.

I wasn't aware of a gentoo IA-64 effort, but checking, it looks like
gentoo-ia64 has no email since October 2006.  That doesn't look like
an active project.

> Is there anything that the ia64 backend is currently blocking in gcc?

We still get bug reports for it.  Someone has to answer the bug
reports.  If there is no dedicated IA-64 maintainer, then one of the
global maintainers has to handle it, and they don't want to do this
work.

Sometimes we have to make global changes to gcc which require changes
to multiple backends.  The general process is to test every backend
that is touched, but if you have to touch the ia64 backend, and the
ia64 backend is broken, then you can't touch it.  People don't like
making blind changes that they can't properly test.

There are some optimization passes and infrastructure features that
are used primarily or only by the IA-64 backend.  If we can deprecate
the ia64 port, then we can perhaps deprecate these features, which
then lowers the maintenance burden for people working on other parts
of the compiler.

This all hinges on whether the IA-64 port has a maintainer or not.  If
someone here wants to volunteer as the IA-64 port maintainer, then you
can keep the port alive for a while longer.  It is still likely to be
deprecated eventually though.  There are so many things that are
different about IA-64 than everything else that gcc supports that this
creates a maintenance burden even for people who aren't doing IA-64
work.  So it is really only practical to keep it alive if it has
value, and an EOL processor doesn't have much value.

I was keeping the IA-64 alive for a few years by serving as a token
maintainer, but my RISC-V work has increased to the point where I
can't reasonably pretend to be the IA-64 maintainer anymore.  So now
that there is no official maintainer they want to deprecate it.

If you care about this, I would suggest contributing to the thread on
the gcc mailing list.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

John Paul Adrian Glaubitz
On 6/13/19 9:06 PM, Jim Wilson wrote:
> On Thu, Jun 13, 2019 at 11:31 AM John Paul Adrian Glaubitz
> <[hidden email]> wrote:
>> I don't understand why it would be so important to deprecate ia64 so quickly
>> now given the fact that both Debian and Gentoo are actively working on the
>> port.
>
> The IA-64 port has been broken on and off ever since we added some
> qsort checking.  That happened in Sept 2017.  So the port has been
> broken for about a year and a half now.

It can't be that broken otherwise it wouldn't be possible to build about
80% of the Debian archive, large part of the unbuildable stuff being
Rust and Golang:

> https://buildd.debian.org/stats/graph-ports-big.png

> Intel has already announced EOL for IA-64 in Fall of 2020.  The next
> gcc release is spring 2020, so not clear that we need support for a
> soon to be dead processor.  You can still use old gcc versions for
> IA-64, it just wouldn't be supported in new releases if it gets
> deprecated.

At least in Debian unstable we can't use old gcc version, no. Debian
unstable always defaults to the latest upstream stable version as the
default compiler which is why it's somewhat annoying that gcc upstream
has decided to push out releases every year now.

> I wasn't aware of a gentoo IA-64 effort, but checking, it looks like
> gentoo-ia64 has no email since October 2006.  That doesn't look like
> an active project.

You have to look at their git repository:

> https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=grep&q=ia64

Last ia64-related commit was just 5 hours ago.

>> Is there anything that the ia64 backend is currently blocking in gcc?
>
> We still get bug reports for it.  Someone has to answer the bug
> reports.  If there is no dedicated IA-64 maintainer, then one of the
> global maintainers has to handle it, and they don't want to do this
> work.

Is it really true that bug reports _must_ be handled? And if downstream
projects like Debian and Gentoo provide patches, what's wrong with merging
them?

> Sometimes we have to make global changes to gcc which require changes
> to multiple backends.  The general process is to test every backend
> that is touched, but if you have to touch the ia64 backend, and the
> ia64 backend is broken, then you can't touch it.  People don't like
> making blind changes that they can't properly test.

I understand that. But if something in the ia64 backend breaks, Debian
and Gentoo get to keep the pieces (and will eventually send in the
patches to fix them).

> There are some optimization passes and infrastructure features that
> are used primarily or only by the IA-64 backend.  If we can deprecate
> the ia64 port, then we can perhaps deprecate these features, which
> then lowers the maintenance burden for people working on other parts
> of the compiler.

I know that argument and I have heard it before but whenever I asked
for a particular example which code in question of a backend would
block something else, I never received an answer.

> This all hinges on whether the IA-64 port has a maintainer or not.  If
> someone here wants to volunteer as the IA-64 port maintainer, then you
> can keep the port alive for a while longer.  It is still likely to be
> deprecated eventually though.  There are so many things that are
> different about IA-64 than everything else that gcc supports that this
> creates a maintenance burden even for people who aren't doing IA-64
> work.  So it is really only practical to keep it alive if it has
> value, and an EOL processor doesn't have much value.

Well, every backend is going to be deprecated at some point, isn't it?

> I was keeping the IA-64 alive for a few years by serving as a token
> maintainer, but my RISC-V work has increased to the point where I
> can't reasonably pretend to be the IA-64 maintainer anymore.  So now
> that there is no official maintainer they want to deprecate it.
>
> If you care about this, I would suggest contributing to the thread on
> the gcc mailing list.

I would like to see first what others on this list have to say.

Adrian

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

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> Is it really true that bug reports _must_ be handled? And if downstream
> projects like Debian and Gentoo provide patches, what's wrong with merging
> them?

They don't necessarily have to be fixed.  There just needs to be
someone willing to accept responsibility for them, so that the global
maintainers can say "it's not my problem; it's his/her problem".
After all, I haven't done much IA-64 work over the last few years, and
only fixed a few token problems, but that was good enough that
everyone could point at me and say it was my problem if something
broke.  Fortunately, backends rarely are responsible for breaking
other things, so in practice this isn't much work.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
In reply to this post by John Paul Adrian Glaubitz
On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> I know that argument and I have heard it before but whenever I asked
> for a particular example which code in question of a backend would
> block something else, I never received an answer.

It is hard to produce good examples on demand, as some of these things
tend to be temporary problems, and someone just gets impatient enough
that they just make a blind fix to the targets that can't be properly
tested.

A possible example here is LRA.  This is a new local register
allocation pass that is intended to replace the very old reload pass.
For now, some ports are continuing to use reload.  Some ports are
using LRA.  Generally, the well maintained ports are using LRA because
it has a number of advantages, and the poorly maintained ports are
still using reload.  We would like to eventually obsolete the reload
code, but we can't do that until every port switches over.  Meanwhile,
we have to maintain two very different register allocation passes that
do the same thing, which is twice as much work as only having one of
them.  So we'd really like to see all ports switch over to LRA.  IA-64
is one of the ports that hasn't switched yet.  Most of the unfixed
ports are embedded targets, and eventually someone will get impatient
enough to fix them even though they don't care about the target, using
a simulator to test it.  But IA-64 is a server part, not an embedded
part, so in theory requires more testing.  Also, there is no free
simulator for IA-64 that I know of which makes the testing harder.
However, there are over 20 targets that don't have LRA support yet, so
the IA-64 port is not a blocking factor here yet.  There are people
slowly converting random embedded ports over though, so eventually
IA-64 will be a blocking factor if it doesn't get fixed.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jason Duerstock-3
Regarding LRA, I saw this coming and started working on it here:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90785
Judging from the similar SH4 PR, I understand this isn't a trivial thing to fix.
Is there any reason I couldn't become the ia64 maintainer, assuming there was someone available to act as my general gcc mentor?

Jason

On Thu, Jun 13, 2019 at 5:24 PM Jim Wilson <[hidden email]> wrote:
On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> I know that argument and I have heard it before but whenever I asked
> for a particular example which code in question of a backend would
> block something else, I never received an answer.

It is hard to produce good examples on demand, as some of these things
tend to be temporary problems, and someone just gets impatient enough
that they just make a blind fix to the targets that can't be properly
tested.

A possible example here is LRA.  This is a new local register
allocation pass that is intended to replace the very old reload pass.
For now, some ports are continuing to use reload.  Some ports are
using LRA.  Generally, the well maintained ports are using LRA because
it has a number of advantages, and the poorly maintained ports are
still using reload.  We would like to eventually obsolete the reload
code, but we can't do that until every port switches over.  Meanwhile,
we have to maintain two very different register allocation passes that
do the same thing, which is twice as much work as only having one of
them.  So we'd really like to see all ports switch over to LRA.  IA-64
is one of the ports that hasn't switched yet.  Most of the unfixed
ports are embedded targets, and eventually someone will get impatient
enough to fix them even though they don't care about the target, using
a simulator to test it.  But IA-64 is a server part, not an embedded
part, so in theory requires more testing.  Also, there is no free
simulator for IA-64 that I know of which makes the testing harder.
However, there are over 20 targets that don't have LRA support yet, so
the IA-64 port is not a blocking factor here yet.  There are people
slowly converting random embedded ports over though, so eventually
IA-64 will be a blocking factor if it doesn't get fixed.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Frank Scheiner
On 6/14/19 16:29, Jason Duerstock wrote:
> Is there any reason I couldn't become the ia64 maintainer, assuming
> there was someone available to act as my general gcc mentor?

That's great news! Thanks, Jason, for taking over maintenance and
thanks, Jim, for keeping it alive until recently.

Also, my thanks to all people involved in getting Debian back on ia64,
that's - again - Jason, Adrian and James and possibly many more.

My Integrities are looking forward into a bright future. :-D And I hope
that my descendants will still be able to use them for their liking.

Because as long as there's software for a specific hardware, that
hardware **is** useful IMHO. Devaluation of hardware in my eyes does not
come through so-called product obsolescence - hardware never has any
practical value without software - but by "trashing" key software which
originally was created with a lot of effort.

Cheers,
Frank

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
In reply to this post by Jason Duerstock-3
On Fri, Jun 14, 2019 at 7:30 AM Jason Duerstock
<[hidden email]> wrote:
> Regarding LRA, I saw this coming and started working on it here:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90785
> Judging from the similar SH4 PR, I understand this isn't a trivial thing to fix.

Yes, which is why some folks would rather get rid of the IA-64 port
than try to fix it themselves.

> Is there any reason I couldn't become the ia64 maintainer, assuming there was someone available to act as my general gcc mentor?

Yes, I suppose that I can act as a mentor.  I'm extremely busy with
RISC-V stuff though, so I may not have much time to help.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
In reply to this post by Frank Scheiner
On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <[hidden email]> wrote:
> Because as long as there's software for a specific hardware, that
> hardware **is** useful IMHO. Devaluation of hardware in my eyes does not
> come through so-called product obsolescence - hardware never has any
> practical value without software - but by "trashing" key software which
> originally was created with a lot of effort.

There is no proposal to "trash" any gcc release that contains IA-64
support.  There is only a proposal to drop it from future releases.

It is important to keep in mind that software does not magically keep
working after being written.  Someone has to maintain it.  That takes
time and energy.  It isn't fair to force that burden onto the GCC
global maintainers when there is no one that cares enough about IA-64
to maintain it themselves.  Maintenance is a significant long term
cost, and GCC does not have infinite time and people to do this work.
We have to focus most our time and energy on the targets that have the
most users.  And when there is a target with few users that falls into
disrepair and remains broken for a long time, we have to deprecate it.
Also, it is important to note that IA-64 has a higher than normal
maintenance burden, because there are so very many things it does that
are different from other targets.

If you want the port to survive, then someone who cares about it will
have to maintain it.  We have pdp11, vax, and m68k ports for instance
because each one has a volunteer that is keeping it alive, so that the
global maintainers don't have to fix it themselves.

Another issue here, if gcc maintainers can't get access to IA-64
hardware or simulators, how are they supposed to maintain the IA-64
gcc port?  Most of the lesser gcc targets have freely available
simulators that make it easy for anyone to test gcc without access to
hardware.  That is a serious problem for IA-64.  QEMU dropped the
IA-64 support Nov 2017.  I don't think that ski is maintained anymore
either.  IA-64 hardware is expensive, and soon won't be manufactured
anymore.  This is going to make continued maintenance even harder.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Frank Scheiner
On 6/16/19 01:14, Jim Wilson wrote:
> On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <[hidden email]> wrote:
>> Because as long as there's software for a specific hardware, that
>> hardware **is** useful IMHO. Devaluation of hardware in my eyes does not
>> come through so-called product obsolescence - hardware never has any
>> practical value without software - but by "trashing" key software which
>> originally was created with a lot of effort.
>
> There is no proposal to "trash" any gcc release that contains IA-64
> support.  There is only a proposal to drop it from future releases.

Don't worry, that was not meant as criticism of you or the gcc
maintainers - otherwise I wouldn't have expressed my thanks for your
work in the same email, wouldn't I? :-)

I just felt the need to express a different opinion on your earlier
"[...] an EOL processor doesn't have much value.".

> It is important to keep in mind that software does not magically keep
> working after being written.

It also doesn't magically stop working, there's always a reason behind
when it stops working. I.e. I can think of hardware defects, environment
changes or changes to its dependencies or even changes to the compiler.
So my general assumption is that a lot of issues for software -
especially on non-mainstream architectures - are artificially created
nowadays.

>  Someone has to maintain it. That takes
> time and energy.  It isn't fair to force that burden onto the GCC
> global maintainers when there is no one that cares enough about IA-64
> to maintain it themselves.  Maintenance is a significant long term
> cost, and GCC does not have infinite time and people to do this work.

Please understand that I'm totally with you here.

> We have to focus most our time and energy on the targets that have the
> most users.

How do you measure that - I mean, that ia64 doesn't have that many users
is out of the question - but still, how do you determine that?

> [...]
> Another issue here, if gcc maintainers can't get access to IA-64
> hardware or simulators, how are they supposed to maintain the IA-64
> gcc port?  Most of the lesser gcc targets have freely available
> simulators that make it easy for anyone to test gcc without access to
> hardware.  That is a serious problem for IA-64.  QEMU dropped the
> IA-64 support Nov 2017.  I don't think that ski is maintained anymore
> either.  IA-64 hardware is expensive, and soon won't be manufactured
> anymore.  This is going to make continued maintenance even harder.

Doesn't e.g. Debian have ia64 development machines available? Could
using these be an option for gcc maintainers perhaps?

Apart from that: ski was still good enough for debugging an issue on
ia64 in 2018 (see [1]).

Cheers,
Frank

[1]:
http://trofi.github.io/posts/210-ptrace-and-accidental-boot-fix-on-ia64.html

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

John Paul Adrian Glaubitz
In reply to this post by Jim Wilson
On 6/13/19 10:54 PM, Jim Wilson wrote:
> They don't necessarily have to be fixed.  There just needs to be
> someone willing to accept responsibility for them, so that the global
> maintainers can say "it's not my problem; it's his/her problem".

And it seems Jason Duerstock is willing to do that.

> After all, I haven't done much IA-64 work over the last few years, and
> only fixed a few token problems, but that was good enough that
> everyone could point at me and say it was my problem if something
> broke.  Fortunately, backends rarely are responsible for breaking
> other things, so in practice this isn't much work.

So, it seems there isn't much pressure then to get rid of the backend
as soon as possible.

Adrian

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

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

John Paul Adrian Glaubitz
In reply to this post by Jim Wilson
On 6/16/19 12:56 AM, Jim Wilson wrote:
> On Fri, Jun 14, 2019 at 7:30 AM Jason Duerstock
> <[hidden email]> wrote:
>> Regarding LRA, I saw this coming and started working on it here:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90785
>> Judging from the similar SH4 PR, I understand this isn't a trivial thing to fix.
>
> Yes, which is why some folks would rather get rid of the IA-64 port
> than try to fix it themselves.

Regarding LRA, I can only speak for SH where LRA mostly works fine although
it has some issues here and there.

>> Is there any reason I couldn't become the ia64 maintainer, assuming there was someone available to act as my general gcc mentor?
>
> Yes, I suppose that I can act as a mentor.  I'm extremely busy with
> RISC-V stuff though, so I may not have much time to help.

I wonder what's left for RISC-V to do. Most of the stuff seems to work, the
only thing that no one has taken care of are OpenJDK and LLVM.

I would have taken care of the OpenJDK stuff, at least for the Zero VM, but
I feel that RISC-V has an insane amount of people working on the ports, so
I rather focus on my pet ports ;).

Adrian

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

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

John Paul Adrian Glaubitz
In reply to this post by Jim Wilson
On 6/16/19 1:14 AM, Jim Wilson wrote:
> On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <[hidden email]> wrote:
>> Because as long as there's software for a specific hardware, that
>> hardware **is** useful IMHO. Devaluation of hardware in my eyes does not
>> come through so-called product obsolescence - hardware never has any
>> practical value without software - but by "trashing" key software which
>> originally was created with a lot of effort.
>
> There is no proposal to "trash" any gcc release that contains IA-64
> support.  There is only a proposal to drop it from future releases.

As I have already mentioned in a previous mail, we cannot unfortunately
use older gcc versions in Debian. We are using the default gcc version
from Debian unstable which is - sometimes with a little delay - always
the current release version.

This is one of the main reasons why I am against rapid release models
for something big as gcc or OpenJDK as it doesn't bring huge advantages
to regular users, but means a considerable extra workload for distribution
maintainers for constantly having to fix regressions of the new versions.

> It is important to keep in mind that software does not magically keep
> working after being written.  Someone has to maintain it.  That takes
> time and energy.

I fully understand that. In fact, I think most people here know how
software maintenance works.

> It isn't fair to force that burden onto the GCC
> global maintainers when there is no one that cares enough about IA-64
> to maintain it themselves.

But it's also not fair when GCC maintainers think they're the only project
in the open source world that deserves attention. A Linux distribution
isn't just GCC but a lot of other projects.

GCC maintainers should therefore also consider the needs and interests
of the maintainers of other projects, in particular with the power that
GCC has to destroy complete ports.

In Debian, we just had to kill of the PowerPCSPE port because GCC decided
to get rid of the backend despite Andrew Jenner working on fixing up the
backend. Eric Botcazou said that he didn't think the backend had to be
removed as it was separate from the other PowerPC backends. But that comment
was ignored and the backend removed and the Debian port killed off leaving
multiple users in frustration not being able to update their machines
anymore.

> Maintenance is a significant long term
> cost, and GCC does not have infinite time and people to do this work.

Yes, and this applies to all other open source maintainers as well. I have
done a huge amount of work on various architectures, including some work
on RISC-V, despite neither having RISC-V hardware nor being particularly
interested in the port nor being paid by someone. Yet I helped with the port
because I'm a nice person. In fact, a lot of the work we did in Debian Ports
for the old architectures helped to bring up RISC-V in Debian rather quickly,
much quicker than in the past.

> We have to focus most our time and energy on the targets that have the
> most users.  And when there is a target with few users that falls into
> disrepair and remains broken for a long time, we have to deprecate it.

If it was about users, no one would be working on RISC-V. RISC-V boards
are still absurdly expensive and every cheap arm64 board is still faster
and more powerful. By this very argument, RISC-V would have to be dropped
now.

> Also, it is important to note that IA-64 has a higher than normal
> maintenance burden, because there are so very many things it does that
> are different from other targets.

Yes, that's known.

> If you want the port to survive, then someone who cares about it will
> have to maintain it.  We have pdp11, vax, and m68k ports for instance
> because each one has a volunteer that is keeping it alive, so that the
> global maintainers don't have to fix it themselves.

Yep, and that's what's GCC's huge value over LLVM. GCC should by all
means not try to be another LLVM because what makes GCC so useful
is the vast amount of supported targets.

> Another issue here, if gcc maintainers can't get access to IA-64
> hardware or simulators, how are they supposed to maintain the IA-64
> gcc port?  Most of the lesser gcc targets have freely available
> simulators that make it easy for anyone to test gcc without access to
> hardware.  That is a serious problem for IA-64.  QEMU dropped the
> IA-64 support Nov 2017.

No, QEMU dropped support for KVM on IA-64. QEMU never had real ia64
emulation support.

And HPPA didn't have emulation support in QEMU for a long time either
but the backend was eventually added because Helge Deller and David
Anglin with the help of Debian Ports brought Debian's hppa port into
such a good shape that there was a very good basis to work on the
QEMU backend.

> I don't think that ski is maintained anymore
> either.  IA-64 hardware is expensive, and soon won't be manufactured
> anymore.  This is going to make continued maintenance even harder.

RISC-V hardware is expensive, too, and very hard to come by. The same
applies to VAX and PDP-11. So, I don't think this is a valid argument.

Adrian

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

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
In reply to this post by John Paul Adrian Glaubitz
On Sun, Jun 16, 2019 at 12:00 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> I wonder what's left for RISC-V to do. Most of the stuff seems to work, the
> only thing that no one has taken care of are OpenJDK and LLVM.

The more users we have the more stuff there is to do.  There are
always people wanting questions answered, or bugs fixed, or new speed
optimizations, or new size optimizations, or new features added.  Etc.
There is a great deal of stuff that x86/arm have that RISC-V doesn't
have yet.  It will take many man years to implement all of this stuff.

There is still some basic stuff missing from the GNU toolchain.
gdbserver.  32-bit glibc.  sub-word atomics in gcc (which are
available in a library that most people don't link in).  Gdb still has
hundreds of testsuite failures and needs a lot more work.  Gdb is also
missing features like hardware breakpoints that limits its usability.
There is a new V (vector) extension that people are starting to
implement, and auto-vectorizing compiler support is man years of work.
Just ask ARM/Linaro.  There is also the new B (bit manipulation)
extension that is getting more and more real.  LLVM stuff needs more
work, and that is holding back Rust and all of the packages that
require Rust.  Though I think there are more people working on the
LLVM tools than the GNU tools at the moment, so hopefully this stuff
gets in usable shape in a few more months.  But in turn is creating
more GNU toolchain work because they are finding implementation
differences and edge cases, things that we will need to work through
and update/clarify ABI documents and toolchain implementations.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: IA-64 GCC deprecation?

Jim Wilson
In reply to this post by John Paul Adrian Glaubitz
On Sun, Jun 16, 2019 at 12:22 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> GCC maintainers should therefore also consider the needs and interests
> of the maintainers of other projects, in particular with the power that
> GCC has to destroy complete ports.

We understand the importance of GCC and we do not deprecate a target
without good reason.

But you need to remember that we are a volunteer project, and do not
have infinite amounts of time available to support dying targets.
Someone has to support a target, and if no one steps forward then we
have to deprecate it.

> In Debian, we just had to kill of the PowerPCSPE port because GCC decided
> to get rid of the backend despite Andrew Jenner working on fixing up the
> backend. Eric Botcazou said that he didn't think the backend had to be
> removed as it was separate from the other PowerPC backends. But that comment
> was ignored and the backend removed and the Debian port killed off leaving
> multiple users in frustration not being able to update their machines
> anymore.

If someone steps forward to support a target, it can be readded.  But
you aren't going to get much sympathy for the PowerPC SPE port.  This
was a problem for a long time.  Freescale stopped supporting it long
ago.  IBM was forced to support it because it was part of the PowerPC
port.  IBM did the work to separate it, and then after a long period
of no one touching it we had to deprecate it.  But if someone is
serious about fixing it, then it can be re-added.  Ports have been
re-added after deprecation in the past.  There just needs to be
someone willing to do the necessary work.

> RISC-V hardware is expensive, too, and very hard to come by. The same
> applies to VAX and PDP-11. So, I don't think this is a valid argument.

There is a big difference.  There are multiple companies supporting
RISC-V development, including gnu toolchain development.  There are no
companies supporting VAX and PDP-11 toolchain development.  And there
are no companies supporting IA-64 toolchain development.

Jim