Re: [FFmpeg-devel] [PATCH v2] lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang

[Brad Smith <brad-at-comstyle.com@ffmpeg.org>]

On 2025-03-06 8:28 a.m., Ramiro Polla wrote:
> On Wed, Mar 5, 2025 at 4:17 AM Ramiro Polla<ramiro.polla@gmail.com> wrote:
>> On Wed, Mar 5, 2025 at 2:24 AM Brad Smith
>> <brad-at-comstyle.com@ffmpeg.org> wrote:
>>> On 2023-08-23 4:52 p.m., Michael Niedermayer wrote:
>>>> On Fri, Aug 18, 2023 at 10:14:04PM -0400, Brad Smith wrote:
>>>>> lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang
>>>>>
>>>>> Add a check for the existence of the vec_xl() function. Clang provides
>>>>> the function even with VSX not enabled.
>>>>>
>>>>> v2: test for function if AltiVec is enabled instead of with AltiVec and without VSX
>>>>> ---
>>>>>    configure                        | 8 ++++++++
>>>>>    libswscale/ppc/yuv2rgb_altivec.c | 4 ++--
>>>>>    2 files changed, 10 insertions(+), 2 deletions(-)
>>>> Has this been tested on an affected platform ?
>>>> I mean the function is provided but does it also work ?
>>> This has been in the FreeBSD / OpenBSD ports for years. So to a certain
>>> extent yes. Anyway, I didn't have access to my test VM for quite some
>>> time but I do now and ran the various tests with FATE and did not see
>>> any issues.
>> Build doesn't seem to fail anymore, but that's probably because of the
>> #if 0 from b9eaf6e05c2ca16d94869e0263236dbdac752400.
>>
>> Could you please send a rebased patch?
> I tested on Sean's G5 and this patch fixed the build issue with clang,
> so I pushed it.
>
> The code that uses vec_xl() is still under #if 0 though.

I have commit access. Also what you had commited was my v1 diff not v2. 
I will fix it.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".