Diego Biurrun <[email protected]> writes: > 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.
I don't understand what you are trying to say. It still checks for the same things, but disables altivec with a warning rather than aborting if the check fails. There will be no error later. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
