Also adding Richard Sandiford to CC, because I forgot first time. Thanks, Alice
On Wed, Aug 19, 2026 at 03:55:49PM +0100, Alice Carlotti wrote: > 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
