On Fri, 6 Mar 2026 at 09:31, Manos Pitsidianakis <[email protected]> wrote: > > On Fri, Mar 6, 2026 at 11:19 AM Peter Maydell <[email protected]> > wrote: > > Mohamed points out that this breaks the build when compiling > > with GCC (which I hadn't noticed because I happen to do my testing > > of target-arm with clang on Linux these days): > > Oops. same here, I was using clang.
> > typedef uint8_t hv_sme_zt0_uchar64_t; > > > > Could somebody confirm that that works OK on the relevant macos > > configurations ? > > I think this works. Do you want me to send a new revision? If you can test it for the macos configs I can just make the change locally. I have: +/* + * The system version of this type declares it with + * __attribute__((ext_vector_type(64))) + * However, that is clang specific and not supported by GCC. + * Since these headers are only here for the case where the system + * headers do not provide these types (including both older macos + * and non-macos hosts), we don't need to make the type match + * exactly, so we declare it as a plain uint8_t. + */ +typedef uint8_t hv_sme_zt0_uchar64_t; While you're retesting, could you also look at / test patches 17 and 18 in Mohamed's series https://lore.kernel.org/qemu-devel/[email protected]/T/#m2d1e3dfbfa5aecd41af6c0aa9e3b574a72c6f04d ? They look to me like bugfixes that we should be squashing/including in the "enable SME2 for hvf" handling. thanks -- PMM
