Explicitly document which versions of GCC / clang are supported

[mithro]

Proposed Behaviour

It would be good if the documentation explicitly said which versions of GCC and clang were supported. We can then run make sure these versions compile on the CI system.

FYI - The compilers released by Ubuntu can be found here;
https://gist.github.com/mithro/85c97dd594a8726d081c57b2b541630e

Possible Solution

I suggest the following list;

• gcc-5 -- To support default compiler on Ubuntu Xenial (which is an LTS).
• gcc-6 -- To support default compiler on Debian Stretch.
• gcc-8 -- To support Debian testing + unstable and Ubuntu bionic (LTS) + cosmic.
• gcc-9 -- To support Ubuntu disco + eoan.
• clang-3.6 -- Earliest reasonable version of clang.
• clang-6 -- Earliest reasonable version of clang.
• clang-8 -- Latest released version of clang.

I don't use Redhat / Fedora, so I don't know if this covers a good range of compilers.

[mithro]

It might be worth supporting clang-6 which seems to be available in Debian testing+unstable plus Ubuntu xenial -> eoan.

[mithro]

Here is an example of running the compiles after Build / Testing is a success

• Commit -> 438a975
• Example build -> https://travis-ci.org/mithro/vtr-verilog-to-routing/builds/539482119

[mithro]

Looks like the build bot checks the following configurations;

vtr-verilog-to-routing/sweep_build_configs.py

Lines 14 to 16 in 81d1673

	DEFAULT_GNU_COMPILER_VERSIONS=["8", "7", "6", "5", "4.9"]
	DEFAULT_MINGW_COMPILER_VERSIONS=["5"]
	DEFAULT_CLANG_COMPILER_VERSIONS=["3.8", "3.6"]

[mithro]

@kmurray -- This is a question for you and @vaughnbetz

[mithro]

Just FYI the current status seems to be;

• GCC 5 works
• GCC 6 works
• GCC 8 fails due to LTO issue Internal compiler error when building with GCC 8.0 (on Travis) #628
• GCC 9 fails due to LTO issue Internal compiler error when building with GCC 8.0 (on Travis) #628
• clang 3.6 fails with VtR fails to compile with clang-3.6 #629
• clang 6.0 currently running...
• clang 8 fails due to an LTO issue (mayve Internal compiler error when building with GCC 8.0 (on Travis) #628)

[kmurray]

What is in sweep_build_configs.py is what we currently test the code builds against. And we generally try to keep it warning clean for the GCC compilers.

Effectively our requirement is a C++14 compliant compiler.

However I've been contemplating dropping gcc-4.9, since:

• Ubuntu 14.04 LTS is now EOL
• It isn't fully C++14 compliant (there are a couple corners of the syntax which we've had to work around). For example see this build error.

I'm leaning towards making the VTR 8.0 release with gcc-4.9 tested, and then drop it from the list of tested compilers shortly afterwards.

[mithro]

@kmurray It might be better to drop gcc-4.9 support before VtR 8.0 release to stop people using it as an excuse to use VtR 8.0 verses upstream.

[mithro]

Update on the status! Thanks to @kmurray's fixing of #628 we are pretty close to having everything working. See https://travis-ci.org/verilog-to-routing/vtr-verilog-to-routing/builds/541097847

Just FYI the current status seems to be;

• GCC 5 works
• GCC 6 works
• GCC 8 works (seemed to have fixed Internal compiler error when building with GCC 8.0 (on Travis) #628)
• GCC 9 works (seemed to have issue Internal compiler error when building with GCC 8.0 (on Travis) #628)
• clang 3.6 fails with VtR fails to compile with clang-3.6 #629
• clang 6 works
• clang 8 works

So, it only looks like clang-3.6 is broken!

[litghost]

FYI @kmurray, I'm seeing test failures on GCC 6 and clang 7 (at 988f670):

soft_multipliers:         k6_frac_N10_4add_2chains_depop50_mem20K_22nm.xml/mult_5x5.v/common                             failed: vpr (exited with return code 2) (took 3.02 seconds)
multiclock:               k6_frac_N10_mem32K_40nm.xml/multiclock.blif/common                                             OK              (took 1.40 seconds)
soft_multipliers:         k6_frac_N10_4add_2chains_depop50_mem20K_22nm.xml/mult_8x8.v/common                             OK              (took 4.94 seconds)
soft_multipliers:         k6_frac_N10_4add_2chains_depop50_mem20K_22nm.xml/mult_6x6.v/common                             OK              (took 5.07 seconds)
no_timing:                k6_frac_N10_frac_chain_depop50_mem32K_40nm.xml/ch_intrinsics.v/common                          failed: vpr (exited with return code 139) (took 5.14 seconds)
eblif_vpr:                k6_frac_N10_40nm.xml/test_eblif.eblif/common                                                   OK              (took 1.15 seconds)
fracturable_luts:         k6_N8_I80_fleI10_fleO2_ff2_nmodes_2.xml/ch_intrinsics.v/common                                 failed: vpr (exited with return code 139) (took 5.73 seconds)

[vaughnbetz]

Kevin can't reproduce these either; do they still occur?

[mithro]

@acomodi Can you close out this issue (IE Check that everything is the same and then close it.)

[acomodi]

@mithro I have checked that all the current builds (GCC-5/6/7/8/9 and Clang-6/8) do pass the strong regression tests. I can confirm this can be closed now.
I am unable to close the issue though, probably because I wasn't the original author of the issue.

[vaughnbetz]

Thanks @acomodi!