With the security policy we want to rely on usage of
the -ftrivial-auto-var-init=zero flag to declare
bugs "not a CVE" if they rely on uninitialized stack
variables.

This arg is only supported by  CLang 17 or GCC 12 though,
both of which are beyond our current min versions.

This series bumps CLang to enable this, but we can't
bump GCC far enough due to the NetBSD constraint due to
its system GCC being 10.x. They do have newer GCC in the
pkg-src as non-default add-ons but we mostly stick with
default system versions.

We could bump to 12.x and force NetBSD users into use of
the non-default versions, but the last patch took the view
that we can just warn that use of old GCC versions takes
you outside the security policy.  If people prefer the
former though, I can respin.

Also historically the macOS XCode versions reported by
clang did not appear to align with upstream CLang versions
so we checked versions separately for macOS.

With this set of patches we happen to end up on 17.0 for
both upstream CLang and macOS Clang, and this makes me
wonder if we can rely on aligned versions going forward ?

Latest XCode 26.6 apparently reports clang 21.0.0 which
appears to be a match for a modern llvm release.

I'm no macOS expert though so looking for feedback from
people with more direct knowledge.

Daniel P. Berrangé (4):
  meson: simplify clang version checks
  meson: bump min XCode CLang to 17.0
  meson: bump min upstream CLang to 17.0
  meson: warn on GCC < 12.0 due to lack of -ftrivial-auto-var-init=zero

 meson.build | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

-- 
2.55.0

On 9/3/26 00:35, Daniel P. Berrangé wrote:
> We could bump to 12.x and force NetBSD users into use of
> the non-default versions, but the last patch took the view
> that we can just warn that use of old GCC versions takes
> you outside the security policy.  If people prefer the
> former though, I can respin.

In patch 3's commit message you mention that NetBSD has clang 21.  I 
think I'd be happier just rejecting gcc 10 and letting NetBSD compile 
with clang instead.  If someone really wants to build with gcc on 
NetBSD, they can take the extra step of using the pkg version.


r~

On Thu, Sep 10, 2026 at 08:04:10AM -1000, Richard Henderson wrote:
> On 9/3/26 00:35, Daniel P. Berrangé wrote:
> > We could bump to 12.x and force NetBSD users into use of
> > the non-default versions, but the last patch took the view
> > that we can just warn that use of old GCC versions takes
> > you outside the security policy.  If people prefer the
> > former though, I can respin.
> 
> In patch 3's commit message you mention that NetBSD has clang 21.  I think
> I'd be happier just rejecting gcc 10 and letting NetBSD compile with clang
> instead.  If someone really wants to build with gcc on NetBSD, they can take
> the extra step of using the pkg version.

NB, that would mean rejecting their "system" compiler since IIUC
they use GCC for that.  Having said that, this will resolve itself
with newer NetBSD, and NetBSD users are rare enough that this is
likely not a major inconvenience.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

On 9/3/2026 3:35 AM, Daniel P. Berrangé wrote:
> With the security policy we want to rely on usage of
> the -ftrivial-auto-var-init=zero flag to declare
> bugs "not a CVE" if they rely on uninitialized stack
> variables.
> 
> This arg is only supported by  CLang 17 or GCC 12 though,
> both of which are beyond our current min versions.
> 
> This series bumps CLang to enable this, but we can't
> bump GCC far enough due to the NetBSD constraint due to
> its system GCC being 10.x. They do have newer GCC in the
> pkg-src as non-default add-ons but we mostly stick with
> default system versions.
> 
> We could bump to 12.x and force NetBSD users into use of
> the non-default versions, but the last patch took the view
> that we can just warn that use of old GCC versions takes
> you outside the security policy.  If people prefer the
> former though, I can respin.
> 
> Also historically the macOS XCode versions reported by
> clang did not appear to align with upstream CLang versions
> so we checked versions separately for macOS.
> 
> With this set of patches we happen to end up on 17.0 for
> both upstream CLang and macOS Clang, and this makes me
> wonder if we can rely on aligned versions going forward ?
> 
> Latest XCode 26.6 apparently reports clang 21.0.0 which
> appears to be a match for a modern llvm release.
> 
> I'm no macOS expert though so looking for feedback from
> people with more direct knowledge.
> 
> Daniel P. Berrangé (4):
>   meson: simplify clang version checks
>   meson: bump min XCode CLang to 17.0
>   meson: bump min upstream CLang to 17.0
>   meson: warn on GCC < 12.0 due to lack of -ftrivial-auto-var-init=zero
> 
>  meson.build | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 

For the series:
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

Regards,
Pierrick