On Tue, 8 Oct 2024 13:35:27 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> Personally I think it is foolish to trust this compiler and rather than >> dropping the optimisation level for the one file we've been lucky enough to >> know has been compiled incorrectly, we should issue a fatal error if this >> compiler is used. Downgrade your compilers again and complain en-masse to >> Apple. This compiler simply cannot be trusted. > >> Personally I think it is foolish to trust this compiler and rather than >> dropping the optimisation level for the one file we've been lucky enough to >> know has been compiled incorrectly, we should issue a fatal error if this >> compiler is used. Downgrade your compilers again and complain en-masse to >> Apple. This compiler simply cannot be trusted. > > While I understand your sentiment, let me just note that this is certainly > not the first time compilers generate incorrect code. Almost all hard-coded > places where we lower the optimization level for certain files is due to > compiler bugs. (A few is because a higher optimization level takes a > disproportionate time to compile.) Back in the days when we used Solaris > Studio, this kind of work-arounds was abundant. :( > > Of course the problem manifesting itself here can happen elsewhere. But it > apparently requires some very specific conditions to happen, as shown by the > so far failed attempts at getting this down to a simpler reproducer. It also > stands to reason that if this were to happen all the time, it would have been > discovered by clang/Xcode testing before they released. > > I'm not saying we should definitely include this PR, but I want us to view > the question a bit more grayscale and less black-and-white. @magicus the difference between this case and "back in the day", IMO, is that we perform rigorous testing of new toolchains before adopting them for our build system and so have a greater level of confidence in the overall reliability of the tools. It was only after such testing that we would adopt this kind of workaround. Also "back in the day" we had a lot more visibility into those tools (gcc and Solaris Studio) and the bugs that affected them. In this case we have developers choosing to use the bleeding-edge Xcode release, finding that it has an apparent bug, and then looking to deal with that by changing our build system. This is not my immediate "jump to" solution for such a problem. If the problem discovery were followed up by more extensive testing that failed to demonstrate other issues, then I'd more warmly welcome such a workaround. But I don't want us to be in a position where we accumulate such workarounds due to the pace at which developers update their Xcode installati on. And who is going to track if Xcode 16.x fixes the problem and allows the workaround to be dropped? This is certainly not a black-and-white issue, but no-one has outright rejected integrating the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2415560891
