On Thu, Aug 16, 2012 at 12:10:52AM +0100, Mans Rullgard wrote:
> There used to be one test for Altivec intrinsics support and a
> separate test to determine which of two possible syntaxes to use
> for vector literals. Since 2008, we only support the more common
> of these so the split test no longer makes sense.
>
> This combines the tests into one and also changes the hard error on
> failure to a warning. The test can reasonably fail if no --cpu flag
> is provided (or is provided with an unknown CPU) and the compiler
> default target does not support Altivec. Aborting in this case is
> probably over-reacting.
>
> --- a/configure
> +++ b/configure
> @@ -2873,17 +2873,14 @@ elif enabled ppc; then
> check_cc <<EOF || disable altivec
> $inc_altivec_h
> int main(void) {
> - vector signed int v1, v2, v3;
> - v1 = vec_add(v2,v3);
> + vector signed int v1 = (vector signed int) { 0 };
> + vector signed int v2 = (vector signed int) { 1 };
> + v1 = vec_add(v1, v2);
> return 0;
> }
> EOF
>
> - # check if our compiler supports braces for vector declarations
> - check_cc <<EOF || die "You need a compiler that supports {} in
> AltiVec vector declarations."
> -$inc_altivec_h
> -int main (void) { (vector int) {1}; return 0; }
> -EOF
> + enabled altivec || warn "Altivec disabled, possibly missing --cpu
> flag"
> fi
Merging the two tests is OK, but you should also merge the two comments
then. IIRC this caused a lot of grief back in the day when the compiler
did not support the syntax used in libavcodec. It would fail after a
long and expensive compile. Erroring out early in configure was done
on purpose. I believe we should keep that behavior, since the compile
error later on would be equally fatal.
Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
