On Tue, 12 Aug 2025, Frank Scheiner wrote: > Dear Richard, > > On 12.08.25 08:46, Richard Biener wrote: > > On Mon, 11 Aug 2025, Frank Scheiner wrote: > >> 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". > > Yeah, ok, I guess nobody is really subscribed to that list but rather > uses it for reference only. > > >>>> 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. > > That's fine and much obliged by users of GCC (including me). I'm sure, if > we had the backing, and the countless systems running non-stop > free-of-charge we could do some really great things, albeit we have to > work with what we have available (incl. manpower). > > But to be sure, you mean the GCC testsuite(s) here, not the testsuites of > each and every userland part that offers it? AFAIK even my upstream distro > (Slackware) doesn't do the latter by default. Also running the testsuites > of userland parts would be primarily a quality measure of the respective > distro IMHO.
Yes, being able to boostrap a hosted port or being able to build a cross compiler and then with either result run the testsuite (for an interesting subset of languages, C and C++ for bootstrap, at least C for cross testing) "regularly" would be a good thing to have. Where "regularly" can be once a day, a week or a month. If it's so slow that once a month isn't feasible then it would be important to step up the pace during Stage3/Stage4. > >>>>> [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. > > Well, if these are not used as argument against ia64 in the GCC, that's > fine. :-) Sure not. Incoming bugreports for a port are _also_ a sign of it being alive! Of course bugs getting no attention at all (not confirming, not at least some analysis) isn't a sign of a healthy state of maintainance of a port. > >>>>>>> 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 until now, no constraints were actually violated. Right. The only thing is that we don't like to have ports without a maintainer. > >> 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. > > Ok, so [10] mentions the following: > > ``` > Our release criteria for the secondary platforms are: > > The compiler bootstraps successfully, and the C++ runtime library builds. > The DejaGNU testsuite has been run, and a substantial majority of the tests > pass. > ``` > > ...for secondary platforms and limiting it further above to "C, C++, and > C++ runtime library". > > [10]: https://www.gnu.org/software/gcc/gcc-15/criteria.html > > I believe ia64 will fulfill these release criteria, though the last test > results submitted ([11]) were from a pre-GCC-15.1-release. > > [11]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > I know that GCC 15.1 bootstraps on EPIC Slack (for C, C++ and Fortran, I > only build these) and I'm currently bootstrapping 15.2, because > Slackware switched to this version on Saturday. > > Testsuite results are missing and I didn't keep the build directory for > 15.1. But the testsuite results on [11] were anyhow made from T2, so > for comparison it would be better to reuse that environment for the > native bootstrap builds and testsuite runs for 15.1 and 15.2. > > Can I limit these builds and testsuite runs to C and C++ as per the > release criteria to speed things up on real hardware? I don't know > exactly how much time this would save, but I seem to remember that the > Fortran build and testsuite takes quite some time extra, Objc not so > much IIRC. Yes, I think that'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. > > Yeah. Usermode emulation could at least scale to the number of > hardware threads on the host. But I have no idea how much work is > needed to implement the missing syscalls for Ski. > > Cross-bootstrap and executing only testsuite programs on real > hardware could be closer - if possible. > > >> [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? > > Can't say for sure. But from my experience with my entire collection > of vintage hardware across architectures and practically zero > breakdowns from age I conclude there's much more life left in these > machines than anybody would expect from them. E.g. for my ia64 gear > only the rx4640 is sometimes flaky, which I attribute to one or > multiple of its 16 (or 32 - I don't remember currently) memory > modules. But when those boot errors are happening, they are usually > cleared with one or multiple reboot(s), so not much reason to invest > the time to go through all of the modules with memtest in some x86 > machine. > > Apart from that, looking at the number of ia64 systems that are > available to me on [12] and others in the community. It'll take a long > time until all of them are used up (incl. the extra hardware in stock > like PSUs). And even then it will be possible to "operate" some ia64 > blade and continue with that for years. Especially when newer systems > like i4 or i6 become available, with the latter still listed in HPE's > webshop ([13]). Heh. Richard.
