On Fri, May 10, 2024 at 01:32:15PM -0700, Kyle Lippincott wrote:
> On Thu, May 9, 2024 at 9:24 AM Jeff King <peff@xxxxxxxx> wrote:
> >
> > On macOS, a bare "gcc" (without a version) will invoke a wrapper for
> > clang, not actual gcc. Even when gcc is installed via homebrew, that
> > only provides version-specific links in /usr/local/bin (like "gcc-13"),
> > and never a version-agnostic "gcc" wrapper.
> >
> > As far as I can tell, this has been the case for a long time, and this
> > osx-gcc job has largely been doing nothing.
>
> If it's been doing nothing (which I interpreted as "it's doing the
> same thing as osx-clang"), and we've not noticed any issues with that,
> do we need the job at all? Should we just rely on clang and not test
> with gcc on macOS, since it's not a compiler that's provided by the
> platform anymore?
Your interpretation is correct; it was just doing the same thing as
osx-clang. As I said earlier, I'd be fine with just dropping it. It's
possible that there is value in testing there with gcc (that we've been
missing out on), but to know that we'd have to understand the original
reasons it was added.
Looks like it came from 889cacb689 (ci: configure GitHub Actions for
CI/PR, 2020-04-11), but that was just porting from the Azure pipelines
config. That system got its osx_gcc job from 27be78173d (Add a build
definition for Azure DevOps, 2019-01-29), but that in turn was just
porting the Travis config. The Travis job came from 522354d70f (Add
Travis CI support, 2015-11-27), and there's no specific rationale given.
But it used a build matrix of (os, compiler), so we got all four of
{linux,osx}-{gcc,clang}. So it mostly seems like "more is better" and
that was the easiest way to define it.
I do think there's value in testing with both clang and gcc in
general[1]. And there is _some_ code which is compiled only on macos
and not elsewhere. So this would be our only chance for gcc to see it.
But it seems like a pretty small return for an entire parallel job.
Especially as I do not think it has uncovered anything interesting in
the past (even when it was working).
-Peff
[1] Another quirk is that we run the whole test suite for both
compilers, which is probably overkill. The main value in comparing
gcc vs clang is that we don't use any constructs that the compiler
complains about. It's _possible_ for there to be a construct that
the compiler does not notice but which causes a runtime difference
(say, undefined behavior which happens to work out on one compiler),
but I think we're again hitting diminishing returns.
