On 10.12.25 10:14, Jonathan Wakely via Gcc wrote: > On Wed, 10 Dec 2025, 01:49 Frank Scheiner via Gcc, <[email protected] > <mailto:[email protected]>> wrote: >> 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. > > This only tells us whether 15.2.0 works, which is probably the same > answer as whether 15.1.0 works. Testing the official releases is > better than nothing, but why aren't you posting test results for the > branch *before* a release, so that if something is broken it can get > fixed before the release?
Well, I tried, but the RC builds failed ca. 5.5 hours into it because of [2]. And I couldn't find the actual reason before the releases happened. Also these versions cross-bootstrapped fine all along. [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121623 > But what's really needed is to know whether > the trunk works, because that's where most changes happen. We know that trunk works, because we always cross-build the latest snapshots of glibc, binutils and GCC (with the toolchain autobuilds and also GCC alone with the gcc autobuilds for all currently maintained GCC versions). There is only a window of a week for GCC where things can go unnoticed due to the snapshot frequency. For example the issue fixed with [3] was only detected early on because of our toolchain autobuilds. Also it was quickly identifiable what introduced the problem (=a recent change in glibc), because the last known good build of GCC and the broken build happened to happen with the same GCC snapshot. [3]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9c9d3aef2f66625d9cb03ef4baee10ed6648e681 Also the kernel builds for the regular Linux mainline kernel testing always happen with the latest GCC snapshot. > If you don't test trunk then some change that breaks your target > could go unnoticed on trunk, and you'd be stuck on 15.x forever. It's > also possible (but less likely) that if nobody notices the trunk > change breaks ia64 then the change might even get backported to the > stable 15.x branch. I'd expect our autobuilds to notice such problems. And with future runtime tests with Ski we will also have runtime results from the resulting binaries. And if the testsuite can indeed be cross-built but still runtime tested in Ski we can even provide testsuite results for ia64 created on ordinary x86_64 hardware (similar to full runs in emulators for other arches but compiled much faster) in the future. I don't yet have a specific idea how this can be accomplished, but I assume I'd have to look into how things are done for targets like avr to get a picture. > If you're happy to stay on 15.x forever, you don't need to test > trunk, and you shouldn't care if the target is removed from trunk. > > But if you want the target to remain on trunk, you need to report > test results for trunk. Understood. Cheers, Frank
