[patch] FFT fixes, GHS/Mercury fixes

[Jules Bergmann]

This patch cleans up several bugs in the FFT IPP backend.  First, for 
2-D FFTs the IPP backend was constructing a plan with rows and columns 
swapped.  This was previously hidden by the sizeof bug in the fft test. 
  Second, for FFTMs, plans were being destroyed with the wrong-dimension 
function.  This was previously hidden by the Fft_imp memory leak.  In 
addition, this patch changes the FFT IPP backend to use the new 
alloc_align signature.

This patch fixes some problems with the FFT test cleanup that were not 
exposed testing against SAL.

On the Mercury side, this patch adds template instantiation pragmas to 
signal-window for template functions it uses.  This is necessary because 
Greenhills uses an automated template instantiation algorithm that 
instantiates the necessary templates at link time and assigns them to a 
single object file (to avoid multiple definitions) (these are the 
"prelinker" messages).  Since signal-window is compiled as part of the 
library, its source is not be available when the application is linked. 
  I made some functions used by signal-window inline instead of adding 
pragmas (in particular small functions in signal-fft, and operators in 
fns_elementwise).

This patch disables all uses of SAL mat_mul when VSIP_IMPL_USE_MAT_MUL 
is 0 (even when no alternative SAL routine exists).

This patch adds support for split-complex convolution.

This patch adds configure tests to check if acosh is provided 
(greenhills cmath defines it, but mercury's libc does not provide it).


Stefan, do the FFT changes look OK?  Also, is it OK to inline the 
operators / functions in fns_elementwise?

Don, do the SAL changes look OK?

				thanks,
				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mc3.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060305/bbd21673/attachment.ksh>