On Wed, 16 Oct 2024 01:50:02 GMT, David Holmes <dhol...@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. >> >> 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 installa tion. 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. In terms of the champions & detractors review > model [1] I don't like this but will not actively fight against it. > > [1] https://www.oscar.nierstrasz.org/champion/ @dholmes-ora Well written, thanks. If I did think differently before (I'm not sure :-)), I know at least fully agree with what you say. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2415975988
