Is it possible to run the multiple binaries of one type of compilers

[xinyi-li7]

Feature Request

Can it support multiple binaries for one type of compiler?

Description:

Sometimes we want to test different versions of one type of compiler.

Moreover, in my case, I have a modified compiler named clang++-fpchecker which is based on clang++. I want to run bothclang++-fpchecker and clang++. But now, I need to build and run them separately. I was wondering if we could run these compilers together in one build and run.

Suggested change:

A clear and concise description of what you want to happen. Add any considered drawbacks. You can also specify potential design or architecture directions with planned implementation details.

Alternative approaches:

A clear and concise description of any alternative solutions or features you've considered.

[JohnJacobsonIII]

Yes, you can do this by adding each compiler to the .toml file (i.e. treat clang-6.0 and clang 7.0 as separate compilers in your config.)

I'm not sure this would be a good approach with using FPChecker as this will cause FLiT to instrument every file anyway. I'm not sure what would happen with the output, or what the instrumented object files would do when linked with the non-instrumented object files. (@ilagunap might have better input on this.)

If you want to run FPChecker on the entire codebase, it probably makes more sense to just bypass FLiT and compile the entire thing with clang++-fpchecker and check the output.

For combining these utilities, I think it makes more sense to apply these in a pipeline, i.e. run FLiT to identify trouble files then apply FPChecker to this limited file scope. I have an example of this if this is relevant to what you're trying to do.

[mikebentley15]

For a regular FLiT run, yes you can use multiple different compilers. You just need to create the appropriate entries in the flit-config.toml file. See

https://github.com/PRUNERS/FLiT/blob/devel/documentation/standard-c++-library-implementations.md

The main trickiness comes when you want to use FLiT Bisect. You just need to make sure that they are using the same standard library. This is documented in

https://github.com/PRUNERS/FLiT/blob/devel/documentation/standard-c++-library-implementations.md

You may need to specify some compiler flags to the non-system compiler to use the correct libraries, include directories, and link against the correct libraries. Some of that is in the page above detailing the standard C++ library implementation.

For a regular flit run, it should be fine to use the fpchecker version. But FLiT Bisect might choke because you may be breaking ABI guarantees that the compiler assumes. You're welcome to give it a try, but there are no guarantees.

[xinyi-li7]

Hi John, Mike Thanks for your quick response. However, if I add a new compiler entry, say clang++-12 in the .toml file under the clang type, it will give me the error flit-config.toml: cannot have multiple compilers of the same type (clang). Should I remove the type attribute?

[mikebentley15]

That does sound familiar. Sorry, it's been so long since I've actually touched this code...

It looks like this has been documented in issue #40. This issue was mentioned in pull requests #301 and #309. I guess I never got around to figuring out a way to resolve this issue.

The problem stems from the way we are storing the different flags and behavior for each compiler. The Makefile variable names are tied to the type of compiler rather than some other unique identifier. This is implemented in scripts/flitcli/flit_update.py which uses the Makefile template data/Makefile.in.

I think Ian got around this issue when running experiments by having more than one toml config file, then copying the test directory with a different toml file and running them individually. Would this workaround work for you until we implement #40?

You're more than welcome to try to implement #40 and issue a pull request. We would be happy to provide guidance and assist when we can.

[xinyi-li7]

Hi Mike, Yes! Running separately works for me! I got the idea; I think I could try to fix this when I get time. Thanks!