Diego Biurrun <[email protected]> writes: > 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.
There is no need. The braces mentioned in the second comment _are_ the Motorola syntax. > 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? Very simple. Yasm is a tool separate from the compiler that, if missing, would result in an extremely slow build. The Altivec intrinsics are supported by every compiler capable of building Libav at all (and a few more). The only sane reason the test can fail is someone building for a target lacking Altivec without passing a --cpu option we recognise as such. Insisting on explicitly disabling Altivec in such situations would be inconsistent with how we handle optional features on other targets. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
