Fix various typos (#385)

Found via `codespell -q 3 -L aadd,aci,alo,fo,inout,intot,mone,nam,nd,ois,re-use,re-used,re-using,rin,shft,twon`

Author: luzpaz

mpi/api.c

@@ -51,7 +51,7 @@ static MPI_Comm problem_comm(const problem *p) {
 /* used to synchronize cost measurements (timing or estimation)
    across all processes for an MPI problem, which is critical to
    ensure that all processes decide to use the same MPI plans
-   (whereas serial plans need not be syncronized). */
+   (whereas serial plans need not be synchronized). */
 static double cost_hook(const problem *p, double t, cost_kind k)
 {
      MPI_Comm comm = problem_comm(p);

mpi/f03api.sh

@@ -9,7 +9,7 @@
 #   include 'fftw3-mpi.f03'
 # and then call the C FFTW MPI functions directly, with type checking.
 #
-# One caveat: because there is no standard way to conver MPI_Comm objects
+# One caveat: because there is no standard way to convert MPI_Comm objects
 # from Fortran (= integer) to C (= opaque type), the Fortran interface
 # technically calls C wrapper functions (also auto-generated) which
 # call MPI_Comm_f2c to convert the communicators as needed.

mpi/mpi-bench.c

@@ -789,7 +789,7 @@ void main_init(int *argc, char ***argv)
 
      /* init_threads must be called before any other FFTW function,
 	including mpi_init, because it has to register the threads hooks
-	before the planner is initalized */
+	before the planner is initialized */
 #ifdef HAVE_SMP
      if (threads_ok) { BENCH_ASSERT(FFTW(init_threads)()); }
 #endif

rdft/vrank3-transpose.c

@@ -504,7 +504,7 @@ static const transpose_adt adt_cut =
  */
 
 /*
- * "a" is a 1D array of length ny*nx*N which constains the nx x ny
+ * "a" is a 1D array of length ny*nx*N which contains the nx x ny
  * matrix of N-tuples to be transposed.  "a" is stored in row-major
  * order (last index varies fastest).  move is a 1D array of length
  * move_size used to store information to speed up the process.  The

simd-support/simd-avx-128-fma.h

@@ -172,7 +172,7 @@ static inline V VCONJ(V x)
 
            V pmpm = VLIT(-0.0, 0.0);
 
-        but historically some compilers have ignored the distiction
+        but historically some compilers have ignored the distinction
         between +0 and -0.  It looks like 'gcc-8 -fast-math' treats -0
         as 0 too.
       */

simd-support/simd-avx.h

@@ -187,7 +187,7 @@ static inline void STN2(R *x, V v0, V v1, INT ovs)
 static inline __m128d VMOVAPD_LD(const R *x)
 {
      /* gcc-4.6 miscompiles the combination _mm256_castpd128_pd256(VMOVAPD_LD(x))
-	into a 256-bit vmovapd, which requires 32-byte aligment instead of
+	into a 256-bit vmovapd, which requires 32-byte alignment instead of
 	16-byte alignment.
 
 	Force the use of vmovapd via asm until compilers stabilize.
@@ -258,7 +258,7 @@ static inline V VCONJ(V x)
 
            V pmpm = VLIT(-0.0, 0.0);
 
-        but historically some compilers have ignored the distiction
+        but historically some compilers have ignored the distinction
         between +0 and -0.  It looks like 'gcc-8 -fast-math' treats -0
         as 0 too.
       */

simd-support/simd-avx2-128.h

@@ -186,7 +186,7 @@ static inline V VCONJ(V x)
 
            V pmpm = VLIT(-0.0, 0.0);
 
-        but historically some compilers have ignored the distiction
+        but historically some compilers have ignored the distinction
         between +0 and -0.  It looks like 'gcc-8 -fast-math' treats -0
         as 0 too.
       */

simd-support/simd-avx2.h

@@ -191,7 +191,7 @@ static inline void STN2(R *x, V v0, V v1, INT ovs)
 static inline __m128d VMOVAPD_LD(const R *x)
 {
      /* gcc-4.6 miscompiles the combination _mm256_castpd128_pd256(VMOVAPD_LD(x))
-	into a 256-bit vmovapd, which requires 32-byte aligment instead of
+	into a 256-bit vmovapd, which requires 32-byte alignment instead of
 	16-byte alignment.
 
 	Force the use of vmovapd via asm until compilers stabilize.
@@ -260,7 +260,7 @@ static inline V VCONJ(V x)
 
            V pmpm = VLIT(-0.0, 0.0);
 
-        but historically some compilers have ignored the distiction
+        but historically some compilers have ignored the distinction
         between +0 and -0.  It looks like 'gcc-8 -fast-math' treats -0
         as 0 too.
       */

simd-support/simd-common.h

@@ -20,7 +20,7 @@
 
 /* detection of alignment.  This is complicated because a machine may
    support multiple SIMD extensions (e.g. SSE2 and AVX) but only one
-   set of alignment contraints.  So this alignment stuff cannot be
+   set of alignment constraints.  So this alignment stuff cannot be
    defined in the SIMD header files.  Rather than defining a separate
    set of "machine" header files, we just do this ugly ifdef here. */
 #if defined(HAVE_SSE2) || defined(HAVE_AVX) || defined(HAVE_AVX2) || defined(HAVE_AVX_128_FMA) || defined(HAVE_AVX512)

simd-support/simd-maskedsve.h

@@ -71,7 +71,7 @@ typedef DS(svfloat64_t, svfloat32_t) V;
 
 /* The goal is to limit to the required width by using masking.
  * However, some SVE instructions are limited to two-addresses
- * rather than three adresses when masked.
+ * rather than three addresses when masked.
  * (i.e. they do X op= Y, not X = Z op X)
  * Loads will put zero in masked-out value.
  * For performance reason, we want to use non-masked for the instructions