On Thu, Aug 16, 2012 at 11:29:53AM +0100, Måns Rullgård wrote: > 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.
Indeed, brainfart from my side. Please merge the comments nonetheless. I feel obliged to raise one more point though: On x86 we error out if (yasm) optimizations will not be included in the build, why not here? Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
