superenv: disable ConstraintEliminationPass on Xcode 16

[carlocab]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

This can result in build failures (e.g. OpenJDK) and silently miscompile
some formulae (e.g. Vim).

See Homebrew/homebrew-core#195325.

[MikeMcQuaid]

Looks good, thanks @carlocab!

[fxcoudert]

Isn't that a super heavy-handed fix? We are aware of two formulas where this bug triggers: vim and openjdk. Compilers will always have various slight optimization bugs, and I think it's a bad road to expect to fix them across the board. There is no evidence that this is a very high-profile or high-impact issue at this stage.

[fxcoudert]

To be clear about the approach I recommend: I suggest enabling the flag for vim and openjdk, and now that the issue is well-identified (thanks to great work on that issue page), see if other reports come in that appear similar.

[carlocab]

Maybe, but the way I see it is: we are trading off between the risk of miscompilation vs the risk of missed optimisations. One is much worse than the other.

If that's not actually the tradeoff that we're making, then do correct me, but once you agree that that's the tradeoff then it's hard not to conclude that you'd rather potentially miss some optimisations than potentially miscompile software.

As for compilers always having slight optimisation bugs: this is true, but "optimisation bugs" come in many different forms, and not all of those forms result in miscompilation. (Some, maybe most, just lead in code that isn't really faster.) Wherever we're aware of any that result in miscompilation and can do something about it, we probably should.

[fxcoudert]

I don't think it's just missed optimization, these passes are not strongly tested independently (i.e., most code and most tests just specify one -O value) so there is potential risk that we trigger other optimization bugs by forcing an unusual combination of passes. For the majority of software, where there is no known problem, I'd rather ship with the most tested configuration (including the one that Apple themselves use to compile their own OS and system).

I think the benefit/risk ratio would be different if we had a lot of formulas that crashed or otherwise misbehaved, but we have deployed Sonoma bottles for two months and so far we have found issues in only two cases: openjdk bootstrap, and one very specific code path in vim.

[MikeMcQuaid]

I suggest enabling the flag for vim and openjdk, and now that the issue is well-identified (thanks to great work on that issue page), see if other reports come in that appear similar.

This seems reasonable to me 👍🏻

[fxcoudert]

This seems reasonable to me 👍🏻

Implemented in vim, and openjdk is currently under testing.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[fxcoudert]

Original issue was confirmed fixed in Xcode 16.2 beta 3 (clang-1600.0.26.6), see Homebrew/homebrew-core#195325 (comment)