On Mon, 11 Aug 2025, Frank Scheiner wrote: > Dear all, > > On 11.08.25 12:59, Richard Biener wrote: > > On Mon, 11 Aug 2025, Sam James wrote: > >> Frank Scheiner <frank.schei...@web.de> writes: > >>> On 11.08.25 09:49, Richard Biener wrote: > >>>> On Sun, 10 Aug 2025, Jeff Law wrote: > >>>>> On 8/10/25 3:24 PM, Andrew Pinski wrote: > >>>>>> I just looked and the last testsuite results for ia64 was back in June > >>>>>> 2024. There has been no movement since. Can we again make ia64 > >>>>>> obsolete? > >>> > >>> Is there any current issue that needs tackling with ia64? Or does it > >>> create extra work for others? > >> > >> * Incomplete C23 support (needs BitInt ABI defined and implemented, see > >> PR117585) > >> * I think it's the only target requiring (?) selective scheduling and > >> selective > >> scheduling isn't in a great state (PR85099) > >> * A bunch of random ICEs and wrong-code bugs specific to ia64 that > >> nobody has debugged or fixed (e.g. PR87281, PR105215, PR105445) > >> > >> There isn't any maintenance being done for the target, monitoring of > >> (new) bugs, etc. > > > > The most important thing is that there's no listed maintainer of the > > target. > > Well, we can't directly control that. But yeah, I had hoped for more, also > from me. Making time for that is an issue though on all sides. But also > it's not like nothing happened on our side. It's built, it's used for kernel > and userland builds and it works for most things tried. Visibility of what > has been done is of course limited. But will it really make a difference if > I spam the testresults list with successful cross-compiler and kernel > builds?
Well, it's an indication the port is "alive". > >> I suspect that more issues would be found if someone was running the > >> testsuite regularly (and doing bootstraps w/ full checking enabled) and > >> looking at new failures. > >> > >>> > >>> (1) While I haven't produced any new testsuite results for ia64 since > >>> last year*, I'm building and using an ia64 cross-compiler from GCC > >>> snapshots every week (most of the time) to build Linux mainline RCs > >>> or pre-RCs for testing on real machines and Ski during merge windows. > >>> See for example [1]. > >>> > >> > >> Not having support in upstream glibc or the kernel also means nobody can > >> really test it. > > I don't understand that point. We have - granted, out-of-tree - support for > both Linux and glibc for ia64. And this is there since 6.7 ([4]) and > 2.39 ([5]) respectively, and taking this history into account, the prospect > is, that it is not going away any time soon. That no distribution is using > it but T2 and EPIC Slack, that's indeed sad. But if we can use it, it > shouldn't be a problem for others, too - if they want to test it. But I > asssume the __want__ is the problem. > > [4]: https://github.com/johnny-mnemonic/linux-ia64/ > > [5]: https://github.com/linux-ia64/glibc-ia64/ > > >> I think the requirements for a target that isn't > >> freestanding and is for a specific libc, yet that libc doesn't support > >> it (and there's no sign of such support (returning)) are stronger than > >> an upcoming port or one where it's freestanding. > > > > That's of course an issue, though a ia64-elf freestanding target could > > be tested with a cross compiler and using a simulator (I'm not sure > > how the state of simulators of IA64 is). > > Ski is actively maintained and gradually improved (see [6] and [7]) > > [6]: https://github.com/trofi/ski > > [7]: https://github.com/linux-ia64/ski > > Ski support through hp-sim target is back to (out-of-tree) Linux mainline > since early 2024, see [8]. > > [8]: http://epic-linux.org/#!/machines/hp-sim/index.md > > Performance is rather limited and userland emulation is missing too > many syscalls to be of use for more complex stuff. Networking is possible > in system mode (in the future also with tun/tap devices thanks to old > patches from Mikael Pettersson I'm currently integrating), so it's > possible to inject compiled programs during runtime via NFS for example. > > >>> [1]: http://epic-linux.org/#!testing-effort/log.md > >>> > >>> *) Frankly, I'm missing the time to also handle this in addition to > >>> maintaining Linux and glibc for ia64. Also, we're still missing a > >>> constantly running ia64 system to perform those ca. 10+ hour runs > >>> for building and running the testsuite regularly. > >>> > >>> (2) I've also set up an autobuilder which every night cross-builds the > >>> latest available glibc, binutils and GCC snapshots, see [2]. > >>> > >>> [2]: > >>> https://github.com/johnny-mnemonic/toolchain-autobuilds/actions/runs/16870641887/job/47784774192 > >>> > >>> (3) I'm natively building a selection of Slackware packages for my > >>> unofficial ia64 port (EPIC Slack ([3])) regularly. Though this uses the > >>> versions Slackware uses in -current, so 15.1 ATM. > >> > >> Are you running testsuites for packages and making sure there's not > >> wrong-code issues arising? > > I consider building with an always up-to-date environment both native > (EPIC Slack) and cross (T2) test enough for the state of the ia64 port > with its current user base. If interest in the ia64 port grows this > can be professionalized more, sure. We don't have the resources to > target maximum goals. And that is also not needed to keep a port alive. > > Nobody will complain to GCC devs if something doesn't work for ia64. Well. That's not our standards of quality. Or it shouldn't be. > >>> [3]: http://epic-slack.org/ > >>> > >>> If there were any hard issues during this continuous testing I'd have > >>> created a bug report to handle that. > >> > >> I see http://epic-slack.org/#!index.md#2025-07-11 mentions an ICE with > >> cryptsetup. Is there a bug for that? If one is filed, who is going to > >> take care of it? > > This specific issue is new and happens both natively (even with older > GCC versions) and cross. Personally I don't think cryptsetup is vital > enough for ia64, but when this is needed by users I'm sure they will > find a way to fix that issue. > > But exactly, why should we file a bug for ia64 if we can't provide > the solution, too. Bug reports also exist to get visibility on issues. > >>>>> Yes, please. Better to get it in place now so that nobody's surprised > >>>>> come > >>>>> next spring. > >>>> > >>>> Also let's discuss better documentation (or changed) requirements on > >>>> what we expect from targets to stay in GCC, be primary or secondary > >>>> targets. > >>> > >>> Yes, I'd really appreciate that. Because using and testing it for > >>> Linux builds seems not enough? > >>> > >> > >> (See my above remarks wrt requirements; do think there's more to be > >> discussed here but don't want to repeat the same parts here too.) > > > > I'd like to see build bots for each target. At least those we > > consider primary and secondary. > > I'd like those, too, but the reality is, we don't have them. > At least not for native building. For cross-bootstrap-builds see [2]. > > But also ia64 is neither primary nor secondary, or? Right. > So what would be adequate for a tertiary target? There are currently no official constraints for "other targets" (other than primary or secondary). Which is why I suggested to improve documentation and think about what's reasonable. > > I think non-bootstrap builds are OK, > > but running the testsuite is important, so this might involve > > building a runtime. Testing with a simulator should be OK. > > I wouldn't dare to run the testsuite in Ski, as performance is > lousy ([9]). And if it already takes more than 5 hours just for the > testsuite on an rx2800 i2 with 1 x 9320 and 8 hardware threads, I'd > expect a full run to take weeks inside Ski. In [9] I found that a > single Madison 1.3 GHz 3M is about 21 times faster than Ski (running > on a 4 GHz Haswell) for a simple package build of the dash shell. Hmm. So I guess it's the lack of usermode emulation, with qemu if you have to do system emulation that's also 10x slower than with user emulation. The only possible "positive" is that x86 and arm hosts scale to 100s of CPU cores, so massive parallelization of testing can still make a difference. > [9]: http://epic-linux.org/#!index.md#Ski_-_the_undiscovered_country > > But maybe there could be a solution found that involves both cross > compiling and only executes test programs on real ia64 hardware to > speed things up considerably. I assume this is possible, and I > believe Rene has looked into that. I just don't know where we are > with that right now. But it could be a solution to provide more > testing. I think for IA-64 a problem that you'll face sooner or later is that hardware will break down and it's impossible to get replacement parts or repairs. So robust (and scalable) emulation is important. But then, given the architecture is truly dead, I wonder whether, at such point, there's a point in keeping it alive? How far are we from this point? Thanks, Richard.
