This bug was present all along, but something changed in the order
of de-initialisation performed by llvm that makes it actually
crash now.
The constructor of HipifyPPCallbacks gives:
```
std::unique_ptr<HipifyPPCallbacks>(this)
```
to the LLVM Preprocessor instance. The Preprocessor instance
subsequently frees the HipifyPPCallbacks, which is then freed
again when we leave the stack frame at line 4340.
So: let's leak the HipifyPPCallbacks onto the heap, and leave
the LLVM Preprocessor object responsible for tidying it up.
The Preprocessor smart pointer is held by the CompilerInstance,
and therefore its reference count cannot reach zero until the
CompilerInstance itself is destroyed.
If the CompilerInstance is destroyed, you have more to worry about
than just the preprocessor being deallocated!
Newer versions of the LLVM/Clang API migrated to using
std::shared_ptr, so there is no `Retain()` function (by that
name, anyway). Eliminating this redundant use is a neat and
backward-compatible way to become compatible with newer versions
of the LLVM/Clang API.
Newer versions of llvm/clang mean there is both an
llvm::StringLiteral and a clang::StringLiteral. Since we're
dumping both namespaces wholesale into the global namespace with
`using` declarations, this creates a name collision, which must be
resolved.
This change is backwards-compatible, and fixes a problem you
encounter when using newer versions of the llvm/clang API.
What we actually want to do here is use the StringRef version in
versions newer than 3.8, and the void one in 3.8 and older.
Checking "major-version >= 3 && minor-version >= 9" does not do
what we want. Consider what this will do for version 4.0, for
which minor-version is zero...
This copies to the output after operation, instead of working
_on_ the output. This allows includes to work correctly, while
supporting output paths anywhere on the filesystem.
Fixes#208Fixes#206
[Synopsis]
If any of kernel arguments is a MACRO its location calculation is wrong (location of its definition is actually calculated).
Thus garbage code is being produced on the place of such a MACRO starting from the end of its actual definition.
[Solution]
Add isMacroBodyExpansion and isMacroArgExpansion checks on kernel arguments.
[hipify-clang] Finally finished syncing with CUDA 8.0.61 Driver and Runtime API (including missing data types, D3D, OpenGL, VDPAU and EGL interop).
+ All the Modules are supported now:
1) 4.1 – 4.31 from CUDA 8.0.61 Driver API
2) CUDA_Driver_API_functions_supported_by_HIP.md updated accordingly
3) 4.1 – 4.31 from CUDA 8.0.61 Runtime API
4) CUDA_Runtime_API_functions_supported_by_HIP.md updated accordingly
+ Typos fixing
+ Annotating
+ CUDA_Driver_API_functions_supported_by_HIP.md update.
+ Initial update of HIPIFY with CUDA driver API functions:
1.Error Handling, 2.Initialization, 3.Version Management, 5-6.Device Management, 7.Primary Context, 8-9.Context, 10.Module Management, 11.Memory Management.
+ Sync HIP functions against CUDA Driver and Runtime API functions.
+ Typo fixes.
ToDo: 12-30 modules of CUDA Driver API.
+ Memory advise values
+ Memory Range Attributes
+ P2P Attributes
P.S.
There is no any new changes in CUDA Driver API 8.0.61 Data structures since 8.0.44.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/80
Example from CUDA 8.0.44 sample (CUDASamples\0_Simple\matrixMulDrv\matrixMulDrv.cpp):
CUjit_option *jitOptions = new CUjit_option[jitNumOptions];
where CUjit_option is enum, should be:
hipJitOption *jitOptions = new hipJitOption[jitNumOptions];
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/81
1. Do not use JIT options on HCC path, call hipModuleLoadData instead.
2. NVCC path is unchanged, to call cuModuleLoadDataEx with all options.
3. Get rid of manual hipification, based on #ifdef #else for NVCC/HIP.
4. Update documentation accordingly.
Some Clang tooling functions return std::string, some return StringRef. Assigning of returning std::string to StringRef variables leads to garbage in it.
DEBUG build is always affected.
+ Update CUDA_Driver_API_functions_supported_by_HIP.md.
+ Final update of HIPIFY with CUDA driver data types.
[TODO] Syncing HIPIFY and HIP by CUDA Driver API functions.
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/issues/71
[Solution]
getUnqualifiedType for enumConstantDecl's type is added, except ordinary enum declarations (w/o typedef).
[ToDo]
Find more appropriate way of distinguishing redefined enum declarations and ordinary ones.
+ Introduce CUDA_Driver_API_functions_supported_by_HIP.md.
+ Initial update of HIPIFY with CUDA driver data types.
+ Initial sync HIP types against CUDA Driver and Runtime API types.
+ Typo fixes.
+ all Cuda 7.5 RT API enum values are synced.
+ a few missing functions are added.
+ CONV_EXEC type is added for Execution control functions and data types.
Chris Kitching
Evgeny Mankov
Evgeny Mankov