On Mon, 11 Aug 2025, Sam James wrote: > Frank Scheiner <frank.schei...@web.de> writes: > > > Dear all, > > > > 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. > 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 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). > > [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? > > > > > [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? > > > > >>> 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 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. Richard. > >> Can you please give heads-up to the folks that switched ia64 to LRA? > >> > >> Richard. > > > > Cheers, > > Frank > > sam > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
