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. 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 >
