[infra] Support GCC as compiler for Taichi developers (experimental)

[archibate]

Related issue = #

[Click here for the format server]

---

IMO, GCC vs Clang ~= OpenGL vs CUDA: despite Clang is more fit with LLVM, but GCC is distributed on almost all *nix machines, we may also add mingw64 support later instead of the ad-hoc MSVC which is embed into that gaint IDE..

It also provides many useful warnings (much more than Clang) that might help us debug our C++ program.

[archibate]

Will update this message and doc when GCC is battle-tested.

[codecov]

Codecov Report

Merging #1598 into master will increase coverage by 0.11%.
The diff coverage is 47.45%.

@@            Coverage Diff             @@
##           master    #1598      +/-   ##
==========================================
+ Coverage   86.76%   86.87%   +0.11%     
==========================================
  Files          19       19              
  Lines        3679     3689      +10     
  Branches      653      654       +1     
==========================================
+ Hits         3192     3205      +13     
+ Misses        354      350       -4     
- Partials      133      134       +1     

Impacted Files	Coverage Δ
python/taichi/lang/shell.py	51.38% <47.45%> (+12.67%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f4ce50...bd90599. Read the comment docs.

[TH3CHARLie]

It would be great if GCC is supported.

It also provides many useful warnings (much more than Clang) that might help us debug our C++ program.

For this, I think maybe adding another build(possibly: master build, ubuntu, GCC and 3.7) to monitor and also show the effect of GCC. Since GCC support is now experimental, the build can be set to allow failure. It can happen within this PR or in a separate one, either way, having this would enable all taichi developers to monitor GCC progress and have a better context on it.

[yuanming-hu]

Thanks. LGTM.

It's worth mentioning that if someone uses the LLVM backend for development, clang is still needed to compile the runtime bitcode.

I guess you are trying to use the cc backend with gcc (and therefore you don't need the LLVM backend?)

It's nice that we can compile Taichi with gcc. Feel free to merge if it works on your end.

[archibate]

It's worth mentioning that if someone uses the LLVM backend for development, clang is still needed to compile the runtime bitcode.

Yes, but note that we don't need clang if one only do development on cc, opengl or metal, which are s2s backends. I didn't update the doc yet since it's experimental for now.

I guess you are trying to use the cc backend with gcc (and therefore you don't need the LLVM backend?)

Yes, that's my point: to allow contributors build and test on cc and opengl without LLVM - which is our configured one therefore needs to be build from source and easy to break - @FantasyVR in our WeChat group for example.
This make contributions to C++ part easier. To do so, we need something like TI_WITH_LLVM:BOOL=OFF, would you help me do this iapr when you've time?

It's nice that we can compile Taichi with gcc. Feel free to merge if it works on your end.

Yes, that's cool and many examples are functional! But some tests involving advanced features failed, maybe it's gcc -O3's fault, I'll try to fix them before merge, or iapr?

[yuanming-hu]

Thanks. All sounds good to me.

To do so, we need something like TI_WITH_LLVM:BOOL=OFF, would you help me do this iapr when you've time?

I think it's a good idea to add that flag. I do it when I have time, but I'm probably slow given my recent schedule. It can be a nice newcomer issue. Maybe we should open an issue and let new contributors help with that?

Yes, that's cool and many examples are functional! But some tests involving advanced features failed, maybe it's gcc -O3's fault, I'll try to fix them before merge, or iapr?

It's great that many examples are working! I'd suggest we do that in a different PR. Small PRs are always good.