https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 6 Aug 2025, ktkachov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412 > > --- Comment #10 from ktkachov at gcc dot gnu.org --- > Adding a graceful error message here would certainly be an improvement, I can > look into that. > > I wonder if this has implications for a vector library like SLEEF. They'd want > to build multiple VLS variants + VLA + Neon versions and ship them in a single > .a. Currently that all silently "works" modulo this ICE during LTO. > But would we recommend that they ship separate variants of the library per > VLA/VLS configuration? I think on the QOI side we should see to improve GCC to do-what-I-mean here, even with -flto. I _think_ (without having confirmed by analysis) the issue here is that we have no -msve-vector-bits during compile and -msve-vector-bits=256 in effect at link time. That could be triggered with a single CU and LTO by adding -msve-vector-bits to the linker command. On x86 we face similar issues when some vector modes start to be supported or not supported and that affects mostly global data and types where somee "effects" have been reflected into per-function IL. At certain points we have to make sure to reflect such variable properties (usually TYPE_MODE/DECL_MODE) in the context of a function. But as said, I'm not sure the SVE issue is the same. Somebody with more knowledge needs to see what is actually unexpected and why when we ICE.
