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. 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. > [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.) >> Can you please give heads-up to the folks that switched ia64 to LRA? >> >> Richard. > > Cheers, > Frank sam
