On Sun, 22 Sep 2024 11:02:20 GMT, Julian Waters <jwat...@openjdk.org> wrote:
>> Trivial change to drop the optimization level (for both fastdebug and >> release) of stackMapTable.cpp to O1 on MacOS with Xcode 16. >> >> This is a workaround for https://bugs.openjdk.org/browse/JDK-8340341, which >> prevents building on MacOS. >> >> Tested: with patch fastdebug and release builds are green again. > > I was about to raise a second concern about Link Time Optimization possibly > not working with this patch, but remembered that macOS's only supported > compiler, clang, doesn't support LTO in our build system. Wonder how I > could've forgotten that @TheShermanTanker > I think we typically don't use that sort of syntax in make for ifeq, Please be more specific. What is "that sort of syntax" you disapprove of? > There might be a better way of implementing the check of whether Xcode 16 is > being used, For example? > but since this is a workaround I think this is ok, If its okay, would you mind approving, then? If not, what is preventing approval? I am happy to address any complaints, but yours are way too vague. > we probably wouldn't want to overengineer a hack. My only concern is whether > specifying -O1 directly like that will properly end up behind all other > optimization flags to properly override them. As I wrote originally: the patch was tested and it works. Moreover, this seems to be the way to do per-file cflag optimization level overrides. > I was about to raise a second concern about Link Time Optimization possibly > not working with this patch You are saying that this override mechanism in itself is flawed? If so, it is outside the scope of this RFE and you would need to open a separate JBS issue to address this. For this RFE, I use this mechanism since it has been used for many similar cases (see the other overrides in this file) and it makes my build function again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21119#issuecomment-2366749468
