[PATCH] D49486: [cfe][CMake] Export the clang resource directory
philip.pfaffe added a comment. Ping. https://reviews.llvm.org/D49486 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D49486: [cfe][CMake] Export the clang resource directory
philip.pfaffe added a comment. I had not, but it should work just as well! https://reviews.llvm.org/D49486 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52814: [PassManager/Sanitizer] Enable usage of ported AddressSanitizer passes with -fsanitize=address
philip.pfaffe added a comment. You're right, my bad; I missed the fact that it's EP_OptimizerLast, which has no equivalent in the new PM. Your implementation is actually correct here. Did you run your test in a debug build? Repository: rC Clang https://reviews.llvm.org/D52814 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52814: [PassManager/Sanitizer] Enable usage of ported AddressSanitizer passes with -fsanitize=address
philip.pfaffe accepted this revision. philip.pfaffe added a comment. This revision is now accepted and ready to land. LGTM, thank you! Repository: rC Clang https://reviews.llvm.org/D52814 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D49486: [cfe][CMake] Export the clang resource directory
philip.pfaffe abandoned this revision. philip.pfaffe added a comment. It looks like running clang will be good enough. I'm closing this for now! https://reviews.llvm.org/D49486 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56935: [NewPM] Add support for new-PM plugins to clang
philip.pfaffe added a comment. This generally looks sane. What will happen on windows though? Will it silently fail? Comment at: clang/include/clang/Basic/CodeGenOptions.h:292 + /// List of dynamic shared object files to be loaded as pass plugins. + std::vector PassPlugins; + This should be SmallVector. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56935/new/ https://reviews.llvm.org/D56935 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56935: [NewPM] Add support for new-PM plugins to clang
philip.pfaffe added a comment. I'm not sure what the current state of plugins on windows is. They were broken and disabled last time I worked on this, but that might've changed in the meantime! Worth checking. Comment at: clang/include/clang/Basic/CodeGenOptions.h:292 + /// List of dynamic shared object files to be loaded as pass plugins. + std::vector PassPlugins; + melver wrote: > philip.pfaffe wrote: > > This should be SmallVector. > Not sure if this is better. getAllArgValues returns a vector, which > is why I think the above members are also vector. And std::vector > cannot be assigned to SmallVector, which required an extra line in > CompilerInvocation.cpp. > > Let me know what you think. You're right, SmallVector doesn't actually help here. Sorry! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56935/new/ https://reviews.llvm.org/D56935 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56935: [NewPM] Add support for new-PM plugins to clang
philip.pfaffe accepted this revision. philip.pfaffe added a comment. This revision is now accepted and ready to land. It would be good to check, since the bots won't! Otherwise this looks good. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56935/new/ https://reviews.llvm.org/D56935 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D61664: [NewPM] Setup Passes for KASan and KMSan
philip.pfaffe accepted this revision. philip.pfaffe added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61664/new/ https://reviews.llvm.org/D61664 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52814: [PassManager/Sanitizer] Enable usage of ported AddressSanitizer passes with -fsanitize=address
philip.pfaffe added a comment. Is this the right place in the pipeline to put the passes? The legacy PM inserts the asan passes at EP_OptimizerLast, why not do the same thing? Repository: rC Clang https://reviews.llvm.org/D52814 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56935: [NewPM] Add support for new-PM plugins to clang
philip.pfaffe added a comment. Landed it for you in r352972. Thanks! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56935/new/ https://reviews.llvm.org/D56935 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D57265: [PM/CC1] Add -f[no-]split-cold-code CC1 options to toggle splitting
philip.pfaffe added a comment. I'd prefer not adding this kind of state to PassBuilder. `SplitColdCode` is soemthing that refers to the construction of //one// particular pipeline, not to pipeline-building in general. It should be an argument passed down through the build*Pipeline calls. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57265/new/ https://reviews.llvm.org/D57265 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool
philip.pfaffe added a subscriber: beanz. philip.pfaffe added a comment. I fear you'll need to plan at least for new pm right now. Otherwise your change will be obsolete in half a year. What is it really that LINK_X_INTO_TOOLS is supposed to do? Effectively bake in something that's consumable by -load or -load-plugin, right? So can we use that interface directly? Effectively, can we have statically built-in plugins, that prepopulate the plug-in loader mechanisms? If the patch becomes too large then it should be split into separate functional units, e.g., one adding the cmake functionality, one updating the plugins and the tools. You could also ask @beanz for a review of the cmake change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61446/new/ https://reviews.llvm.org/D61446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D61709: [NewPM] Port HWASan and Kernel HWASan
philip.pfaffe accepted this revision. philip.pfaffe added a comment. This revision is now accepted and ready to land. Nit aside, looks good! Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:179 - bool runOnFunction(Function &F) override; - bool doInitialization(Module &M) override; + bool instrumentFunction(Function &F); + void initializeWithModule(Module &M); There are some naming clashes here. In the other sanitizers these functions are called `sanitizeFunction` and `initializeModule`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61709/new/ https://reviews.llvm.org/D61709 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D49486: [cfe][CMake] Export the clang resource directory
philip.pfaffe created this revision.
philip.pfaffe added reviewers: mgorny, beanz, gottesmm.
Herald added a subscriber: bollu.
Out-of-tree tools trying to parse source files need the builtin headers
such as `stddef.h`. If the tool isn't installed together with clang, it
can't find them automatically. Exporting the location makes this much
easier.
(Resubmitting because I've subscribed the wrong list, sorry for the noise).
https://reviews.llvm.org/D49486
Files:
clang/cmake/modules/CMakeLists.txt
clang/cmake/modules/ClangConfig.cmake.in
Index: clang/cmake/modules/ClangConfig.cmake.in
===
--- clang/cmake/modules/ClangConfig.cmake.in
+++ clang/cmake/modules/ClangConfig.cmake.in
@@ -8,6 +8,7 @@
set(CLANG_EXPORTED_TARGETS "@CLANG_EXPORTS@")
set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@")
set(CLANG_INCLUDE_DIRS "@CLANG_CONFIG_INCLUDE_DIRS@")
+set(CLANG_RESOURCE_DIR "@CLANG_CONFIG_RESOURCE_DIR@")
# Provide all our library targets to users.
include("@CLANG_CONFIG_EXPORTS_FILE@")
Index: clang/cmake/modules/CMakeLists.txt
===
--- clang/cmake/modules/CMakeLists.txt
+++ clang/cmake/modules/CMakeLists.txt
@@ -19,6 +19,13 @@
"${CLANG_SOURCE_DIR}/include"
"${CLANG_BINARY_DIR}/include"
)
+if (CLANG_RESOURCE_DIR)
+ set(CLANG_CONFIG_RESOURCE_DIR ${CLANG_RESOURCE_DIR})
+else()
+ set(CLANG_CONFIG_RESOURCE_DIR
+${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}/include)
+endif()
+
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
${clang_cmake_builddir}/ClangConfig.cmake
Index: clang/cmake/modules/ClangConfig.cmake.in
===
--- clang/cmake/modules/ClangConfig.cmake.in
+++ clang/cmake/modules/ClangConfig.cmake.in
@@ -8,6 +8,7 @@
set(CLANG_EXPORTED_TARGETS "@CLANG_EXPORTS@")
set(CLANG_CMAKE_DIR "@CLANG_CONFIG_CMAKE_DIR@")
set(CLANG_INCLUDE_DIRS "@CLANG_CONFIG_INCLUDE_DIRS@")
+set(CLANG_RESOURCE_DIR "@CLANG_CONFIG_RESOURCE_DIR@")
# Provide all our library targets to users.
include("@CLANG_CONFIG_EXPORTS_FILE@")
Index: clang/cmake/modules/CMakeLists.txt
===
--- clang/cmake/modules/CMakeLists.txt
+++ clang/cmake/modules/CMakeLists.txt
@@ -19,6 +19,13 @@
"${CLANG_SOURCE_DIR}/include"
"${CLANG_BINARY_DIR}/include"
)
+if (CLANG_RESOURCE_DIR)
+ set(CLANG_CONFIG_RESOURCE_DIR ${CLANG_RESOURCE_DIR})
+else()
+ set(CLANG_CONFIG_RESOURCE_DIR
+${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}/include)
+endif()
+
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
${clang_cmake_builddir}/ClangConfig.cmake
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
