The new constructor xt_redist_repeat_asym_new generalizes
xt_redist_repeat_new by having different displacement
vectors for source and destination side.

* YAXT Fortran bindings now offer equivalent and simpler functionality.

* -Wl,--start-group -Wl,--end-group -Wl,-\( -Wl,-) must preserve their
  respective position within the list of libraries to work as expected.

* The variables in question are known to change frequently but do not
  influence compilation results.

* sizeof should not be used for array parameters, it resolves to the size
  of a pointer. This just happened to work by chance because
  the actual computation always returned 1 (32-bit systems) or 2 (64-bit
  systems).

* This way the mysterious failure of gfortran 5.1 does not need to be
  documented and worked around at all.
  Good riddance.

* This way assumed size argument passing can be made to work for
  higher rank arrays, which does not work for generic interface
  resolution.

* gcc 5.1 optimizer assumes results will not change even though its address
  can legally escape.

* The corresponding problem occurs when the strides in question do not share
  divisors but the strides and the stripes' starts are at far apart
  positions, i.e. their difference is large.

* Fixup for 58136cd3.

* Using separate arrays is non-conforming, although expected to work
  on usual systems.

I've determined G95 has problems in the following areas:
* Performing INT conversion directly in the argument of a sub-program.
  But passing a variable of the correct type holding the converted
  value works fine.
* Creating PARAMETER arrays, where the iterator is of non-default kind.
  But converting the iterator value works.

* This makes G95 happy.

* Otherwise problems might occur when the destination library is already
  installed in an incompatible version, i.e. tests would link an old version.

* The alternative syntax is invalid in g95.

* Having data from different objects is not guaranteed to work.