On Thu, 22 Jan 2026, Kalvis Duckmanton wrote: > > Have you run your fix through full regression-testing or is it only the > > reproducer from the PR and presumably the build of GCC that the fix has > > been verified against? Regardless, I'll push it through verification in > > my own environment and let you know of the outcome. > Only the reproduction case from the PR and builds of GCC - both on > NetBSD/amd64 and Linux/i686.
OK. The more verification the better as it increases the diversity of test environments, e.g. I use PPC64/Linux as the test host. Plus sadly I might be the only one nowadays to ever run regression-testing with the VAX/NetBSD target, so the bus factor is pretty low. > > I'm curious as to what has caused this regression, or alternatively what > > is different that causes the problem with your configuration but not mine, > > as I was certainly able to build a GCC 15 snapshot just fine shortly after > > GCC 14 was branched: > > > > $ vax-netbsdelf-gcc --version > > vax-netbsdelf-gcc (GCC) 15.0.0 20240525 (experimental) > > [...] > I suspect that it's some function of the language being compiled (C++ vs C), > the complexity of the input, the optimisation level requested and the phase of > the moon. I do know that GCC 12.2.0 also terminated abruptly under the same > circumstances and that the reproduction case was quite a bit smaller. I'll > send you some more details of my build environment off-list. Weird, but the issue does trigger here with your reproducer included with the PR, so it's good enough to work with. Compilation succeeds with GCC 11 though, so it's indeed a regression and might be related to the switch from CC0 to MODE_CC internal condition code representation. I might try to bisect it. In any case I've built a fresh version of the compiler with no issue and regression-testing is under way. As I recall it took ~72h to complete on the last occasion, so it'll take a while yet and then another run will be required with your change applied. I'll keep you posted. Maciej
