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?
On Thu, Jun 13, 2019 at 11:31 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> 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.
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.
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.
https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=grep&q=ia64
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.
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.
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?
On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> 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
Is there any reason I couldn't become the ia64 maintainer, assuming
there was someone available to act as my general gcc mentor?
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.
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?
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.
On Fri, Jun 14, 2019 at 7:30 AM Jason Duerstock
<jason.duerstock@gmail.com> 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.
On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <frank.scheiner@web.de> 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.
[...]
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.
On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner <frank.scheiner@web.de> 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.
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 22:43:34 |
| Calls: | 6,646 |
| Calls today: | 1 |
| Files: | 12,191 |
| Messages: | 5,327,622 |
