Remove support for GCC 7 and 8

[awvwgk]

Edit: see discussion here for motivation for dropping GCC 7 and 8 support.

• remove GCC 8.1 from Windows workflow
• remove GCC 7.5 and GCC 8.4 from Ubuntu/MacOS workflow
• remove GCC workaround from stdlib_string_type
• move GCC <9 from supported to failing compilers
• create error in CMake for too old GCC version

[ivan-pi]

All looks good to me.

[jvdp1]

LGTM, pending one minor comment

[LKedward]

I'm reading the README and it's not clear which issues were causing problems with GCC<9 on Ubuntu/MacOS - I though #296 only affected Windows? (Apologies if I missed something)

[Romendakil]

In general, I think ropping older compiler versions is fine, however, I don't know what the vision is for stdlib. I'd assume that the goal would be to deliver stdlib as a precompiled library on OS in a similar fashion as libstdc++. This would mean that LTS OS versions which still have gcc 7/8 as their main compiler (Ubuntu 18 e.g.) could support stdlib only as an addition to their special gcc-9 and newer packages, but not for their system compiler.

[awvwgk]

I'm reading the README and it's not clear which issues were causing problems with GCC<9 on Ubuntu/MacOS

We are using one feature implemented in GCC 9 and later for stdlib_string_type, which was using a workaround before:

stdlib/src/stdlib_string_type.fypp

Lines 1244 to 1246 in 1c86812

	! GCC 8 and older cannot evaluate pure derived type procedures here
	!character(len=len(string)) :: maybe_string
	character(len=:), allocatable :: maybe_string

Also, for #420 we hit an issue where GCC 9 and later were required for usage with the real and imaginary component selectors

stdlib/src/stdlib_math_linspace.fypp

Lines 68 to 69 in e62f3fc

	x = linspace(start%re, end%re, n)
	y = linspace(start%im, end%im, n)

In general, I think ropping older compiler versions is fine, however, I don't know what the vision is for stdlib. I'd assume that the goal would be to deliver stdlib as a precompiled library on OS in a similar fashion as libstdc++. This would mean that LTS OS versions which still have gcc 7/8 as their main compiler (Ubuntu 18 e.g.) could support stdlib only as an addition to their special gcc-9 and newer packages, but not for their system compiler.

I have mixed feelings about LTS support of compilers, some project require me to write code compatible with GCC 4.9, the conda-forge Windows toolchain is running on GCC 5.3 and won't get updated any time soon. Using old GCC versions really limits the available features and the known bugs and issues can become tedious to workaround. Sticking with the supported compilers by GCC sounds like the easiest solution for me.

There are currently two lines of code that break GCC 7/8 support, which can be easily reverted, #420 could also be adapted to be compatible with GCC 7/8 without much problems. If we want to keep supporting those versions, this is still easily possible right now. And I'm open to reverting this patch.

[LKedward]

Thanks for the explanation @awvwgk - I had missed the discussion in #420 so this PR was a little out of the blue. I've updated the PR description for anyone else who ends up here from the README.

Sticking with the supported compilers by GCC sounds like the easiest solution for me.

This is probably the key point here, particularly regarding bugs and the future development/maintainability of stdlib, so this seems fine to me 👍