In theory, it is possible to inline a callee function into a caller function with incompatible streaming state, if we can prove that the body of the callee function will behave identically in both streaming and non-streaming mode. Unfortunately the existing checks are far too lenient, and can have an inconsistent impact on whether errors are reported for mismatching always_inline functions.
This issue has cropped up in various places: - PR 126133 was triggered by changes to the implementation of Neon intrinsics. The included testcase is resolved by patch 1/2, but a similar testcase without the explicit always_inline attribute is valid code where the same function might be incorrectly inlined. This related testcase is addressed in patch 2/2. - PR 124416 is a straightforward example of the bug, fixed by patch 2/2. - Multiple uncommmitted patches have tried to lower halving-add intrinsics to GIMPLE, which results in the sme/arm_neon_[123].c tests failing. There's nothing special about these particular intrinsics, besides them happening to be chosen when writing those tests. See https://gcc.gnu.org/pipermail/gcc-patches/2026-March/711545.html and https://gcc.gnu.org/pipermail/gcc-patches/2026-August/727675.html The second patch in this series removes all of the non-testsuite code that is changed in the first patch. I have chosen to structure this as two separate patches nonetheless, as I consider the first patch to be a necessary permanent fix, while the second patch could in future be reverted as the basis for a fixed implementation of AARCH64_IPA_SM_FIXED. Are these patches ok for master (assuming regression testing passes)? And ok to backport to GCC 14-16? Thanks, Alice
