Omr: Investigate the challenges in downgrading Tril's minimum compiler version

[mgaudet]

There is some desire to use Tril in contexts where the compiler may not have full C++11 support; most of the compiler technology outside Tril is capable of building in this situation.

It would be good to know exactly what kind of changes would be required to lower the minimum compiler version, and what features we'd lose or be forced to make conditional on language support version.

[fjeremic]

In particular attempting to build Tril on Linux on z with g++ 4.4.6 will not work due to missing C++11 support.

[mgaudet]

When thinking about this, it might also be worthwhile to split the sizing effort in two: 1) The effort to get Tril, the parser and Ilgenerator up and running with older compilers and 2) the effort to get the test cases supported.

It may still be supremely useful to use Tril on older build compilers, even if the cost of converting the extent test cases would be prohibitive.

[Leonardo2718]

For Tril, I believe the only C++11 feature that is heavily relied upon is the <type_traits> standard library. Theoretically, the library could be implemented in pure C++03 (at least the parts that are used in Tril). However, doing so would require writing a fair bit of boilerplate template code.

Another C++11 feature that is somewhat used in Tril are template type aliases. Not having these would only be an inconvenience, leading to some duplicate code.

Everything else can either be worked around easily enough, or should already be supported by older compilers (e.g. auto).

For the Tril-based tests, in addition to the features I've mentioned above, some also use C++11 variadic templates. This will be quite tricky to replace, though it should be possible to create something that's close enough using std::pair.

[fjeremic]

As a temporary workaround I've compiled gcc 4.8.5 on my RHEL 6 and I am able to build Tril correctly now. Interestingly enough there are some test failures for which I'll open up issues for so it was a worth while exercise.

[mgaudet]

@rbanerjee is investigating downgrading the minimum supported version. We're not yet sure how complicated this will be, but are hopeful.

[fjeremic]

@rbanerjee is investigating downgrading the minimum supported version. We're not yet sure how complicated this will be, but are hopeful.

In my experience only ast.hpp caused problem because of the use of using = <some template> which we can work around with typedef. Best to hop onto a machine with gcc 4.4.6 and attempt to compile Tril then just fix problems as they come.

[rbanerjee]

So I'm done building tril (as in libtril.a) with GCC 4.4.6. triltest also builds and runs fine (all the tests pass).

[as @fjeremic mentioned most of the changes were in ast.hpp. The others only show up once you get past those. Namely in ilgen and jitbuilder_compiler.].

The next step would be to fix the compiler tests in examples (mandelbrot and incordec).

[lmaisons]

As there doesn't seem to be a PR for those changes yet, I'll add this here:

I'm worried that

#if __cplusplus <= 199711L

is going to cause us problems. I initially thought that it should be:

#if __cplusplus < 201103L

but then was made aware of the MSVC++ garbage fire related to the value of this pre-processor constant. We probably need some combination of __cplusplus and _MSVC_LANG, with the latter only existing post MSVC++ 2015, which, as far as I know, is sufficient for our purposes.

#if (__cplusplus < 201103L) || !defined(_MSVC_LANG)

[mgaudet]

PR is #1718