Le 28 septembre 2022 15:52:46 GMT+03:00, Peter Krefting <pe...@softwolves.pp.se> a écrit : >Hi! > >>> The DCBZL instruction is not available for the e500v1 and e500v2 >>> architectures, but may still be recognized by the toolchain, so we need to >>> remove the test for it explicitly for these architectures. >> Isn't this the sort of thing that's supposed ti be guarded by run-time CPU >> flags rather than in the configure script? > >Our compiler (powerpc-btech-linux-gnuspe-gcc (crosstool-NG 1.24.0) 8.3.0) >recognizes the instruction, so the configure test succeeds, but the CPU >(e500v2) crashes if it tries to execute it.
Yes? >I previously had a patch (d5733936d857ce5c7d28c0bc9e89a2e2548f8895) to >suppress the instruction, but it broke at some point, this patch tries to fix >it in a slightly better way. AFAICT, this old changeset had the exact same problem as this patch. If somebody just compiles FFmpeg with default flags as one does, it remains broken. Normally, you would expect that the default flags result in something that works, if perhaps not optimally, no? I mean, the patch is basically correct in that it keeps DCBZL disabled if the selected CPU is known not to support it. Altivec already works the exact same way for that matter. But Altivec is also guarded at run-time, so it won't cause a crash if the target CPU is unspecified/unknown. Br, _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
