Comment # 8 on bug 1230262 from Guillaume GARDET

(In reply to Andreas Färber from comment #7)
> (In reply to Guillaume GARDET from comment #6)
> > (In reply to Andreas Färber from comment #5)
> > > Should we in the meantime switch to either gcc13 or non-LTO builds?
> > 
> > Not all builds fail, so I would stick to gcc14 and LTO builds for Tumbleweed
> > in general. 
> > If some packages are key packages, we can disable LTO until this bug is
> > fixed.
> 
> I was thinking of openvino in particular; not sure where libaom is used.
> It already took a month for the upstream GCC bug to get assigned, so leaving
> it failing in Factory does not strike me as a good strategy, given that
> there is an upstream reproducer.

Patch is on list already:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664319.html

So, if @Richard Biener agrees, we could add this patch on our gcc14 package?

Otherwise, I will disable LTO for openvino and also for libaom because of the
number of packages depending on it:
  osc whatdependson openSUSE:Factory:ARM libaom standard aarch64 |wc -l
returns 506!