Rémi Denis-Courmont:
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?
Indeed.
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.
Before d5733936, ffmpeg would crash on startup on e500v2 when the
binary tried to use the unsupported instruction (when built with
default configuration). At d5733936 it works as the instruction is
disabled.
At some point between d5733936 and HEAD, a default "configure" run for
this CPU re-enabled the instruction, causing it again to crash on
startup. Since the configure script was changed to set "disable" in
the CPU selection header:
e500v2)
cpuflags="-mcpu=8548 -mhard-float -mfloat-gprs=double"
disable altivec
disable dcbzl <--- here
(which I believe came in from the avconf fork merge), my patch fixes
the ppc-specific branch to check if it was disabled in the above
stanza.
Normally, you would expect that the default flags result in something
that works, if perhaps not optimally, no?
Exactly, this is what I am trying to (re-)fix.
(And yes, I know that the CPU I am running on is end-of-life, but the
joy of working with embedded hardware is that you have to support it
anyway.)
--
\\// Peter - http://www.softwolves.pp.se/
_______________________________________________
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".
