Re: [PATCH 2/3] ci: avoid bare "gcc" for osx-gcc job

From: Jeff King <peff@peff.net>
Date: May 16, 2024, 07:19 UTC
Message-ID: <20240516071930.GB83658@coredump.intra.peff.net>
In-Reply-To: <Zj-pGGGJEXlH02nR@framework>

On Sat, May 11, 2024 at 07:21:28PM +0200, Patrick Steinhardt wrote:

Show 16 quoted lines

> On Fri, May 10, 2024 at 03:47:39PM -0700, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> writes:
> [snip]
> > > [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.
> > 
> > Yeah, that is a very good point.
> 
> On Linux, we have the "pedantic" job that runs Fedora and only compiles
> the sources with DEVOPTS=pedantic without running any of the tests. We
> could do the same on macOS.

Yeah, I think the infrastructure is there (looks like just resetting $run_tests). We probably could stand to use it in more places. E.g., is there even value in running the tests for linux-gcc and linux-clang? It's _possible_ for there to be a run-time difference in the compiler outputs, but we may be hitting diminishing returns. The main value I think is just seeing what the compilers complain about.

But I dunno. This thread argues there is value in running the tests with the separate compiler:

  https://lore.kernel.org/git/pull.266.git.gitgitgadget@gmail.com/

which I guess would argue for doing the same for osx-clang and osx-gcc (if the latter continues to exist).

-Peff