./math/fftw, Fast C routines to compute DFTs (single and double precision)

[ CVSweb ] [ Homepage ] [ RSS ] [ Required by ] [ Add to tracker ]


Branch: CURRENT, Version: 3.3.10, Package name: fftw-3.3.10, Maintainer: pkgsrc-users

FFTW is a C subroutine library for computing the discrete Fourier transform
(DFT) in one or more dimensions, of arbitrary input size, and of both real
and complex data (as well as of even/odd data, i.e. the discrete cosine/sine
transforms or DCT/DST).

This package contains the single and double precision floating point FFTW
libraries.


Required to build:
[pkgtools/cwrappers]

Package options: simd

Master sites:

Filesize: 4046.973 KB

Version history: (Expand)


CVS history: (Expand)


   2021-10-26 12:56:13 by Nia Alarie | Files touched by this commit (458)
Log message:
math: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes
   2021-10-07 16:28:36 by Nia Alarie | Files touched by this commit (458)
Log message:
math: Remove SHA1 hashes for distfiles
   2021-09-29 15:34:48 by Thomas Klausner | Files touched by this commit (3) | Package updated
Log message:
fftw*: update to 3.3.10.

FFTW 3.3.10:

* Fix bug that would cause 2-way SIMD (notably SSE2 in double precision)
  to attempt unaligned accesses in certain obscure cases, causing
  segfaults.

  The following test triggers the bug (SSE2, double precision):

    ./tests/bench -oexhaustive r4*2:5:3

  This test computes a pair of length-4 real->complex transforms where
  the second input is 5 real numbers away from the first input.  That
  is, there is a gap of one real number between the first and second
  input array.  The -oexhaustive level allow FFTW to attempt to
  compute this transform by reducing it to a pair of complex
  transforms of length 2, but now the second input is not aligned to a
  complex-number boundary.  The fact that 5 is odd is the problem.

  The bug cannot occur in complex->complex transforms because the
  complex interface accepts strides in units of complex numbers, so
  strides are aligned by construction.

  This bug has been around at least since fftw-3.1.2 (July 2006), and
  probably since fftw-3.0 (2003).
   2021-06-12 09:30:47 by Nia Alarie | Files touched by this commit (1)
Log message:
fftw: bump for default options change
   2021-06-12 09:30:23 by Nia Alarie | Files touched by this commit (1)
Log message:
fftw: Disable "generic" GCC simd intrinsics

These produce poor code and it's always better to use the CPU-specific
intrinsics instead, which we already do on platforms where the test
suite doesn't fail.
   2021-05-24 21:56:06 by Thomas Klausner | Files touched by this commit (3575)
Log message:
*: recursive bump for perl 5.34
   2021-05-16 12:16:26 by Nia Alarie | Files touched by this commit (1)
Log message:
fftw: match future powerpc variants
   2021-05-16 12:14:09 by Nia Alarie | Files touched by this commit (5)
Log message:
split fftw package into -long and -quad precision variants

the package previously used PKG_OPTIONS for this, but PKG_OPTIONS
are harmful in the case that they effect the resulting ABI of
library packages. this way, things that actually need fftwl and fftwq
can depend on these sub-packages.

this also fixes fftwq on NetBSD by making it pull in libquadmath.
another thing about PKG_OPTIONS for library components is that
they mean certain components don't get tested...