autotools: towards uniformization of givaro and fflas-ffpack

[cyrilbouvier]

#184

TODO before merging:

• uniformize warnings flags (for now I used the same as in Givaro, I will look at what fflas was using before and try to find common ground)

• have the same detection for __int128. As for as I understand, Givaro tries to detect __int128_t and if it can be made unsigned, fflas-ffpack only tries to detect __int128_t. The current codes are

# Givaro
AC_CHECK_TYPE([__int128_t], [AC_TRY_COMPILE([#include <type_traits>], [std::make_unsigned<__int128_t>::type y;],[AC_DEFINE(HAVE_INT128, 1, [Define that compiler allows int128_t types])])])

# fflas-ffpack
AC_CHECK_TYPE([__int128_t], [AC_DEFINE(HAVE_INT128, 1, [Define that compiler allows int128_t types])])

The questions are: do we need the detection in both libraries ? If yes, do we use the same in both ?If yes, which version ?

• not directly related, but while I am looking at it: in travis.yml, we install libopenblas-dev with apt and then install OpenBlas from source: why do we do both ? why don't we just use the apt package ?
  (It would decrease Travis running time by 10min).

[cyrilbouvier]

While preparing this PR, I found a small issue in Givaro's configure.ac. I fixed this in commit
linbox-team/givaro@c97f5c5

As it was a very small change, I pushed it directly to master.

[ClementPernet]

* [ ]  uniformize warnings flags (for now I used the same as in Givaro, I will look at what fflas was using before and try to find common ground)

I let you deal with it. I don't see any problem copying the warning flags from Givaro.

* [ ]  have the same detection for __int128. As for as I understand, Givaro tries to detect __int128_t and if it can be made unsigned, fflas-ffpack only tries to detect __int128_t. The current codes are

The reason is probably that contrarily to Givaro, fflas-ffpack does not use/rely on unsigned int types.
Now, I can't imagine a setting where one would like to use int128_t in fflas but where Givaro fails at making them unsigned. Hence, we should probably just use in fflas-ffpack the detection made in Givaro.

* [ ]  not directly related, but while I am looking at it: in travis.yml, we install libopenblas-dev with apt and then install OpenBlas from source: why do we do both ? why don't we just use the apt package ?
  (It would decrease Travis running time by 10min).

At some point I could not get all travis build to work with the system libopenblas, therefore, I decided to compile it and left the command to apt install it. I can't remember the reason why. We should definitely try again and if possible avoid compile openblas. This is #294

[ClementPernet]

• For the int128_t case, recall that int128 on OSX and fedora givaro#95 explains why FFLAS's detection is decoupled from Givaro's. I suggest we leave the 2 detections distinct as it is currently the case.

[ClementPernet]

• @cyrilbouvier : any progress on the warnings?
  I think this is not maybe not a priority but having a consistent dectection of the optimization flags between Givaro and fflas-ffpack is, hence this PR should move forward.
  I would be happy to merge this PR now, and leave the uniformization of the warnings, and travis config to future PRs, as they are not directly related to the urgent need: getting rid of the SIMD detection in fflas-ffpack to be consistent with Givaro.

[cyrilbouvier]

• @cyrilbouvier : any progress on the warnings?
  I think this is not maybe not a priority but having a consistent dectection of the optimization flags between Givaro and fflas-ffpack is, hence this PR should move forward.
  I would be happy to merge this PR now, and leave the uniformization of the warnings, and travis config to future PRs, as they are not directly related to the urgent need: getting rid of the SIMD detection in fflas-ffpack to be consistent with Givaro.

The warnings were essentially the same, so I used the ones from Givaro.

I added some changes from #305 with commit 8604d3a

For me, this PR can be merged now.

[jgdumas]

Does not work. See Travis with GCC=4.9 :

../fflas-ffpack/fflas/fflas_simd/simd512_float.inl: In static member function ‘static Simd512_impl<true, false, true, 4>::vect_t Simd512_impl<true, false, true, 4>::blendv(Simd512_impl<true, false, true, 4>::vect_t, Simd512_impl<true, false, true, 4>::vect_t, Simd512_impl<true, false, true, 4>::vect_t)’:
../fflas-ffpack/fflas/fflas_simd/simd512_float.inl:199:48: error: ‘_mm512_castps512_ps256’ was not declared in this scope
__m256 lowa = _mm512_castps512_ps256(a);
^

[cyrilbouvier]

Does not work. See Travis with GCC=4.9

This is not a bug with fflas but with GCC 4.9 which does not support the full AVX512F specification.
The intrinsics '_mm512_castps512_ps256' was only added in GCC 5.1.0 (cf the changelog of gcc 5.1.0 line 29022).
Support for GCC < 5 was dropped in #334, so this is not a problem.