[BUG] OIIO 2.5.7.0 fails to build on Fedora only on aarch64

[hobbes1069]

Describe the bug

/builddir/build/BUILD/OpenImageIO-2.5.7.0/src/include/OpenImageIO/simd.h:4796:32: error: cannot convert ‘int16x8_t’ to ‘OpenImageIO_v2_5::simd::vint4::simd_t’ {aka ‘int32x4_t’} in initialization
 4796 |     simd_t val16 = vcombine_s16(vqmovn_s32(clamped), vdup_n_s16(0));
      |                    ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                |
      |                                int16x8_t

Full log:
https://kojipkgs.fedoraproject.org//work/tasks/1777/111791777/build.log

Perhaps this is do to the new SIMD updates? I never built 2.5.6.0 in the official repos but all test builds completed.

Platform information:

• OIIO branch/version: 2.5.7.0
• OS: Fedora Rawhide
• C++ compiler: gcc 13.2.1
• Any non-default build flags when you build OIIO: See full logs

[mfvescovi]

Hi Richard!

/builddir/build/BUILD/OpenImageIO-2.5.7.0/src/include/OpenImageIO/simd.h:4796:32: error: cannot convert ‘int16x8_t’ to ‘OpenImageIO_v2_5::simd::vint4::simd_t’ {aka ‘int32x4_t’} in initialization
 4796 |     simd_t val16 = vcombine_s16(vqmovn_s32(clamped), vdup_n_s16(0));
      |                    ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                |
      |                                int16x8_t

I'll give you more feedback on Debian later this week (maybe this evening CET) since I'm uploading v2.5.7.0 to Debian experimental prior to the SONAME transition and it'll be built on all release architectures, so even arm64.

[mfvescovi]

I'll give you more feedback on Debian later this week (maybe this evening CET) since I'm uploading v2.5.7.0 to Debian experimental prior to the SONAME transition and it'll be built on all release architectures, so even arm64.

Here: ARM64 build

Hope this helps somehow.

[hobbes1069]

Unfortuantely I couldn't find anything that helped. For now I have reverted to 2.5.6.0.

[darix]

Same issue for openSUSE Tumbleweed

https://build.opensuse.org/package/live_build_log/graphics/OpenImageIO/openSUSE_Factory_ARM/aarch64

[hobbes1069]

The original build expired so here's a new link showing the error for 2.5.8.0:
https://kojipkgs.fedoraproject.org//work/tasks/1376/112731376/build.log

[darix]

openSUSE package updated to 2.5.8.0. same link as above.

[darix]

can we maybe revert the neon part from
in the mean time? d58e4aa3e3f4fb42aa1593ae379

[lgritz]

Thanks for your patience. I will look at this issue today.

[lgritz]

Proposed fix here: #4143

Can you try this patch out on your end before I merge it?

The problem is that even though we now have an ARM based Mac in our CI suite, it looks like the flavor of Apple Clang it uses was perfectly happy to accept the code we had and just understand that it was fine to bitcast between those types, whereas it was rejected on the ARM Linux variants (which we don't have available to test on).

Reading documentation on the intrinsics, I believe I was able to repair it, but won't be sure until you give it a try.

The functions get tested, so I know they were correct execution all along, it's just a question of the compiler being strict about the type casting.

[darix]

package with the patch is building here: https://build.opensuse.org/package/show/home:darix:branches:graphics/OpenImageIO

you can find multiple distributions and architectures there.

it seems 2.5.8.0 broke the testsuite for us. even updating the images to the latest version does not help.

for the record 2.5.7.0 still passed https://build.opensuse.org/package/show/openSUSE:Factory/OpenImageIO

[lgritz]

If I understand the failing aarch64 logs for the build in progress that you point to above, I believe that it is failing because the Imath/OpenEXR you have installed is 2.2, whereas OpenImageIO 2.5 requires a minimum OpenEXR 2.4. (Current OpenEXR is 3.2, so we're talking about extraordinarily old.)

At least in that log, it's not getting anywhere near far enough in the build for the NEON patch to be relevant. It fails just trying to find dependencies.

[darix]

I will force newer BuildRequires.

[lgritz]

For reference, OpenEXR 2.4 was released in 2019.

[lgritz]

@hobbes1069 Your error was definitely on the NEON part. Please do let me know (if you can check) whether the patch from this PR gets you unstuck.