Recent GCC patches leave DEFAULT_CPU undefined in some cases

[h-vetinari]

brew config AND brew doctor output OR brew gist-logs <formula> link

not applicable

Verification

• My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.
• My issue is not about a failure to build a formula from source.

What were you trying to do (and why)?

The GCC patches (for v16 and recent patch releases) do the following

homebrew-core/Patches/gcc/gcc-16.1.0.diff

Lines 3187 to 3193 in 76b7fd6

	+/* Default architecture to use if -mcpu=native did not detect a known CPU. */
	+#if TARGET_MACHO
	+#define DEFAULT_ARCH "apple-m1"
	+#else
	+#define DEFAULT_ARCH "8A"
	+#define DEFAULT_CPU "generic-armv8-a"
	+#endif

i.e. define DEFAULT_CPU conditionally, while leaving codepaths elsewhere in that TU that require DEFAULT_CPU to be set unconditionally (or, more specifically, guarded by #if defined(__APPLE__), which is not equivalent to #if TARGET_MACHO).

This makes it impossible to build cross-compilers targetting darwin from linux, as we're doing (among other things) in conda-forge.

CC @fxcoudert for #287916

PS. Sorry for having to "lie" in the issue template; this is not directly a brew issue, but still belongs in this repo.

What happened (include all command output)?

GCC with homebrew patches applied should still compile under all circumstances.

What did you expect to happen?

GCC compiles successfully

Step-by-step reproduction instructions (by running brew commands)

N/A

[SMillerDev]

PS. Sorry for having to "lie" in the issue template; this is not directly a brew issue, but still belongs in this repo.

Why does it belong to brew and not to the source of the patches in https://github.com/iains/gcc-16-branch?

[h-vetinari]

If you prefer, I can open an issue there, but the branch there is much more volatile than what actually ends up getting committed here. For us, the patches checked into this repo are the source of truth.

[SMillerDev]

Not sure who "us" is, but these patches are merely a snapshot of the source I linked whenever Homebrew tries to merge an update. If there are issues with the patches, they should be submitted to the source. That's what Homebrew maintainers will refer you to if you suggest patch changes anyway.

[h-vetinari]

@SMillerDev: Not sure who "us" is,

As indicated in the OP,

@h-vetinari: This makes it impossible to build cross-compilers targetting darwin from linux, as we're doing (among other things) in conda-forge.

I'm referring to conda-forge here, and in particular our compiler builds for GCC.

@SMillerDev: these patches are merely a snapshot of the source I linked whenever Homebrew tries to merge an update.

That makes all the difference though, as each of those snapshots is being tested and validated by y'all, whereas a given commit on Iain's branch does not necessarily meet the same bar.

Let's say I open an issue on issue on Iain's repo, and it gets fixed eventually, then there'd still be the need to wait for an update of those patches (like #287916) on this repo.

[fxcoudert]

Opened an upstream report: iains/gcc-darwin-arm64#153
But we're unlikely to carry the patch as a "hot fix" when it comes out, because it's cross-compiler specific and Homebrew does not build cross-compilers.

I'm therefore closing here.

[fxcoudert]

That makes all the difference though, as each of those snapshots is being tested and validated by y'all, whereas a given commit on Iain's branch does not necessarily meet the same bar.

While I personally work as hard as I can to provide stable patches for GCC that are usable by the largest user base, and I know that the added value of Homebrew testing is important (because it demonstrates the stability of the patches), Homebrew as a project cannot become "de facto maintainer" of GCC.

[SMillerDev]

That makes all the difference though, as each of those snapshots is being tested and validated by y'all, whereas a given commit on Iain's branch does not necessarily meet the same bar.

We compile it and see if it runs a very very simple program. I don't think we do more validation than upstream.

[SMillerDev]

That makes all the difference though, as each of those snapshots is being tested and validated by y'all, whereas a given commit on Iain's branch does not necessarily meet the same bar.

We compile it and see if it runs a very very simple program. I don't think we do more validation than upstream.