Clang warning after update to MacOS 26

[canecaster]

Output of brew config

HOMEBREW_VERSION: 4.6.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: 6c44d1a8f1bd7ca44c3f13c4e3694cdff40483a2
Last commit: 2 days ago
Branch: stable
Core tap JSON: 16 Sep 15:11 UTC
Core cask tap JSON: 16 Sep 15:11 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 3.4.5 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/bin/ruby
CPU: dodeca-core 64-bit arm_blizzard_avalanche
Clang: 17.0.0 build 1700
Git: 2.50.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.0-arm64
CLT: 26.0.0.0.1.1757719676
Xcode: 26.0
Rosetta 2: false

Output of brew doctor

Your system is ready to brew.

Description of issue

Today I upgraded my secondary Mac to MacOS 26, updated Xcode, updated the Command Line Tools, did a brew update and then a brew upgrade. When I compile Fortran code using gcc, I get the following warning:

clang: warning: overriding deployment version from '16.0' to '26.0' [-Woverriding-deployment-version]

The code does seem to compile and run okay, so I'm guessing this is a warning that I can ignore. Any recommendations? I don't want to go to MacOS 26 on my primary Mac until I understand the significance of this warning.

Thanks,

James

[SMillerDev]

How do you run Fortran code? How is brew involved in it?

[canecaster]

I installed the gcc compiler using Homebrew. The warning message comes up when I compile a Fortran source with gcc.

[cho-m]

May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120645, which @fxcoudert fixed upstream.

Will likely go away when GCC 15.2 update is done in future PR (will take some more time due to rebasing patch).

You can ignore warning as it is just saying Clang is doing the right thing, i.e. auto-correcting macOS 16 to macOS 26.

[canecaster]

Thank you for that link and the reassurance!

[jdroniou]

This is actually not an insignificant warning. I had the same this morning while compiling my (extensive) C++ library, and even though the compilation seems to go well modulo this warning, the output of my code is completely broken (it creates NAN where I previously had proper numbers). It's ok if I compile my library with clang, but then I cannot benefit from all its dependencies (some do not compile with clang).
I'm planning to wait on an update of brew/gcc, hoping that it does not take several weeks.

[SMillerDev]

Sounds like a good thing to report to the GCC maintainers that made a fork for macOS on ARM.

[jdroniou]

Just to specify, my configuration is not the same as the OP, I'm on a silicon chip.

[SMillerDev]

https://github.com/iains/gcc-15-branch/issues seems to be the place for that.

[fxcoudert]

To be clear: the warning is harmless and the fix is already pushed upstream, we could ship it.

@jdroniou could you open a report with a minimal working example for your specific issue? You say “ it creates NAN where I previously had proper numbers”, so what happened in this before/after comparison? Does it follow a macOS update, a GCC update, or another change?

[jdroniou]

Yes, I was probably quick in identifying the issue. This particular warning may be harmless, but something else happened when I did the update to Xcode 26.
My homebrew was up to date (with gcc-15 v15.1.0), and everything was working well on Sunday. I was then prompted to update Xcode, which I did; it's the only update I made, but it completely broke my code when I compile it with gcc (as I said, many calculations end up giving NAN when they gave correct numbers before). When I compile with the native clang, it works well (but i have to disconnect some modules that do not compile with clang).
Unfortunately, the library is way too extensive for me to try and cook up a MWE. It uses boost - that I also re-compiled from scratch -, Eigen3, etc., and has dozens of internal modules (it's a scientific calculation code). I completely recognise that without an MWE it's impossible to look for the bug, and my objective now is just to wait for some update of gcc to see if things get fixed (it's not the first time that an update of xcode breaks something in brew/gcc, but it's usually repaired soon after when brew updates its gcc).

[fxcoudert]

So you said you updated Xcode, but not macOS. Could you post the output of brew config to see what your exact config is?

If you have a bit of time on your hands, you could try to recompile Homebrew's gcc from source, and see if it fixes it for you: brew reinstall -s gcc (it will take a few hours). It may fix the issue if it comes from a mismatch between SDK and compiler (which is one of the possibilities).

[jdroniou]

Thanks for the advice. I've re-installed gcc from sources (which only took about 15min actually) but the result is the same.

Here is my brew config:

HOMEBREW_VERSION: 4.6.13
ORIGIN: https://github.com/Homebrew/brew
HEAD: 21c60eb773618f039434d923d2522120c4df56ea
Last commit: 26 hours ago
Branch: stable
Core tap JSON: 23 Sep 16:51 UTC
Core cask tap JSON: 23 Sep 16:51 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_FORBID_PACKAGES_FROM_PATHS: set
HOMEBREW_MAKE_JOBS: 14
Homebrew Ruby: 3.4.5 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.5/bin/ruby
CPU: 14-core 64-bit arm_palma
Clang: 17.0.0 build 1700
Git: 2.50.1 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.0-arm64
CLT: 26.0.0.0.1.1757719676
Xcode: 26.0
Rosetta 2: false

[fxcoudert]

Hum, then I don't know. It's either:

• some macOS math lib or other library or SDK change (unlikely)
• a regression in GCC's arm64 or arm64-darwin code (somewhat unlikely)
• your code is relying on undefined behavior which the compiler go “better” at optimising (more likely)
• if it's C++, possibly some libc++/libstdc++ change or incompatibility

If you want to reduce it, you say it's complex code and it works fine with clang. Assuming it's C (and not C++) and you want to invest some effort into figuring it out, you could switch compilation from clang to GCC part by part, and see where the miscompilation occurs.

[jdroniou]

It's C++, so quite intricate. I tried reducing the level of optimisation, no luck. I'll need to investigate more to find the source, but at least I seem to see the issue at every level (even on simpler calculations).