Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Porting to cygwin #1010

wants to merge 633 commits into from


Copy link

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.

@@ -21,7 +21,7 @@

namespace swift {
/// The DWARF version emitted by the Swift compiler.
const unsigned DWARFVersion = 3;
const unsigned DWARFVersion = 4;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this required? /cc @adrian-prantl

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

const unsigned DWARFVersion = 4;
const unsigned DWARFVersion = 3;


2016-01-19 9:10 GMT+09:00 Dmitri Gribenko

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

Reply to this email directly or view it on GitHub

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Let's see what @adrian-prantl says, possibly this change would need to be scoped to Cygwin.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@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");
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

bitjammer and others added 5 commits January 21, 2016 17:05
…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).

t.swift:6:17: error: cannot convert value of type 'Int' to specified type 'Int'
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.

information about where the archetype was defined.  Before:

t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int =


t.swift:6:17: error: generic parameter 'T' could not be inferred
var a : Int =
t.swift:2:8: note: 'T' declared as parameter to type 'A'
struct A<T> {
trentxintong and others added 26 commits January 25, 2016 20:10
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

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.
[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 from nominal type metadata.

    Strip all field metadata for nominal types. This also implies

NFC yet.
This is used to emit relative references to field names for
Copy link
Contributor Author

I recreated same PR on master branch an hour ago. I think this PR must be removed.

Copy link

Closing this PR in favor of #1108.

@gribozavr gribozavr closed this Jan 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet