On Wed, Dec 10, 2025 at 3:07 AM Andrew Pinski via Gcc <[email protected]> wrote: > > On Tue, Dec 9, 2025 at 5:48 PM Frank Scheiner <[email protected]> wrote: > > > > Dear Andrew, all, > > > > On 09.12.25 21:15, Andrew Pinski via Gcc wrote: > > > It has been a few months since I last made the proposal of deprecating > > > IA64 and it seems like not much has changed. Nobody has stepped up. > > > There has been a few fixes but still no testresults for the trunk > > > sent. (there was one sent for GCC 15.1.0 and 15.2.0). > > > > I don't really follow. But maybe I misunderstood that thread you spoke of, > > so I re-read the whole thread. > > > > In [1] you wrote: > > > > > I also vote to have a testresults for the target at least once a year. > > > > [1]: https://gcc.gnu.org/pipermail/gcc/2025-August/246502.html > > > > Granted, the last result I posted in August was not from trunk, but from > > the current stable version; also for comparison reasons with existing > > test results it made sense to target GCC 15.1.0 and 15.2.0 instead of > > trunk. > > > > If that is not what you expected, AFAIK Tomas ran the testsuite for > > trunk recently on his machine. If the results weren't yet published > > I think this can be arranged still. If those results are no longer > > available I'll try to schedule a full run for C and C++ until the > > end of the week. > > > > You know, if we had an ia64 machine that runs 24x7 all year, we could > > provide testresults daily probably (assuming a more than 10 hour runtime > > for bootstrap and testsuite run for an 8-thread machine at 1.33 GHz). > > The problem is, we don't have that - yet. So testuite results from > > native bootstraps can't be provided very often. > > Why can't you keep the port maintained out of tree like you do already > for glibc and the kernel? > I am not seeing why it needs to be upstream because right now it is > blocking cleanups and there is no way for anyone outside of your group > to be able to test it.
I suppose that the target blocks cleanups means maintaining it out-of-tree is not easily possible. IMO as there is interest in having the Itanium port in-tree and work is done when required (like enabling LRA) I see no reason for deprecating or removing the port. There are other unmaintained ports and frontends and IMO this looks like a double-standard to me. I do agree that posting testresults from trunk semi-regularly is an important sign of activity in addition to the bootstrap work folks are doing (but not so much visible). Thanks, Richard. > Thanks, > Andrew > > > > > But Richard also wrote in [2]: > > > > > Having testresults also shows the port builds (as a cross at least) and is > > > able to build its target libraries. IMO broken ports are worse than > > > unmaintained ones, esp. if we release with those. > > > > > Ideally we'd have build bots with publically visible results that test > > > the building part > > > (doesn't have to run often), this should include building > > > cross-binutils, newlib/glibc/avr-libc > > > as fit. > > > > [2]: https://gcc.gnu.org/pipermail/gcc/2025-August/246507.html > > > > And this is covered by us, because we have a toolchain autobuilder > > that does exactly that (since 2024 already): i.e. always > > cross-building the latest snaphots of: > > > > * glibc > > * binutils > > * GCC > > > > ...for ia64 with T2 in sequence. > > > > So it first builds basic cross-compilers and tools (0-glibc, 0-binutils, > > 0-gcc (`--enable-languages=c,c++ [...] --disable-shared`)), then with > > these it cross-builds glibc (1-glibc) for ia64. Afterwards GCC is > > rebuilt against 1-glibc with `--enable-languages=c,c++,objc,fortran > > [...] --enable-shared` resulting in 1-gcc. It finishes up by > > cross-building binutils (2-binutils) and GCC (2-gcc) for ia64. > > > > The results (mainly the short build logs and the full logs) are public, > > the full build logs are saved as build artifacts and retained for 90 > > days. GitHub requires an active login to download these. > > > > This is linked from our website ([3], check the CI drop-down menu if > > interested), latest run is always reachable from [4]. > > > > [3]: http://epic-linux.org/ > > > > [4]: https://github.com/johnny-mnemonic/toolchain-autobuilds/actions > > > > In the meantime this has been adapted for another autobuilder > > specifically targetting GCC, building the latest snapshots from ATM: > > > > * gcc-13 (on Fridays) > > * gcc-14 (on Saturdays) > > * gcc-15 (on Sundays) > > * future gcc-16 (on Mondays) > > > > ...for ia64 in a similar manner than the above toolchain autobuilder, > > though with fixed versions of glibc and binutils. > > > > The latest run is always reachable from [5]. > > > > [5]: https://github.com/johnny-mnemonic/gcc-autobuilds/actions > > > > It is not yet linked from our website. Also because there is room > > for enhancement, e.g. I want to use the resulting target environment > > and perform some runtime tests with it in Ski directly on GitHub, > > like it is done for the Linux stable (RC) autobuilds (e.g. for > > linux-6.17.y on [6]) with an older Debian ia64 environment. > > > > [6]: > > https://github.com/linux-ia64/linux-stable-rc/actions/runs/20051199450/job/57508145479#step:14:1 > > > > Also I wonder if a cross-compiled GCC is a big enough test for gcc > > and g++ or if this should be extended to some other C/C++ code > > bases. I'm open for any suggestions here, also for a way to > > communicate these results in a better and more visible way than > > just providing the logs on GitHub and referring from our site. > > > > Another future option could be to also build the testuite programs > > cross and just run them in a Ski instance via ssh or rsh or whatever. > > I don't know if that is possible, but I assume there are ways to > > perform the testsuite on hardware as slow as or slower than Ski. > > Compiled code can be injected into a Ski instance during runtime via > > SSH or NFS. And future Ski will also allow for host idling between > > tests. So can run "forever" w/o constantly hogging a full hardware > > thread on the host machine. > > > > Cheers, > > Frank > > > > > Also at the same time I am also proposing to deprecate selective > > > scheduling since it is not enabled by default except on ia64. > > > Selective scheduling is broken for most other targets producing either > > > ICEs or wrong code. > > > Removing selective scheduling for GCC 17 would allow for some cleanups > > > in CFGhooks and maybe other places too. > > > > > > Thanks, > > > Andrew > >
