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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
This kind of simplification is sometimes useful, but in general it's not correct.
As GNU/kFreeBSD is an hybrid system, for kernel-related issues we want to match the
build definitions used for FreeBSD, whereas for userland-related issues we want to
match the definitions used for other systems with Glibc.
The current modification adjusts the build system so that they can be distinguished,
and explicitly adds GNU/kFreeBSD to the build checks in which it belongs.
Fixes bug #16444.
Patch by Robert Millan in the context of Debian.
llvm-svn: 185311
There is some hope of eventually supporting a unified build with it, but
until then this lets me (and others) check it out in this location
without things breaking.
llvm-svn: 184697
