This patch adds powerpc64le Linux support. While the patch also adds
the matching powerpc64 bits, there are endian issues that need to be
sorted out.
The PowerPC LLVM changes for the swift ABI (eg returning three element
non-homogeneous aggregates) are still in the works, but a simple LLVM
fix to allow those aggregates results in swift passing all but 8
test cases.
The issue is that this was originally done when in-tree builds were the
preferred way of building so LLVM_ENABLE_DOXYGEN would be defined and LLVM would
have found doxygen as well. When one is doing the current preferred standalone
install, the option LLVM_ENABLE_DOXYGEN is not discoverable to the user via an
option with a default argument and the doxygen package is never searched for.
This commit ensures that when building standalone:
1. LLVM_ENABLE_DOXYGEN is defined as an option with a default value of FALSE.
2. The cmake dtrace package is searched for and found.
When we are building standalone, we take these values from LLVM.
At the time this code was originally written, Swift standard
library hasn't been ported to FreeBSD, so we didn't need any
additional library. This is not true anymore, so fix it.
The `use_internal_sdk` flag has been removed from `_add_variant_link_flags` and
`_add_variant_c_compile_flags` in commit
d9bbb6caf0
In four instances where previously FALSE was given as the value for that
parameter, this value has not been removed from the call.
This causes the two functions to try to append flags to FALSE instead of the
respective link_flags and c_compile_flags variables.
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
(Also, be careful only to do this for private link libraries that are
actually targets.)
<rdar://problem/23621157>
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
<rdar://problem/23621157>
When we're building the compiler, we already depend on the "swift" target.
When we're /not/ building the compiler, it had better already be there.
Squelches a CMake warning.
This was defaulting to the build directory, which isn't helpful
post-install. Set Swift libraries to look in the same directory
(ORIGIN) or /usr/lib/swift/linux.
rdar://problem/22766758
This skips the Swift standard library due to the linker script incompatibility
issue.
As before for other related projects, the build-script-impl option
'--use-gold-linker' triggers usage of this.
Swift SVN r32706
When building overlay separately, look for dylibs in the overlay
build directory first, and only then fall back to the compiler resource
directory.
If the overlay changes the ABI, we shouldn't even try the dylibs in the
compiler resource directory, that is certain to fail the build or
result in miscompiles.
rdar://22866170
Swift SVN r32382
A couple of small tweaks to _compiler_version based on review comments:
- Fix &&/|| rejection to work with _compiler_version on either side of the
expression. Also add some test cases around this.
- Use clang/LLVM facilities for isdigit and atoi.
- Assert if parsing an invalid version string and there is no diagnostic
engine.
- Clean up some crumbs in the CMake configs.
rdar://problem/22730282
Swift SVN r32212
This configuration clause will suppress lex diagnostics and skip parsing
altogether if the code under the clause isn't active - the compiler must
have a repository version greater than or equal to the version given to
_compiler_version.
This option is only meant to be used sparingly and not to track the
Swift *language* version.
Example, if using a compiler versioned 700.0.28:
#if _compiler_version("700.0.23")
print("This code will compile for versions 700.0.23 and later.")
#else
This + code + will + not + be + parsed
#endif
Included are new diagnostics for checking that the version is formatted
correctly and isn't empty.
New tests:
- Compiler version comparison unit tests
- Build configuration diagnostics
- Skipping parsing of code under inactive clauses
rdar://problem/22730282
Swift SVN r32195
Refactor configure_sdk_darwin(), remove the "internal" parameter since all calls are the same, make it respect SWIFT_USE_INTERNAL_SDK instead.
Make it use the internal SDK only if cross compiling tools, since it's required.
Swift SVN r31509
This reverts commit r31313.
This change caused an unacceptable dylib size increase:
- watchOS core dylib size increased from 13 Mb to 25 Mb,
- iOS dylib size increased 40 Mb to 76 Mb.
The size change is due to change of the bitcode section size. It can be
attributed to:
- actual symbol strings that we have started to include;
- full debug info. Symbol obfuscation was also changing full debug info
in LLVM metadata into line tables.
rdar://22330874, again.
Swift SVN r31473
We will need this to switch the darwin targets over to use ICU instead of going
to NSString for string operations. The public SDK does not contain the headers
for ICU - only the dylib.
For builds using a public SDK users can specify the path to an ICU install where
the headers can be found. If this path is specified the logic will not use
internal SDK variants.
Swift SVN r31471
This is a negative version of the flag
SWIFT_EXPERIMENTAL_EXTRA_REGEXP_FLAGS. The reason why an additional flag
is needed is that cmake does not support negative regexes in the regex
string itself. Instead you need to do:
if (NOT "..." MATCHES "...")
...
endif()
This suggests that we either needed to introduce more complexity into
SWIFT_EXPERIMENTAL_EXTRA_REGEXP_FLAGS or just introduce another flag. I
decided to go with the later.
Swift SVN r31417
Un-revert the below commits with the following addition:
add declarations for posix_spawn related APIs to SwiftPrivateDarwinExtras.
posix_spawn-related APIs aren't available in the public SDKs, so force past
the availability by creating our own stubs in the internal DarwinExtras
library.
r31244, r31245
CMake: build all platforms except watchOS using the public SDK
Covers rdar://problem/21145996.
A step towards rdar://problem/21099318.
Switch SDK overlays to use the public SDK
I had to cut the dependency on CrashReporterClient.h and reimplement
some of that code inline in the Swift runtime. This shoud be OK (even
though not very clean), since the layout of CrashReporter sections is
ABI.
rdar://21099318
Swift SVN r31252
