https://bugzilla.suse.com/show_bug.cgi?id=1230262 https://bugzilla.suse.com/show_bug.cgi?id=1230262#c8 Guillaume GARDET <guillaume.gardet@arm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(rguenther@suse.co | |m) Status|NEW |IN_PROGRESS --- Comment #8 from Guillaume GARDET <guillaume.gardet@arm.com> --- (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! -- You are receiving this mail because: You are on the CC list for the bug.