Red Hat Bugzilla – Bug 799675
It has come out new version for almost 2 years.Can RH update?
Last modified: 2014-06-16 06:32:53 EDT
see the release note at:http://www.fftw.org/release-notes.html
Well,I think this should be keep up-to-date.
new verison contains new features and bugfix.As the official says,
"Reduced planning time in estimate mode for sizes with large prime factors.
Added AVX autodetection under Visual Studio. Thanks Carsten Steger for submitting the necessary code.
Modern Fortran interface now uses a separate fftw3l.f03 interface file for the long double interface, which is not supported by some Fortran compilers. Provided new fftw3q.f03 interface file to access the quadruple-precision FFTW routines with recent versions of gcc/gfortran."
Added support for the NEON extensions to the ARM ISA. (Note to beta users: an ARM cycle counter is not yet implemented; please contact email@example.com if you know how to do it right.)
MPI code now compiles even if mpicc is a C++ compiler; thanks to Kyle Spyksma for the bug report.
Compiling OpenMP support (--enable-openmp) now installs a fftw3_omp library, instead of fftw3_threads, so that OpenMP and POSIX threads (--enable-threads) libraries can be built and installed at the same time.
Various minor compilation fixes, corrections of manual typos, and improvements to the benchmark test program.
Add support for the AVX extensions to x86 and x86-64. The AVX code works with 16-byte alignment (as opposed to 32-byte alignment), so there is no ABI change compared to FFTW 3.2.2.
Added Fortran 2003 interface, which should be usable on most modern Fortran compilers (e.g. gfortran) and provides type-checked access to the the C FFTW interface. (The legacy Fortran-77 interface is still included also.)
Added MPI distributed-memory transforms. Compared to 3.3alpha, the major changes in the MPI transforms are:
Fixed some deadlock and crashing bugs.
Added Fortran 2003 interface.
Added new-array execute functions for MPI plans.
Eliminated use of large MPI tags, since Cray MPI requires tags < 224; thanks to Jonathan Bentz for the bug report.
make check now runs MPI tests
Some ABI changes — not binary-compatible with 3.3alpha MPI.
Add support for quad-precision __float128 in gcc 4.6 or later (on x86. x86-64, and Itanium). The new routines use the fftwq_ prefix.
Removed support for MIPS paired-single instructions due to lack of available hardware for testing. Users who want this functionality should continue using FFTW 3.2.x. (Note that FFTW 3.3 still works on MIPS; this only concerns special instructions available on some MIPS chips.)
Removed support for the Cell Broadband Engine. Cell users should use FFTW 3.2.x.
New convenience functions fftw_alloc_real and fftw_alloc_complex to use fftw_malloc for real and complex arrays without typecasts or sizeof.
New convenience functions fftw_export_wisdom_to_filename and fftw_import_wisdom_from_filename that export/import wisdom to a file, which don't require you to open/close the file yourself.
New function fftw_cost to return FFTW's internal cost metric for a given plan; thanks to Rhys Ulerich and Nathanael Schaeffer for the suggestion.
The --enable-sse2 configure flag now works in both double and single precision (and is equivalent to --enable-sse in the latter case).
Remove --enable-portable-binary flag: we new produce portable binaries by default.
Remove the automatic detection of native architecture flag for gcc which was introduced in fftw-3.1, since new gcc supports -mtune=native. Remove the --with-gcc-arch flag; if you want to specify a particlar arch to configure, use ./configure CC="gcc -mtune=...".
--with-our-malloc16 configure flag is now renamed --with-our-malloc.
Fixed build problem failure when srand48 declaration is missing; thanks to Ralf Wildenhues for the bug report.
Fixed bug in fftw_set_timelimit: ensure that a negative timelimit is equivalent to no timelimit in all cases. Thanks to William Andrew Burnson for the bug report.
Fixed stack-overflow problem on OpenBSD caused by using alloca with too large a buffer."
So I hope RH engineer can update the existed verison to the newest.
(In reply to comment #0)
> see the release note at:http://www.fftw.org/release-notes.html
> Well,I think this should be keep up-to-date.
> So I hope RH engineer can update the existed verison to the newest.
Christopher, I made a test build of fftw-3.3.1-3 for rhel6:
Can you try it and confirm that it works for you?
In case you cannot access brewweb.devel.redhat.com, I am attaching x86-64 packages to this bug. Let me know if you need help.
Created attachment 592689 [details]
Created attachment 592690 [details]
Created attachment 592691 [details]
Created attachment 592692 [details]
Created attachment 592693 [details]
Created attachment 592694 [details]
BTW,do you have x86 version of this?I run x86 servers...
Please find them attached.
Created attachment 596249 [details]
Created attachment 596250 [details]
Created attachment 596251 [details]
Created attachment 596252 [details]
Created attachment 596254 [details]
Created attachment 596255 [details]
I just forgot a additional question:
Will your update be pushed to @Base repo?
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.
Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
(In reply to comment #21)
> Red Hat invites you to ask your support representative to
> propose this request, if appropriate, in the next release of
> Red Hat Enterprise Linux.
Also, if you will tell that you used test packages and they work well for you, this makes approval more likely...
You can close this bug now. I've switched to Fedora.
Closing WONTFIX for RHEL 6. If the rebase of fftw is important for anyone watching this bug, please raise a ticket through proper product support ( https://access.redhat.com/support ), otherwise, engineering can't do rebase if not prioritized by support and product management.