aboutsummaryrefslogtreecommitdiff
path: root/llvm/projects
AgeCommit message (Collapse)AuthorFilesLines
2023-10-02Revert "[Flang] [FlangRT] Introduce FlangRT project as solution to Flang's ↵David Spickett1-3/+0
runtime LLVM integration" This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70. This is failing on all but 1 of Linaro's flang builders. CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message): Target llvm_gtest not found.
2023-09-30[Flang] [FlangRT] Introduce FlangRT project as solution to Flang's runtime ↵Paul Scoropan1-0/+3
LLVM integration See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details. Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md). This patch aims to: - integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime - decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime - add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target. - provide documentation on how to build and use the new FlangRT runtime Reviewed By: DanielCChen Differential Revision: https://reviews.llvm.org/D154869
2021-10-21Remove unused parallel-libs projectDavid Blaikie1-2/+0
Differential Revision: https://reviews.llvm.org/D112265
2021-06-28[RFC][debuginfo-test] Rename debug-info lit tests for general purposesJames Henderson1-2/+2
Discussion thread: https://lists.llvm.org/pipermail/llvm-dev/2021-January/148048.html Move debuginfo-test into a subdirectory of a new top-level directory, called cross-project-tests. The new name replaces "debuginfo-test" as an LLVM project enabled via LLVM_ENABLE_PROJECTS. Differential Revision: https://reviews.llvm.org/D95339 Reviewed by: aprantl
2020-11-13llvmbuildectomy - replace llvm-build by plain cmakeserge-sans-paille1-20/+0
No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2019-10-04Add few docs and implementation of strcpy and strcat.Siva Chandra1-0/+1
Summary: This patch illustrates some of the features like modularity we want in the new libc. Few other ideas like different kinds of testing, redirectors etc are not yet present. Reviewers: dlj, hfinkel, theraven, jfb, alexshap, jdoerfert Subscribers: mgorny, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67867 llvm-svn: 373764
2019-08-05[libc++] Take 2: Integrate the PSTL into libc++Louis Dionne1-1/+1
Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. The first attempt to commit this failed because it exposed a bug in the tests for modules. Now that this has been fixed, it should be safe to commit this. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 367903
2019-07-19Revert "[libc++] Integrate the PSTL into libc++"Louis Dionne1-1/+1
This reverts r366593, which caused unforeseen breakage on the build bots. I'm reverting until the problems have been figured out and fixed. llvm-svn: 366603
2019-07-19[libc++] Integrate the PSTL into libc++Louis Dionne1-1/+1
Summary: This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when configuring libc++ in CMake. When that option is enabled, libc++ will assume that the PSTL can be found somewhere on the CMake module path, and it will provide the C++17 parallel algorithms based on the PSTL (that is assumed to be available). The commit also adds support for running the PSTL tests as part of the libc++ test suite. Reviewers: rodgert, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF Tags: #libc Differential Revision: https://reviews.llvm.org/D60480 llvm-svn: 366593
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-12-21[pstl] Initial integration with LLVM's CMakeLouis Dionne1-0/+1
Summary: This commit adds a check-pstl CMake target that will run the tests we currently have for pstl. Those tests are not using LLVM lit yet, but switching them over should be a transparent change. With this change, we can start relying on the `check-pstl` target for workflows and CI. Note that this commit purposefully does not support the pre-monorepo layout (with subprojects in projects/), since LLVM is moving towards the monorepo layout anyway. Reviewers: jfb Subscribers: mgorny, jkorous, dexonsmith, libcxx-commits, mclow.lists, rodgert Differential Revision: https://reviews.llvm.org/D55963 llvm-svn: 349919
2018-12-04[projects] Use directory name for add_llvm_external_projectsShoaib Meenai1-1/+2
add_llvm_external_projects expects the directory name instead of the full path, otherwise the check for an in-tree subproject will fail and the project won't be configured. llvm-svn: 348217
2018-12-01[projects] Use add_llvm_external_project for implicit projectsShoaib Meenai1-1/+1
This allows disabling implicit projects via the LLVM_TOOL_*_BUILD variables, similar to how implicit tools can be disabled. They'll still be enabled by default, since add_llvm_external_project defaults the LLVM_TOOL_*_BUILD variables to ON for in-tree implciit projects. Differential Revision: https://reviews.llvm.org/D55105 llvm-svn: 348064
2017-12-12[cmake] Support moving debuginfo-tests to llvm/projectsDon Hinton1-1/+6
Differential Revision: https://reviews.llvm.org/D40972 llvm-svn: 320497
2017-11-21Re-revert "Refactor debuginfo-tests."Zachary Turner1-1/+0
This is still breaking greendragon. At this point I give up until someone can fix the greendragon bots, and I will probably abandon this effort in favor of using a private github repository. llvm-svn: 318722
2017-11-20Resubmit "Refactor debuginfo-tests" again.Zachary Turner1-0/+1
This was reverted due to the tests being run twice on some build bots. Each run had a slightly different configuration due to the way in which it was being invoked. This fixes the problem (albeit in a somewhat hacky way). Hopefully in the future we can get rid of the workflow of running debuginfo-tests as part of clang, and then this hack can go away. llvm-svn: 318697
2017-11-17Re-revert "Refactor debuginfo-tests"Zachary Turner1-1/+0
This is still broken because it causes certain tests to be run twice with slightly different configurations, which is wrong in some cases. You can observe this by running: ninja -nv check-all | grep debuginfo-tests And seeing that it passes clang/test and clang/test/debuginfo-tests to lit, which causes it to run debuginfo-tests twice. The fix is going to involve either: a) figuring out that we're running in this "deprecated" configuration, and then deleting the clang/test/debuginfo-tests path, which should cause it to behave identically to before, or: b) make lit smart enough that it doesn't descend into a sub-suite if that sub-suite already has a lit.cfg file. llvm-svn: 318486
2017-11-16Resubmit "Refactor debuginfo-tests"Zachary Turner1-0/+1
This was reverted due to some failures on specific darwin buildbots, the issue being that the new lit configuration was not setting the SDKROOT environment variable. We've tested a fix locally and confirmed that it works, so this patch resubmits everything with the fix applied. llvm-svn: 318435
2017-11-13Revert "Update test_debuginfo.pl script to point to new tree location."Zachary Turner1-1/+0
This reverts the aforementioned patch and 2 subsequent follow-ups, as some buildbots are still failing 2 tests because of it. Investigation is ongoing into the cause of the failures. llvm-svn: 318112
2017-11-10[debuginfo-tests] Make debuginfo-tests work in a standard configuration.Zachary Turner1-0/+1
Previously, debuginfo-tests was expected to be checked out into clang/test and then the tests would automatically run as part of check-clang. This is not a standard workflow for handling external projects, and it brings with it some serious drawbacks such as the inability to depend on things other than clang, which we will need going forward. The goal of this patch is to migrate towards a more standard workflow. To ease the transition for build bot maintainers, this patch tries not to break the existing workflow, but instead simply deprecate it to give maintainers a chance to update the build infrastructure. Differential Revision: https://reviews.llvm.org/D39605 llvm-svn: 317925
2017-05-11Add temporary workaround to allow in-tree libc++ builds on WindowsEric Fiselier1-1/+3
llvm-svn: 302753
2017-03-07[cmake] Include openmp with add_llvm_external_projectPirama Arumuga Nainar1-1/+3
Summary: Include projects/openmp into the build using add_llvm_external_project instead of add_subdirectory. This creates an option LLVM_TOOL_OPENMP_BUILD that selects whether this project gets included in an in-tree build. Reviewers: beanz, AndreyChurbanov, jlpeyton Subscribers: srhines, openmp-commits, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30470 llvm-svn: 297185
2016-10-09[CMake] Correct configuration order of the sub-projects based on ther ↵Eric Fiselier1-3/+3
dependancies llvm-svn: 283698
2016-09-09Enable in-tree builds of parallel-libs.Justin Lebar1-1/+3
Summary: parallel-libs needs its own changes to make this work; these are just the LLVM changes. Reviewers: jhen Subscribers: llvm-commits, beanz, jprice Differential Revision: https://reviews.llvm.org/D24402 llvm-svn: 281097
2016-01-26Remove autoconf supportChris Bieneman1-26/+0
Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
2015-10-28[CMake] Disable adding the test suite as a projects subdirectoryChris Bieneman1-1/+2
This will never work as an add_subdirectory call, so we should just make sure it doesn't happen. To do this properly we'll need to add it under clang similar to the external compiler-rt. llvm-svn: 251543
2015-04-25build: make libunwind a proper projectSaleem Abdulrasool1-1/+3
This allows the build infrastructure to properly detect and build libunwind. llvm-svn: 235796
2015-03-04Reverse the order libc++ and libc++abi are added in CMake.Eric Fiselier1-1/+3
llvm-svn: 231190
2014-07-25[cmake] Use the external project machinery for libcxxabi so that it canChandler Carruth1-1/+3
be disabled in CMake or relocated if desired. llvm-svn: 213936
2014-03-12Remove projects/sample.Rafael Espindola42-27387/+0
As an example that was not actually being used, it suffered from a slow bitrot. The two main issues with it were that it had no cmake support and included a copy of the autoconf directory. The reality is that autoconf is not easily composable. The lack of composabilty is why we have clang options in llvm's configure. Suggesting that users include a copy of autoconf/ in their projects seems a bad idea. We are also in the process of switching to cmake, so pushing autoconf to new project is probably not what we want. llvm-svn: 203728
2014-03-07"Mac OS/X" -> "Mac OS X" spelling fixes for llvm.Nico Weber1-2/+2
Patch from Sean McBride <sean@rogue-research.com>! llvm-svn: 203258
2014-02-28Drop libtool from llvm.Rafael Espindola5-17697/+1
We were only using it so find the shared library extension and nm. There are simpler ways to do those things :-) llvm-svn: 202524
2014-02-28With rpaths being set correctly, SHLIBPATH_VAR is not needed anymore.Rafael Espindola3-14/+2
llvm-svn: 202510
2014-02-27[CMake] Introduce LLVM_BUILD_EXTERNAL_COMPILER_RT optionAlexey Samsonov1-1/+3
llvm-svn: 202363
2014-02-16Remove dead code, we already require cmake 2.8.8.Rafael Espindola1-5/+1
llvm-svn: 201495
2014-01-24llvm/projects/CMakeLists.txt: Add dragonegg.NAKAMURA Takumi1-0/+3
llvm-svn: 199995
2013-10-07Revert "Revert "Windows: Add support for unicode command lines""David Majnemer2-0/+82
This reverts commit r192070 which reverted r192069, I forgot to regenerate the configure scripts. llvm-svn: 192079
2013-10-06Revert "Windows: Add support for unicode command lines"David Majnemer1-1/+0
This is causing MinGW bots to fail. This reverts commit r192069. llvm-svn: 192070
2013-10-06Windows: Add support for unicode command linesDavid Majnemer1-0/+1
Summary: The MSVCRT deliberately sends main() code-page specific characters. This isn't too useful to LLVM as we end up converting the arguments to UTF-16 and subsequently attempt to use the result as, for example, a file name. Instead, we need to have the ability to access the Unicode command line and transform it to UTF-8. This has the distinct advantage over using the MSVC-specific wmain() function as our entry point because: - It doesn't work on cygwin. - It only work on MinGW with caveats and only then on certain versions. - We get to keep our entry point as main(). :) N.B. This patch includes fixes to other parts of lib/Support/Windows s.t. we would be able to take advantage of getting the Unicode paths. E.G. clang spawning clang -cc1 would want to give it Unicode arguments. Reviewers: aaron.ballman, Bigcheese, rnk, ruiu Reviewed By: rnk CC: llvm-commits, ygao Differential Revision: http://llvm-reviews.chandlerc.com/D1834 llvm-svn: 192069
2013-10-02Disable libc++ building by default with CMake with MSVC -- some botsChandler Carruth1-1/+5
aren't yet happy with this config. llvm-svn: 191811
2013-09-28Enable libcxx as part of the top level CMake build when it is checkedChandler Carruth1-2/+3
out in projects. This appears to be working on my system, and I will be watching build bots to see if there are any issues on other platforms. llvm-svn: 191624
2013-08-18Port the detection of zlib from the main autoconf system to the sampleChandler Carruth2-2/+327
project's autoconf. This is the last of the missing optional checks used by libSupport that seemed to be missing from the sample project, but I could easily have missed some as this was done by inspection when Craig asked me to add the terminfo support. llvm-svn: 188618
2013-08-18Add support for linking librt and using clock_gettime to the sampleChandler Carruth2-0/+105
autoconf setup. llvm-svn: 188617
2013-08-18Update the sample project autoconf setup to include support forChandler Carruth2-1/+142
detecting terminfo. Requested by Craig Topper, and probably should be done much more systematically. llvm-svn: 188616
2013-08-04Build with the $RDYNAMIC flag on Darwin as well as other platforms.Bob Wilson1-8/+5
Part of <rdar://problem/14620988> llvm-svn: 187710
2013-08-02Regenerate with changes for -rdynamic.Bob Wilson1-4/+4
llvm-svn: 187687
2013-08-02Link with -rdynamic instead of -Wl,-export-dynamic.Bob Wilson2-6/+7
Recent versions of the OS X linker support this but follow the existing OS X linker convention of using an underscore in the option name, i.e., -export_dynamic. Rather than changing our configure scripts to check for that alternate spelling, it is simpler to just use the compiler's -rdynamic option and let it deal with translating that to the appropriate linker option. One potential disadvantage of this approach is that the compiler will typically ignore -rdynamic on platforms where it is not supported, so the HAVE_LINK_EXPORT_DYNAMIC in config.h will not necessarily show whether that option has any effect or not. I don't see any in-tree uses of that macro, so I'm assuming it is OK. llvm-svn: 187686
2013-07-26[PowerPC] Support powerpc64le as a syntax-checking target.Bill Schmidt2-1/+4
This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-25Remove dead code from the makefile build system.Rafael Espindola1-246/+1
Back in r140220 we removed the autoconf code that would set LLVMCC_OPTION since it was only used by the test-suite. This patch now removes code that would only be used if LLVMCC_OPTION was set. llvm-svn: 187154
2013-07-25Remove the mblaze backend from llvm.Rafael Espindola2-12/+3
Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html llvm-svn: 187145
generated by cgit v1.1 at 2024-08-16 22:59:39 +0000