One interesting thing about the EDG front end is that it can emulate all the others (and in various versions of the others) and what they support, and the errors they might detect.
It isn't perfect, but it is awfully good.
Another interesting thing is that in 1999ish, when SGI open-sourced the Irix compiler (known as sgicc) into open-64, the it used a terribly hacked version of gcc as a front end to generate its internal intermediate representation.
This was because sgicc, even back then, used EDG as a front end, and EDG wasn't open and couldn't be opened up at the time.
The combination worked OK, but was pretty hacky, and I wonder if open64 would have gotten more traction than it did if it had been able to use EDG, or perhaps some other front end actually designed as a front end instead of the hacky thing.
No, we only parse the language, do full semantic analysis, and optionally lower the representation to something that roughly matches C-language semantics. (That lowering can do some minimal inlining if needed, but that's a historical thing.)
We have two "back ends": c_gen_be.c generates C code from the lower IL ("intermediate language"; EDG's term for the AST) and cp_gen_be.c generates C++ code from the unlowered IL.
Several of our customers instrument the AST to add security-probing and/or other dynamic-analysis features.
NVCC uses it to separate out "device" constructs.
Yes. And this is why the nvcc preprocessor is so effective at working with the various host compilers. It emulates properties of the host compiler so that the device code and host agree on things.
But i could not find Thibaut Lutz's presentation slides linked to in the above discussion. Any idea where i can find it?
I presume the control flow in the above presentation is the same as found in "The CUDA Compilation Trajectory" chapter in the NVCC documentation (cudafe++ is EDG) - <a href="https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#the-cuda-compilation-trajectory" rel="nofollow">https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index...
That is quite interesting. I haven't thought much about source-to-source transformation within C++.
Do you have any articles/papers/books/etc. you can point us to for understanding this better?
Two usecases i have in mind are;
1) Transforming legacy C++98/C++03 codebases into "modern" C++11/14/17/20/23/26. Is this possible with current edg?
2) Adding verification conditions based on code analysis; both runtime contract asserts and compile time proofs (possible?) so as to convert "normal" C++ code into "somewhat verified" C++ code.
Some resources that Google brought up;
Challenges and Opportunities in C/C++ Source-To-Source Compilation - <a href="https://drops.dagstuhl.de/entities/document/10.4230/OASIcs.PARMA-DITAM.2023.2" rel="nofollow">https://drops.dagstuhl.de/entities/document/10.4230/OASIcs.P...
C++ Insights - See your source code with the eyes of a compiler - <a href="https://github.com/andreasfertig/cppinsights" rel="nofollow">https://github.com/andreasfertig/cppinsights Tool at <a href="https://cppinsights.io/" rel="nofollow">https://cppinsights.io/
compiler-guy · · focus · HN ↗
It isn't perfect, but it is awfully good.
Another interesting thing is that in 1999ish, when SGI open-sourced the Irix compiler (known as sgicc) into open-64, the it used a terribly hacked version of gcc as a front end to generate its internal intermediate representation.
This was because sgicc, even back then, used EDG as a front end, and EDG wasn't open and couldn't be opened up at the time.
The combination worked OK, but was pretty hacky, and I wonder if open64 would have gotten more traction than it did if it had been able to use EDG, or perhaps some other front end actually designed as a front end instead of the hacky thing.
feelamee · · focus · HN ↗
daveedvdv · · focus · HN ↗
We have two "back ends": c_gen_be.c generates C code from the lower IL ("intermediate language"; EDG's term for the AST) and cp_gen_be.c generates C++ code from the unlowered IL.
rramadass · · focus · HN ↗
daveedvdv · · focus · HN ↗
saagarjha · · focus · HN ↗
compiler-guy · · focus · HN ↗
You can see some discussion here:
<a href="https://forums.developer.nvidia.com/t/nvcc-preprocessing/64939/7" rel="nofollow">https://forums.developer.nvidia.com/t/nvcc-preprocessing/649...
rramadass · · focus · HN ↗
But i could not find Thibaut Lutz's presentation slides linked to in the above discussion. Any idea where i can find it?
I presume the control flow in the above presentation is the same as found in "The CUDA Compilation Trajectory" chapter in the NVCC documentation (cudafe++ is EDG) - <a href="https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#the-cuda-compilation-trajectory" rel="nofollow">https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index...
rramadass · · focus · HN ↗
Do you have any articles/papers/books/etc. you can point us to for understanding this better?
Two usecases i have in mind are;
1) Transforming legacy C++98/C++03 codebases into "modern" C++11/14/17/20/23/26. Is this possible with current edg?
2) Adding verification conditions based on code analysis; both runtime contract asserts and compile time proofs (possible?) so as to convert "normal" C++ code into "somewhat verified" C++ code.
Some resources that Google brought up;
Challenges and Opportunities in C/C++ Source-To-Source Compilation - <a href="https://drops.dagstuhl.de/entities/document/10.4230/OASIcs.PARMA-DITAM.2023.2" rel="nofollow">https://drops.dagstuhl.de/entities/document/10.4230/OASIcs.P...
C++ Insights - See your source code with the eyes of a compiler - <a href="https://github.com/andreasfertig/cppinsights" rel="nofollow">https://github.com/andreasfertig/cppinsights Tool at <a href="https://cppinsights.io/" rel="nofollow">https://cppinsights.io/
rramadass · · focus · HN ↗