Re: IA-64 GCC deprecation?
On 6/13/19 9:06 PM, Jim Wilson wrote:
> 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.
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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: