Why we use specific compiler versions - was: Re: JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

[Magnus Ihse Bursie]

On 2022-04-14 19:42, Andrew Hughes wrote:
> On 12:57 Wed 13 Apr     , Magnus Ihse Bursie wrote:
>> I disagree completely. We had it this way in mainline originally, but it
>> was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393.
>>
> Prior to this patch, it seems there were no GCC version requirements.
> That's not what I'm suggesting.
>
> What I'm suggesting is that we replace gcc-10=10.2.0-5ubuntu1~20.04
> (or whatever it is now) with just gcc-10.
Is it possible to set the requirement to 10.2? That'd be okay for me, 
since it matches how we check for gcc versions in configure (currently 
it is at least "6.0"), and how we have traditionally described our 
requirements.

Or are the only two options "just major version" or "major, minor, patch 
and ubuntu release"? :(

/Magnus

>
> That still selects a specific major version of GCC. It is between
> major versions that we see new optimisations introduced, deprecations,
> etc.  I would certainly not suggest that we allow it to be switched
> from e.g. GCC 10 to G11 behind our backs. I have dealt with such
> transitions in Fedora and know the changes they bring.
>
> What I don't see the advantage of is requiring a very specific package
> version.  If this was OpenJDK, it would be like asking to build 8u
> with specifically 8u332-b05 rather than just 8u.  I can't see that we
> would do that without a very good reason. I don't see such a good
> reason for requiring the same of GCC.
>
> These two are handled differently on the GCC development side too.
> Breakage is expected with the move to a new major version.  This
> is why three stable versions are currently being maintained [0].
> If breakage were to happen between minor releases of a stable
> version, however, that would be a bug. I've yet to see a case
> of it happening, though of course it's possible.
>
>> As you might know, I'm not too fond of the GHA solution, since we can't
>> debug issues with Github's hosts. Nevertheless, many users look at the
>> GHA results as a way to sanity check their code. Any and all spurious
>> build failures is a problem then, since it will present a red marker --
>> even if the new code in the PR is okay.
> This specific versioning is producing precisely these spurious
> failures.
>
> The reason I started digging into this was because my PR failed on
> Linux x86_64. There were no code changes in the PR (I was backporting
> the GHA setup to our Shenandoah fork of 8u). Having only just added
> support to 8u mainline, I found this very odd.  It turns out it failed
> because it could no longer download the specific version of GCC. [1]
>
> I agree GHA can be painful to debug - it took me weeks to get 8u
> working in full - but it is useful for testing on architectures
> and operating systems one doesn't have easy access to.
>
>>   The less control we have over the build platform, the greater the
>> chance for odd and non-reproducible build failures.  Selecting a
>> specific version of the compiler is a way to guarantee reproducible
>> build results. If the build succeeds in mainline, and I submit
>> correct code, chances are higher that the build also succeeds in my
>> PR. In contrast, if the gcc version suddenly were changed behind my
>> back, the mainline build might succeed, and my PR build fail, not
>> due to anything I've done wrong, but just due to the fact that the
>> compiler was switched by the Ubuntu team in the meantime.  Yes, it
>> means a bit more annoyance when upgrading the compiler, but that
>> also means it is a conscious (and hopefully well tested)
>> choice. I'll take that any day over re-introducing more uncertainty
>> into an already-unstable testing procedure.
> As I say, I'm not suggesting we don't select a specific version, just
> that we are not *too* specific to the point we are constantly changing
> the version specification every time the Ubuntu maintainer fixes a typo.
>
> /Magnus
>
> [0] https://gcc.gnu.org/
> [1] https://github.com/openjdk-bots/shenandoah-jdk8u/runs/5889665932?check_suite_focus=true
>
> Thanks