Porting to cygwin #1010
Closed
Porting to cygwin #1010
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -21,7 +21,7 @@ | |||
|
|
|||
| namespace swift { | |||
| /// The DWARF version emitted by the Swift compiler. | |||
| const unsigned DWARFVersion = 3; | |||
| const unsigned DWARFVersion = 4; | |||
There was a problem hiding this comment.
Why was this required? /cc @adrian-prantl
There was a problem hiding this comment.
My dev environment was cygwin 64bit 2.3.1, and clang version was 3.5.2.
The dwarf version 4 is used as default and the linker displayed errors when
compiled with dwarf version 3.
$ clang++ hello.cpp -gdwarf-3
/tmp/hello-c8fc34.o:(.debug_info+0x16): relocation truncated to fit:
R_X86_64_32 against `.debug_line'
collect2: error: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to
see invocation)
So swiftc -c -g must generate in dwarf ver 4.
Is this should be changed to like this?
#if CYGWIN
const unsigned DWARFVersion = 4;
#else
const unsigned DWARFVersion = 3;
#fi
2016-01-19 9:10 GMT+09:00 Dmitri Gribenko notifications@github.com:
In include/swift/Basic/Dwarf.h
#1010 (comment):@@ -21,7 +21,7 @@
namespace swift {
/// The DWARF version emitted by the Swift compiler.
- const unsigned DWARFVersion = 3;
- const unsigned DWARFVersion = 4;
Why was this required? /cc @adrian-prantl
https://github.com/adrian-prantl—
Reply to this email directly or view it on GitHub
https://github.com/apple/swift/pull/1010/files#r50059136.
There was a problem hiding this comment.
I see. Let's see what @adrian-prantl says, possibly this change would need to be scoped to Cygwin.
There was a problem hiding this comment.
Upgrading the emitted DWARF version has to be done very carefully, because there are many different DWARF consumers besides the debugger that all need to be tested for compatibility and upgraded. There is work underway to move the Darwin default for both clang and swiftc to DWARF 4, but the qualification process is not yet complete.
The best solution is to implement -gdwarf-3 / -gdwarf-4 / -gdwarf-5 driver options that translate to -dwarf-version= frontend options analogous to the clang driver and make the default depend on the target platform.
|
@tinysun212 Thank you for your work! I have left a few comments, unfortunately some of issues are showstoppers. I would be happy to discuss possible solutions. |
| << "; Invalidated: " | ||
| << (AggBuilderMap.isInvalidated(_N)? "yes" : "no") << "\n"); | ||
| << (AggBuilderMap.isInvalidated(_work)? "yes" : "no") << "\n"); |
There was a problem hiding this comment.
You can submit this part as a separate pull request if you like, I'll merge it immediately. Not using reserved names is obvious goodness.
…ter-synthesized properties on enums. If you extend a C/ObjC enum type to conform to ErrorType, then the synthesized _code getter ends up registered as an external decl, but appears to already get synthesized due to @slavapestov's changes. I'm not sure whether this is reliable enough that we can simply stop registering the external decls, so just to keep the build from crashing, insert a check in emitExternalDecls that we didn't already emit the decl and skip emission. Low-risk workaround for rdar://problem/24287125.
…e 'Int' to specified type 'Int' When a contextual conversion has a matching type, don't diagnose it as a conversion error, the problem is due to something else (in this case, an unresolved archetype somewhere else in the expression). Before: t.swift:6:17: error: cannot convert value of type 'Int' to specified type 'Int' After: t.swift:6:17: error: generic parameter 'T' could not be inferred This should still be a bit better to provide information about where the T archetype came from, but at least now it isn't completely wrong diagnostic.
…icate
information about where the archetype was defined. Before:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
After:
t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int = A.foo()
^
t.swift:2:8: note: 'T' declared as parameter to type 'A'
struct A<T> {
^
[gardening] Fix recently introduced typos
to the new projection path. We do not need to trace from the accessed field to the base object when we've done it before in enumerateLSLOcations Stdlib -O === Before === Running Time Self (ms) Symbol Name 25137.0ms 37.3% 0.0 swift::runSILOptimizationPasses(swift::SILModule&) 24939.0ms 37.0% 0.0 swift::SILPassManager::runOneIteration() 20226.0ms 30.0% 29.0 swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) 19241.0ms 28.5% 83.0 swift::SILPassManager::runPassesOnFunction(llvm::ArrayRef<swift::SILFunctionTransform*>, swift::SILFunction*) 3214.0ms 4.7% 10.0 (anonymous namespace)::SimplifyCFGPass::run() 3005.0ms 4.4% 14.0 (anonymous namespace)::ARCSequenceOpts::run() 2438.0ms 3.6% 7.0 (anonymous namespace)::SILCombine::run() 2217.0ms 3.2% 54.0 (anonymous namespace)::RedundantLoadElimination::run() 2212.0ms 3.2% 131.0 (anonymous namespace)::SILCSE::run() 1195.0ms 1.7% 11.0 (anonymous namespace)::GenericSpecializer::run() 1168.0ms 1.7% 39.0 (anonymous namespace)::DeadStoreElimination::run() 853.0ms 1.2% 150.0 (anonymous namespace)::DCE::run() 499.0ms 0.7% 7.0 (anonymous namespace)::SILCodeMotion::run() === After === Running Time Self (ms) Symbol Name 22955.0ms 38.2% 0.0 swift::runSILOptimizationPasses(swift::SILModule&) 22777.0ms 37.9% 0.0 swift::SILPassManager::runOneIteration() 18447.0ms 30.7% 30.0 swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) 17510.0ms 29.1% 67.0 swift::SILPassManager::runPassesOnFunction(llvm::ArrayRef<swift::SILFunctionTransform*>, swift::SILFunction*) 2944.0ms 4.9% 5.0 (anonymous namespace)::SimplifyCFGPass::run() 2884.0ms 4.8% 12.0 (anonymous namespace)::ARCSequenceOpts::run() 2277.0ms 3.7% 1.0 (anonymous namespace)::SILCombine::run() 1951.0ms 3.2% 117.0 (anonymous namespace)::SILCSE::run() 1803.0ms 3.0% 54.0 (anonymous namespace)::RedundantLoadElimination::run() 1096.0ms 1.8% 10.0 (anonymous namespace)::GenericSpecializer::run() 911.0ms 1.5% 53.0 (anonymous namespace)::DeadStoreElimination::run() 795.0ms 1.3% 135.0 (anonymous namespace)::DCE::run() 453.0ms 0.7% 9.0 (anonymous namespace)::SILCodeMotion::run()
…ions that are way too large to process. I do not see compilation time difference in stdlib -O nor any change in # of redundant loads eliminated. I am more looking at compilation time and precision in stdlibunittest. === Before Throttle Logic === compilation time stdlibunit -O: Running Time Self (ms) Symbol Name 27016.0ms 26.4% 0.0 swift::runSILOptimizationPasses(swift::SILModule&) 26885.0ms 26.2% 0.0 swift::SILPassManager::runOneIteration() 22355.0ms 21.8% 15.0 swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) 21416.0ms 20.9% 42.0 swift::SILPassManager::runPassesOnFunction(llvm::ArrayRef<swift::SILFunctionTransform*>, swift::SILFunction*) 5662.0ms 5.5% 10.0 (anonymous namespace)::ARCSequenceOpts::run() 3916.0ms 3.8% 58.0 (anonymous namespace)::RedundantLoadElimination::run() 2707.0ms 2.6% 3.0 (anonymous namespace)::SILCombine::run() 2248.0ms 2.1% 5.0 (anonymous namespace)::SimplifyCFGPass::run() 1974.0ms 1.9% 121.0 (anonymous namespace)::SILCSE::run() 1592.0ms 1.5% 30.0 (anonymous namespace)::DeadStoreElimination::run() 746.0ms 0.7% 170.0 (anonymous namespace)::DCE::run() === After Throttle Logic === compilation time stdlibunit -O: Running Time Self (ms) Symbol Name 25735.0ms 25.4% 0.0 swift::runSILOptimizationPasses(swift::SILModule&) 25611.0ms 25.3% 0.0 swift::SILPassManager::runOneIteration() 21260.0ms 21.0% 21.0 swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) 20340.0ms 20.1% 43.0 swift::SILPassManager::runPassesOnFunction(llvm::ArrayRef<swift::SILFunctionTransform*>, swift::SILFunction*) 5319.0ms 5.2% 8.0 (anonymous namespace)::ARCSequenceOpts::run() 3265.0ms 3.2% 58.0 (anonymous namespace)::RedundantLoadElimination::run() 2661.0ms 2.6% 1.0 (anonymous namespace)::SILCombine::run() 2185.0ms 2.1% 5.0 (anonymous namespace)::SimplifyCFGPass::run() 1847.0ms 1.8% 105.0 (anonymous namespace)::SILCSE::run() 1499.0ms 1.4% 21.0 (anonymous namespace)::DeadStoreElimination::run() 708.0ms 0.7% 150.0 (anonymous namespace)::DCE::run() 498.0ms 0.4% 7.0 (anonymous namespace)::SILCodeMotion::run() 370.0ms 0.3% 0.0 (anonymous namespace)::StackPromotion::run()
… Instead of walking the entire projection path to find the most derived type, we cache it and invalidate when the projectionpath is append'ed to. stdlib -O === Before === Running Time Self (ms) Symbol Name 25741.0ms 37.3% 0.0 swift::runSILOptimizationPasses(swift::SILModule&) 25523.0ms 37.0% 0.0 swift::SILPassManager::runOneIteration() 20654.0ms 29.9% 36.0 swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) 19663.0ms 28.5% 87.0 swift::SILPassManager::runPassesOnFunction(llvm::ArrayRef<swift::SILFunctionTransform*>, swift::SILFunction*) 3279.0ms 4.7% 5.0 (anonymous namespace)::SimplifyCFGPass::run() 3205.0ms 4.6% 11.0 (anonymous namespace)::ARCSequenceOpts::run() 2550.0ms 3.7% 7.0 (anonymous namespace)::SILCombine::run() 2177.0ms 3.1% 42.0 (anonymous namespace)::RedundantLoadElimination::run() 2151.0ms 3.1% 115.0 (anonymous namespace)::SILCSE::run() 1255.0ms 1.8% 18.0 (anonymous namespace)::GenericSpecializer::run() 1080.0ms 1.5% 49.0 (anonymous namespace)::DeadStoreElimination::run() 926.0ms 1.3% 189.0 (anonymous namespace)::DCE::run() 488.0ms 0.7% 3.0 (anonymous namespace)::SILCodeMotion::run() === After === Running Time Self (ms) Symbol Name 24065.0ms 36.8% 0.0 swift::runSILOptimizationPasses(swift::SILModule&) 23865.0ms 36.5% 0.0 swift::SILPassManager::runOneIteration() 19245.0ms 29.4% 42.0 swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) 18273.0ms 27.9% 65.0 swift::SILPassManager::runPassesOnFunction(llvm::ArrayRef<swift::SILFunctionTransform*>, swift::SILFunction*) 3096.0ms 4.7% 10.0 (anonymous namespace)::ARCSequenceOpts::run() 3081.0ms 4.7% 9.0 (anonymous namespace)::SimplifyCFGPass::run() 2381.0ms 3.6% 8.0 (anonymous namespace)::SILCombine::run() 1990.0ms 3.0% 128.0 (anonymous namespace)::SILCSE::run() 1828.0ms 2.8% 65.0 (anonymous namespace)::RedundantLoadElimination::run() 1200.0ms 1.8% 10.0 (anonymous namespace)::GenericSpecializer::run() 918.0ms 1.4% 58.0 (anonymous namespace)::DeadStoreElimination::run() 867.0ms 1.3% 140.0 (anonymous namespace)::DCE::run() 479.0ms 0.7% 11.0 (anonymous namespace)::SILCodeMotion::run() 294.0ms 0.4% 1.0 (anonymous namespace)::ConstantPropagation::run()
enum raw value is parsed as a normal expression using `parseExpr()`. However, for a closure, the parser expects a local context that doesn't exist for raw values. We create a temporary context to ensure the closure gets parsed as normal. As a consequence, `parseExpr()` returns normally for closure and correct diagnosis for raw value gets issued.
… redundant_load_and_dead_store.sil
[SR-510] Diagnose closures used as enum raw values.
…red class var suggests [] instead of [:] a simple apparent typo or thinko
[SR-615][Compiler] Don't error when lexing UTF-8 BOM
…be done without access control now by diagnostics.
Fix small typos in build-script help
This is a preliminary refactoring toward emitting generic metadata instantiation accessors. This will let us stop exporting metadata template symbols and reference accessors from conformance tables instead. The latter is required to enable conformances where the conforming type is resilient.
[gardening] Fix recently introduced typo: "polymorhpic" → "polymorphic"
This controls emission of field metadata for reflection, providing
the default decision. We might want to explore finer-grained
control per type, likely as a source code annotation.
-strip-field-names
Strip field names from nominal type metadata.
-strip-field-metadata
Strip all field metadata for nominal types. This also implies
-strip-field-names.
NFC yet.
This is used to emit relative references to field names for reflection.
tinysun212
force-pushed
the
porting-to-cygwin
branch
from
766c5cd
to
6dfd69f
Compare
|
I recreated same PR on master branch an hour ago. I think this PR must be removed. |
|
Closing this PR in favor of #1108. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I made several changes set for cygwin64 port.
The standard library can be used and It is possible to compile and run or interpret a simple hello swift source, but REPL, swift-build and swift-lldb does not work.
Some of these would bad result in other platforms (ex. OS X, Linux) because I didn't check, but I think it would easily fixed.