Fix various typos

Various typo fixes

NEWS

@@ -246,7 +246,7 @@ FFTW 3.3
 
 * 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
+  Remove the --with-gcc-arch flag; if you want to specify a particular
   arch to configure, use ./configure CC="gcc -mtune=...".
 
 * --with-our-malloc16 configure flag is now renamed --with-our-malloc.

api/malloc.c

@@ -32,7 +32,7 @@ void X(free)(void *p)
 }
 
 /* The following two routines are mainly for the convenience of
-   the Fortran 2003 API, although C users may find them convienent
+   the Fortran 2003 API, although C users may find them convenient
    as well.  The problem is that, although Fortran 2003 has a
    c_sizeof intrinsic that is equivalent to sizeof, it is broken
    in some gfortran versions, and in any case is a bit unnatural

bootstrap.sh

@@ -2,7 +2,7 @@
 ############################################################################
 #
 # NOTE: If you just want to build FFTW, do not use this file.  Just use
-# the ordinary ./configure && make commmands as described in the installation
+# the ordinary ./configure && make commands as described in the installation
 # section of the manual.
 #
 # This file is only for users that want to generate their own codelets,

doc/FAQ/fftw-faq.bfnn

@@ -462,7 +462,7 @@ vice versa) yields the original array scaled by the size of the array.
 (For multi-dimensional transforms, the size of the array is the
 product of the dimensions.)  We could, instead, have chosen a
 normalization that would have returned the unscaled array. Or, to
-accomodate the many conventions in this matter, the transform routines
+accommodate the many conventions in this matter, the transform routines
 could have accepted a "scale factor" parameter. We did not do this,
 however, for two reasons. First, we didn't want to sacrifice
 performance in the common case where the scale factor is 1. Second, in

doc/modern-fortran.texi

@@ -570,7 +570,7 @@ It is also possible to use the lower-level routines
 type @code{FILE*}, expressed in Fortran as @code{type(C_PTR)}.
 However, you are then responsible for creating the @code{FILE*}
 yourself.  You can do this by using @code{iso_c_binding} to define
-Fortran intefaces for the C library functions @code{fopen} and
+Fortran interfaces for the C library functions @code{fopen} and
 @code{fclose}, which is a bit strange in Fortran but workable.
 
 @c =========>

doc/mpi.texi

@@ -1238,7 +1238,7 @@ void fftw_mpi_execute_r2r(fftw_plan p, double *in, double *out);
 These functions have the same restrictions as those of the serial
 new-array execute functions.  They are @emph{always} safe to apply to
 the @emph{same} @code{in} and @code{out} arrays that were used to
-create the plan.  They can only be applied to new arrarys if those
+create the plan.  They can only be applied to new arrays if those
 arrays have the same types, dimensions, in-placeness, and alignment as
 the original arrays, where the best way to ensure the same alignment
 is to use FFTW's @code{fftw_malloc} and related allocation functions

doc/tutorial.texi

@@ -372,7 +372,7 @@ even) elements of the complex output are purely real.  Some
 implementations therefore store the Nyquist element where the DC
 imaginary part would go, in order to make the input and output arrays
 the same size.  Such packing, however, does not generalize well to
-multi-dimensional transforms, and the space savings are miniscule in
+multi-dimensional transforms, and the space savings are minuscule in
 any case; FFTW does not support it.
 
 An alternative interface for one-dimensional r2c and c2r DFTs can be

genfft/schedule.ml

@@ -27,7 +27,7 @@
    resulting schedule data structure expresses a "good" ordering
    and structure for the computation.
 
-   The scheduler makes use of utilties in Dag and other packages to
+   The scheduler makes use of utilities in Dag and other packages to
    manipulate the Dag and the instruction list. *)
 
 open Dag

kernel/cpy2d.c

@@ -172,7 +172,7 @@ void X(cpy2d_tiled)(R *I, R *O,
 {
      INT tilesz = X(compute_tilesz)(vl,
 				    1 /* input array */
-				    + 1 /* ouput array */);
+				    + 1 /* output array */);
      struct cpy2d_closure k;
      k.I = I;
      k.O = O;

kernel/ifftw.h

@@ -653,7 +653,7 @@ enum {
 /* hashtable information */
 enum {
      BLESSING = 0x1u,   /* save this entry */
-     H_VALID = 0x2u,    /* valid hastable entry */
+     H_VALID = 0x2u,    /* valid hashtable entry */
      H_LIVE = 0x4u      /* entry is nonempty, implies H_VALID */
 };
 

m4/Makefile.am

@@ -4,5 +4,5 @@ ax_gcc_aligns_stack.m4 ax_gcc_version.m4 ax_openmp.m4
 
 # libtool sticks a bunch of extra .m4 files in this directory,
 # but they don't seem to be needed for the distributed tarball
-# (they aren't needed for configure && make, and boostrapping
+# (they aren't needed for configure && make, and bootstrapping
 # will regenerate them anyway).

m4/ax_gcc_version.m4

@@ -1,5 +1,5 @@
 dnl @synopsis AX_GCC_VERSION(MAJOR, MINOR, PATCHLEVEL, [ACTION-SUCCESS], [ACTION-FAILURE])
-dnl @summary check wither gcc is at least version MAJOR.MINOR.PATCHLEVEL
+dnl @summary check whether gcc is at least version MAJOR.MINOR.PATCHLEVEL
 dnl @category InstalledPackages
 dnl
 dnl Check whether we are using gcc and, if so, whether its version