date:20170131

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (master) #421

2017-01-31 Thread Michael Ilseman via swift-dev

Same issue, for Doug:

Compile Swift Module 'libc' (2 sources)
Compile Swift Module 'swiftpm_xctest_helper' (1 sources)
Compile Swift Module 'PackageDescription' (6 sources)
Compile Swift Module 'POSIX' (15 sources)
Linking 
/home/buildnode/disk2/workspace/oss-swift-package-linux-ubuntu-16_04/build/buildbot_linux/swiftpm-linux-x86_64/release/swiftpm-xctest-helper
Compile Swift Module 'Basic' (23 sources)
Valid decl has error type!
(func_decl "-(_:_:)"  interface type=' (T, T) -> 
T.Stride' access=public
  (parameter_list
(parameter "lhs" interface type='T')
(parameter "rhs" interface type='T')))
0  swift   0x038a3628
1  swift   0x038a3d66
2  libpthread.so.0 0x7f2ce96863e0
3  libc.so.6   0x7f2ce7fec428 gsignal + 56
4  libc.so.6   0x7f2ce7fee02a abort + 362
5  swift   0x013a689e
6  swift   0x0139bd01


> On Jan 31, 2017, at 3:35 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-16_04 [#421]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_04/421/ 
> 
> Project:  oss-swift-package-linux-ubuntu-16_04
> Date of build:Tue, 31 Jan 2017 14:42:37 -0800
> Build duration:   52 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit 3954190b5fe02bcaeccaf85bc1bde15b68ab0f8d by daniel_dunbar:
> Fix 80-col viola.
> 
> edit: lib/BuildSystem/LaneBasedExecutionQueue.cpp
> 
> Commit 45510967ce8da80358f980ac62a923ff85c920fd by jordan_rose:
> [test] Disable broken-modules test while we figure out what broke.
> 
> edit: test/ClangImporter/MixedSource/broken-modules.swift
> 
> Commit a3919f535296e1ac6959a6ba2906ebef8565f1a2 by kyrtzidis:
> [index] Add testing for indexing a system overlay module, along with
> 
> add: test/Index/index_system_module.swift
> edit: lib/Index/Index.cpp
> add: test/Index/Inputs/my_system_overlay/my_system_overlay_header.h
> add: test/Index/Inputs/my_system_overlay/my_system_overlay.swift
> add: test/Index/Inputs/my_system_overlay/module.modulemap
> 
> Commit 602235ed52ae5f7e5777c4b87f7b590d7fdbb7dc by github:
> [RangeInfo] Report the case when a continue/break statement is in the
> 
> edit: include/swift/IDE/Utils.h
> edit: test/IDE/range_info_basics.swift
> edit: lib/IDE/SwiftSourceDocInfo.cpp
> 
> Commit 07ddf07f3bb4464af6141d5b5f138cd726075189 by doug_coleman:
> utils/update-checkout: Do any ``git checkout`` before the ``git fetch``.
> 
> edit: utils/update-checkout
> 
> Commit 8159c84bc9a1295b8d0875aab6f1ce7e10c2fa64 by jgroff:
> Sema: "super" calls to non-ObjC extension methods must be statically
> 
> edit: lib/SILGen/SILGenApply.cpp
> edit: test/Inputs/clang-importer-sdk/swift-modules/Foundation.swift
> add: test/SILGen/super-to-nonobjc-extension.swift
> 
> Commit eed34d15e7eb3b17d04ecb74b9b757a7170b5a8f by github:
> Sema: Explicitly allow Optional-to-IUO when converting functions.
> 
> edit: lib/Sema/CSSimplify.cpp
> edit: test/SILGen/implicitly_unwrapped_optional.swift
> edit: test/Constraints/closures.swift
> 
> Commit 7fefca8d144abc07d8447c837e8e681e53758a01 by enderby:
> Fix a bug in llvm-obdump(1) with the -macho flag disassembling an object
> 
> edit: tools/llvm-objdump/MachODump.cpp
> add: test/tools/llvm-objdump/X86/macho-stub-nosyms-disassembly.test
> add: test/tools/llvm-objdump/X86/Inputs/stub-nosyms.macho-x86_64
> 
> Commit 9a46240f5db9d0b59de7ecdf907034ff88a89c1b by ahatanaka:
> [Sema] Transform a templated name before looking it up in
> 
> edit: lib/Sema/SemaTemplateInstantiateDecl.cpp
> edit: test/SemaCXX/destructor.cpp
> edit: lib/Sema/TreeTransform.h

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Bob Wilson via swift-dev

 use gated merges from LLVM swift-*-branch to stable

> On Jan 31, 2017, at 1:20 PM, Frédéric Riss  wrote:
> 
> 
>> On Jan 31, 2017, at 1:17 PM, Michael Ilseman > > wrote:
>> 
>> Thanks, could you file a radar with the details?
> 
> I’m pretty sure there’s already one lying around. +Michael G, +Bob with whom 
> this was discussed in the past (this is about gating merges 
> swift-x.x-branch->stable on some kind of automatic PR testing).
> 
> Fred
> 
>> 
>> 
>>> On Jan 31, 2017, at 12:54 PM, Frédéric Riss >> > wrote:
>>> 
>>> 
 On Jan 31, 2017, at 12:03 PM, Michael Ilseman >>> > wrote:
 
 Fred, do you know why this wasn’t caught by PR testing?
>>> 
>>> This commit went to the clang stable branch. There’s no PR testing there. 
>>> I’ve been sloppy, the change was so simple that I decided no to test it. Of 
>>> course I typoed.
>>> 
>>> The plan was to get merges from swift-x.x-branch -> stable merges on some 
>>> kind of automates PR testing. This would have prevented my sloppiness from 
>>> breaking Swift. This really needs to be implemented.
>>> 
>>> Fred  
>>> 
 
> On Jan 31, 2017, at 11:16 AM, Michael Ilseman  > wrote:
> 
> Thank you!
> 
>> On Jan 31, 2017, at 11:15 AM, Frédéric Riss > > wrote:
>> 
>> Yes, I already pushed a fix. Sorry about that.
>> 
>> Fred
>>  
>>> On Jan 31, 2017, at 11:13 AM, Michael Ilseman >> > wrote:
>>> 
>>> Fred, probably you?
>>> 
>>> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>>>   Syntax error in cmake code at
>>> 
>>> 
>>> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
>>> 
>>>   when parsing string
>>> 
>>> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
>>> 
>>>   There is an unterminated variable reference.
>>> 
>>> 
>>> -- Configuring incomplete, errors occurred!
>>> See also 
>>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
>>> See also 
>>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
>>> FAILED: build.ninja 
>>> /Applications/CMake.app/Contents/bin/cmake 
>>> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm
>>>  
>>> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>>>  <>
>>> 
>>> 
>>> 
 On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
  wrote:
 
 [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
 
 Build URL: 
 https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
 
 Project:   oss-lldb-swift-3.1-incremental-osx
 Date of build: Tue, 31 Jan 2017 10:50:27 -0800
 Build duration:26 sec
 Identified problems:
 
 Compile Error: This build failed because of a compile error. Below is 
 a list of all errors in the build log:
 Indication 1 
 
 Changes
 
 Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
 [CMake] Fixing variable names that were mistyped
 
 edit: tools/driver/CMakeLists.txt
 
 Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
 Add the patch version to the embedded Info.plist.
 
 edit: tools/driver/CMakeLists.txt
>>> 
>> 
> 
 
>>> 
>> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Frédéric Riss via swift-dev


> On Jan 31, 2017, at 1:17 PM, Michael Ilseman  wrote:
> 
> Thanks, could you file a radar with the details?

I’m pretty sure there’s already one lying around. +Michael G, +Bob with whom 
this was discussed in the past (this is about gating merges 
swift-x.x-branch->stable on some kind of automatic PR testing).

Fred

> 
> 
>> On Jan 31, 2017, at 12:54 PM, Frédéric Riss > > wrote:
>> 
>> 
>>> On Jan 31, 2017, at 12:03 PM, Michael Ilseman >> > wrote:
>>> 
>>> Fred, do you know why this wasn’t caught by PR testing?
>> 
>> This commit went to the clang stable branch. There’s no PR testing there. 
>> I’ve been sloppy, the change was so simple that I decided no to test it. Of 
>> course I typoed.
>> 
>> The plan was to get merges from swift-x.x-branch -> stable merges on some 
>> kind of automates PR testing. This would have prevented my sloppiness from 
>> breaking Swift. This really needs to be implemented.
>> 
>> Fred  
>> 
>>> 
 On Jan 31, 2017, at 11:16 AM, Michael Ilseman >>> > wrote:
 
 Thank you!
 
> On Jan 31, 2017, at 11:15 AM, Frédéric Riss  > wrote:
> 
> Yes, I already pushed a fix. Sorry about that.
> 
> Fred
>  
>> On Jan 31, 2017, at 11:13 AM, Michael Ilseman > > wrote:
>> 
>> Fred, probably you?
>> 
>> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>>   Syntax error in cmake code at
>> 
>> 
>> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
>> 
>>   when parsing string
>> 
>> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
>> 
>>   There is an unterminated variable reference.
>> 
>> 
>> -- Configuring incomplete, errors occurred!
>> See also 
>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
>> See also 
>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
>> FAILED: build.ninja 
>> /Applications/CMake.app/Contents/bin/cmake 
>> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm
>>  
>> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>>  <>
>> 
>> 
>> 
>>> On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
>>>  wrote:
>>> 
>>> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
>>> 
>>> Project:oss-lldb-swift-3.1-incremental-osx
>>> Date of build:  Tue, 31 Jan 2017 10:50:27 -0800
>>> Build duration: 26 sec
>>> Identified problems:
>>> 
>>> Compile Error: This build failed because of a compile error. Below is a 
>>> list of all errors in the build log:
>>> Indication 1 
>>> 
>>> Changes
>>> 
>>> Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
>>> [CMake] Fixing variable names that were mistyped
>>> 
>>> edit: tools/driver/CMakeLists.txt
>>> 
>>> Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
>>> Add the patch version to the embedded Info.plist.
>>> 
>>> edit: tools/driver/CMakeLists.txt
>> 
> 
 
>>> 
>> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Michael Ilseman via swift-dev

Thanks, could you file a radar with the details?


> On Jan 31, 2017, at 12:54 PM, Frédéric Riss  wrote:
> 
> 
>> On Jan 31, 2017, at 12:03 PM, Michael Ilseman > > wrote:
>> 
>> Fred, do you know why this wasn’t caught by PR testing?
> 
> This commit went to the clang stable branch. There’s no PR testing there. 
> I’ve been sloppy, the change was so simple that I decided no to test it. Of 
> course I typoed.
> 
> The plan was to get merges from swift-x.x-branch -> stable merges on some 
> kind of automates PR testing. This would have prevented my sloppiness from 
> breaking Swift. This really needs to be implemented.
> 
> Fred  
> 
>> 
>>> On Jan 31, 2017, at 11:16 AM, Michael Ilseman >> > wrote:
>>> 
>>> Thank you!
>>> 
 On Jan 31, 2017, at 11:15 AM, Frédéric Riss >>> > wrote:
 
 Yes, I already pushed a fix. Sorry about that.
 
 Fred
  
> On Jan 31, 2017, at 11:13 AM, Michael Ilseman  > wrote:
> 
> Fred, probably you?
> 
> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>   Syntax error in cmake code at
> 
> 
> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
> 
>   when parsing string
> 
> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
> 
>   There is an unterminated variable reference.
> 
> 
> -- Configuring incomplete, errors occurred!
> See also 
> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
> See also 
> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
> FAILED: build.ninja 
> /Applications/CMake.app/Contents/bin/cmake 
> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm
>  
> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>  <>
> 
> 
> 
>> On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
>>  wrote:
>> 
>> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
>> 
>> Project: oss-lldb-swift-3.1-incremental-osx
>> Date of build:   Tue, 31 Jan 2017 10:50:27 -0800
>> Build duration:  26 sec
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a 
>> list of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
>> [CMake] Fixing variable names that were mistyped
>> 
>> edit: tools/driver/CMakeLists.txt
>> 
>> Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
>> Add the patch version to the embedded Info.plist.
>> 
>> edit: tools/driver/CMakeLists.txt
> 
 
>>> 
>> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Frédéric Riss via swift-dev


> On Jan 31, 2017, at 12:03 PM, Michael Ilseman  wrote:
> 
> Fred, do you know why this wasn’t caught by PR testing?

This commit went to the clang stable branch. There’s no PR testing there. I’ve 
been sloppy, the change was so simple that I decided no to test it. Of course I 
typoed.

The plan was to get merges from swift-x.x-branch -> stable merges on some kind 
of automates PR testing. This would have prevented my sloppiness from breaking 
Swift. This really needs to be implemented.

Fred  

> 
>> On Jan 31, 2017, at 11:16 AM, Michael Ilseman > > wrote:
>> 
>> Thank you!
>> 
>>> On Jan 31, 2017, at 11:15 AM, Frédéric Riss >> > wrote:
>>> 
>>> Yes, I already pushed a fix. Sorry about that.
>>> 
>>> Fred
>>>  
 On Jan 31, 2017, at 11:13 AM, Michael Ilseman >>> > wrote:
 
 Fred, probably you?
 
 CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
   Syntax error in cmake code at
 
 
 /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
 
   when parsing string
 
 ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
 
   There is an unterminated variable reference.
 
 
 -- Configuring incomplete, errors occurred!
 See also 
 "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
 See also 
 "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
 FAILED: build.ninja 
 /Applications/CMake.app/Contents/bin/cmake 
 -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm
  
 -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
  <>
 
 
 
> On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
>  wrote:
> 
> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
> 
> Build URL:
> https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
> 
> Project:  oss-lldb-swift-3.1-incremental-osx
> Date of build:Tue, 31 Jan 2017 10:50:27 -0800
> Build duration:   26 sec
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a 
> list of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
> [CMake] Fixing variable names that were mistyped
> 
> edit: tools/driver/CMakeLists.txt
> 
> Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
> Add the patch version to the embedded Info.plist.
> 
> edit: tools/driver/CMakeLists.txt
 
>>> 
>> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Michael Ilseman via swift-dev

Fred, do you know why this wasn’t caught by PR testing?

> On Jan 31, 2017, at 11:16 AM, Michael Ilseman  wrote:
> 
> Thank you!
> 
>> On Jan 31, 2017, at 11:15 AM, Frédéric Riss > > wrote:
>> 
>> Yes, I already pushed a fix. Sorry about that.
>> 
>> Fred
>>  
>>> On Jan 31, 2017, at 11:13 AM, Michael Ilseman >> > wrote:
>>> 
>>> Fred, probably you?
>>> 
>>> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>>>   Syntax error in cmake code at
>>> 
>>> 
>>> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
>>> 
>>>   when parsing string
>>> 
>>> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
>>> 
>>>   There is an unterminated variable reference.
>>> 
>>> 
>>> -- Configuring incomplete, errors occurred!
>>> See also 
>>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
>>> See also 
>>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
>>> FAILED: build.ninja 
>>> /Applications/CMake.app/Contents/bin/cmake 
>>> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm
>>>  
>>> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>>>  <>
>>> 
>>> 
>>> 
 On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
  wrote:
 
 [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
 
 Build URL: 
 https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
 
 Project:   oss-lldb-swift-3.1-incremental-osx
 Date of build: Tue, 31 Jan 2017 10:50:27 -0800
 Build duration:26 sec
 Identified problems:
 
 Compile Error: This build failed because of a compile error. Below is a 
 list of all errors in the build log:
 Indication 1 
 
 Changes
 
 Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
 [CMake] Fixing variable names that were mistyped
 
 edit: tools/driver/CMakeLists.txt
 
 Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
 Add the patch version to the embedded Info.plist.
 
 edit: tools/driver/CMakeLists.txt
>>> 
>> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Frédéric Riss via swift-dev

Yes, I already pushed a fix. Sorry about that.

Fred
 
> On Jan 31, 2017, at 11:13 AM, Michael Ilseman  wrote:
> 
> Fred, probably you?
> 
> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>   Syntax error in cmake code at
> 
> 
> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
> 
>   when parsing string
> 
> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
> 
>   There is an unterminated variable reference.
> 
> 
> -- Configuring incomplete, errors occurred!
> See also 
> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
> See also 
> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
> FAILED: build.ninja 
> /Applications/CMake.app/Contents/bin/cmake 
> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm 
> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>  <>
> 
> 
> 
>> On Jan 31, 2017, at 10:50 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
>> 
>> Project: oss-lldb-swift-3.1-incremental-osx
>> Date of build:   Tue, 31 Jan 2017 10:50:27 -0800
>> Build duration:  26 sec
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
>> [CMake] Fixing variable names that were mistyped
>> 
>> edit: tools/driver/CMakeLists.txt
>> 
>> Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
>> Add the patch version to the embedded Info.plist.
>> 
>> edit: tools/driver/CMakeLists.txt
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Michael Ilseman via swift-dev

Thank you!

> On Jan 31, 2017, at 11:15 AM, Frédéric Riss  wrote:
> 
> Yes, I already pushed a fix. Sorry about that.
> 
> Fred
>  
>> On Jan 31, 2017, at 11:13 AM, Michael Ilseman > > wrote:
>> 
>> Fred, probably you?
>> 
>> CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
>>   Syntax error in cmake code at
>> 
>> 
>> /Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79
>> 
>>   when parsing string
>> 
>> ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH
>> 
>>   There is an unterminated variable reference.
>> 
>> 
>> -- Configuring incomplete, errors occurred!
>> See also 
>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
>> See also 
>> "/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
>> FAILED: build.ninja 
>> /Applications/CMake.app/Contents/bin/cmake 
>> -H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm 
>> -B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
>>  <>
>> 
>> 
>> 
>>> On Jan 31, 2017, at 10:50 AM, no-re...@swift.org 
>>>  wrote:
>>> 
>>> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
>>> 
>>> Build URL:  
>>> https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
>>> 
>>> Project:oss-lldb-swift-3.1-incremental-osx
>>> Date of build:  Tue, 31 Jan 2017 10:50:27 -0800
>>> Build duration: 26 sec
>>> Identified problems:
>>> 
>>> Compile Error: This build failed because of a compile error. Below is a 
>>> list of all errors in the build log:
>>> Indication 1 
>>> 
>>> Changes
>>> 
>>> Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
>>> [CMake] Fixing variable names that were mistyped
>>> 
>>> edit: tools/driver/CMakeLists.txt
>>> 
>>> Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
>>> Add the patch version to the embedded Info.plist.
>>> 
>>> edit: tools/driver/CMakeLists.txt
>> 
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

2017-01-31 Thread Michael Ilseman via swift-dev

Fred, probably you?

CMake Error at tools/clang/tools/driver/CMakeLists.txt:79 (set):
  Syntax error in cmake code at


/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm/tools/clang/tools/driver/CMakeLists.txt:79

  when parsing string

${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH

  There is an unterminated variable reference.


-- Configuring incomplete, errors occurred!
See also 
"/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeOutput.log".
See also 
"/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64/CMakeFiles/CMakeError.log".
FAILED: build.ninja 
/Applications/CMake.app/Contents/bin/cmake 
-H/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/llvm 
-B/Users/buildnode/jenkins/workspace/oss-lldb-swift-3.1-incremental-osx/Ninja-ReleaseAssert/llvm-macosx-x86_64
 <>



> On Jan 31, 2017, at 10:50 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-lldb-swift-3.1-incremental-osx [#187]
> 
> Build URL:
> https://ci.swift.org/job/oss-lldb-swift-3.1-incremental-osx/187/ 
> 
> Project:  oss-lldb-swift-3.1-incremental-osx
> Date of build:Tue, 31 Jan 2017 10:50:27 -0800
> Build duration:   26 sec
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit e4215eb1b07ed69909b001216f83d51f743ef82b by friss:
> [CMake] Fixing variable names that were mistyped
> 
> edit: tools/driver/CMakeLists.txt
> 
> Commit d82b06d6ee1bebd4ed371fb08efd852c15071d5e by friss:
> Add the patch version to the embedded Info.plist.
> 
> edit: tools/driver/CMakeLists.txt

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

2017-01-31 Thread Michael Gottesman via swift-dev


> On Jan 31, 2017, at 12:07 AM, Mikio Takeuchi  wrote:
> 
> Hi Michael,
> 
> > If you are interested in the perf difference with ARC atomics, Roman 
> > recently added a mode to the compiler called -assume-single-threaded that 
> > uses non-atomic reference counts anywhere.
> 
> I think that is not exactly true.   As of now, -assume-single-threaded option 
> can eliminate atomic reference counts only for reference types. 
> 
> I tried -assume-single-threaded for compiling applications as well as swift 
> runtime, and found that atomic reference counts were still used for value 
> types and improvements were limited because of them.
> 
> SIL Instructions on value types (such as CopyValue) are not subtype of 
> RefCountingInst, therefore they don't have a mechanism to represent 
> atomicity. 

This is not an issue since currently copy value is lowered right after SILGen 
to instructions that /do/ have atomicity. My understanding is that the assume 
single threaded option runs a pass late to set these all to non-atomic.

> COW requires reference counts and, because of the lack of information, atomic 
> reference counts are assumed at many places in their codegen and runtime.

IMO again, this is not an issue due to the late pass.

> 
> I made a prototype which returns the right atomicity based on the compiler 
> option in order to eliminate atomic reference counts from generated code. I 
> also modified value witness functions to eliminate atomic reference counts 
> from them.  With these changes, atomic reference counts almost disappeared. 

The value witness functions I think are the larger potential issue.

> 
> If it makes sense, I am happy to contribute my changes to the community.  
> 
> I understand there are two problems with my prototype. 
> 1) We may need to introduce a mechanism to represent atomicity for value 
> types as well.  It will open an opportunity for compiler to use non-atomic 
> reference counts for thread-local values. 

Again, I do not think that is an issue since we lower these away today. This 
may require changes at a later time though once these value operations go 
further back into the compiler.

> 2) We need to either extend value witness table to add non-atomic version of 
> functions, or pass atomicity information to the functions as an extra 
> parameter.

Since your option makes an assumption that the whole program is single 
threaded, why couldn't we just emit the value witness functions such that they 
use non-atomic reference counts?

> 
> Since they are not trivial changes, I would like your endorsement before 
> starting serious work.

Send a PR and lets talk about it. [i.e. what Roman said ; )]

> 
> -- Mikio
> 
> 
> 2016-12-18 5:49 GMT+09:00 Michael Gottesman via swift-dev 
> mailto:swift-dev@swift.org>>:
> 
>> On Dec 17, 2016, at 11:13 AM, Brian Gesiak via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hello all!
>> 
>> I really enjoyed Chris Lattner's slides from his talk at IBM 
>> > >. 
>> 
>> The speaker notes mention ARC:
>> 
>> "There are two principle downsides to ARC that people cite: one is the need 
>> for atomic increment/decrements, which can be slow." [...] "The performance 
>> problems it can cause are real in some important cases"
>> 
>> Can someone point me to a good resource that explains these problems? I 
>> guess atomic reference count changes create overhead in multithreaded 
>> applications? Are there more detailed explorations into this topic?
> 
> With a proper concurrency model, I believe you can make most reference 
> counting operations local (my opinion). I have done some explorations in this 
> area in the past using what I call thread local vs global reference counts 
> and using marked concurrency boundaries to mediate transitions in between 
> them (moving from thread local -> atomic of course if one escapes in an 
> undefined way).
> 
> If you are interested in the perf difference with ARC atomics, Roman recently 
> added a mode to the compiler called -assume-single-threaded that uses 
> non-atomic reference counts anywhere.
> 
> There are some interesting optimizations in this area as well, specifically 
> even today, COW gives a nice guarantee of thread localness allowing you to 
> eliminate atomic reference counts once you have a uniqued cow data structure.
> 
> Michael
> 
>> 
>> Thanks!
>> 
>> - Brian Gesiak
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
>

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #816

2017-01-31 Thread Michael Ilseman via swift-dev

Corruption inside an xctest test?


# command stderr:
*** Error in 
`/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/Asynchronous-Predicates':
 double free or corruption (fasttop): 0x7f1b58000a70 ***

error: command failed with exit status: -6
$ "true"
$ 
"/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py"
 
"/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/Output/main.swift.tmp"
 
"/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift"
# command stderr:
Traceback (most recent call last):
  File 
"/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker.py",
 line 15, in 
xctest_checker.main.main()
  File 
"/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker/main.py",
 line 61, in main
compare.compare(args.actual, args.expected, args.check_prefix)
  File 
"/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/xctest_checker/xctest_checker/compare.py",
 line 85, in compare
repr(expected_line)))
xctest_checker.error.XCTestCheckerError: 
 
<>/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift-corelibs-xctest/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:26:
 There were more lines expected to appear than there were lines in the actual 
input. Unmet expectation: 
'.*/Tests/Functional/Asynchronous/Predicates/Expectations/main.swift:32: error: 
PredicateExpectationsTestCase.test_immediatelyFalsePredicateAndObject_fails : 
Asynchronous wait failed - Exceeded timeout of 0.1 seconds, with unfulfilled 
expectations: Expect `` for object '

error: command failed with exit status: 1

--



Testing Time: 2.16s

Failing Tests (1):
SwiftXCTestFunctionalTests :: 
Asynchronous/Predicates/Expectations/main.swift


> On Jan 30, 2017, at 10:53 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#816]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/816/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Mon, 30 Jan 2017 22:20:08 -0800
> Build duration:   33 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 44bbb3317bcfce8e1a5bc7cb900464d53f2da42f by sshamaia:
> String.hasPrefix and String.hasSuffix returns false if string pattern is
> 
> edit: Foundation/NSString.swift
> edit: TestFoundation/TestNSString.swift

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

2017-01-31 Thread Roman Levenstein via swift-dev

Hi Mikio,

> On Jan 31, 2017, at 12:07 AM, Mikio Takeuchi via swift-dev 
>  wrote:
> 
> Hi Michael,
> 
> > If you are interested in the perf difference with ARC atomics, Roman 
> > recently added a mode to the compiler called -assume-single-threaded that 
> > uses non-atomic reference counts anywhere.
> 
> I think that is not exactly true.   As of now, -assume-single-threaded option 
> can eliminate atomic reference counts only for reference types. 
> 
> I tried -assume-single-threaded for compiling applications as well as swift 
> runtime, and found that atomic reference counts were still used for value 
> types and improvements were limited because of them.

That’s correct.  -assume-single-threaded  does not cover all cases. I think it 
is even mentioned somewhere in the comments. It was meant as a quick hack to 
allow some experiments in this direction. 

> 
> SIL Instructions on value types (such as CopyValue) are not subtype of 
> RefCountingInst, therefore they don't have a mechanism to represent 
> atomicity.  COW requires reference counts and, because of the lack of 
> information, atomic reference counts are assumed at many places in their 
> codegen and runtime.
> 
> I made a prototype which returns the right atomicity based on the compiler 
> option in order to eliminate atomic reference counts from generated code. I 
> also modified value witness functions to eliminate atomic reference counts 
> from them.  With these changes, atomic reference counts almost disappeared. 

Cool! Thanks for working on this! 

Could you report some preliminary performance improvement due to these changes? 
It would be interesting to see the comparison with the vanilla Swift compiler, 
the existing -assume-single-threaded option and your improvements.

> 
> If it makes sense, I am happy to contribute my changes to the community.  
> 
> I understand there are two problems with my prototype. 
> 1) We may need to introduce a mechanism to represent atomicity for value 
> types as well.  It will open an opportunity for compiler to use non-atomic 
> reference counts for thread-local values. 
> 2) We need to either extend value witness table to add non-atomic version of 
> functions, or pass atomicity information to the functions as an extra 
> parameter.
> 
> Since they are not trivial changes, I would like your endorsement before 
> starting serious work.

It would be interesting to see your code in any case. Could you share a link to 
the branch with your changes?

Regarding the question about the future work on the prototype, let’s first see 
the code and taken implementation approach. Then we could discuss its design. 
etc.  

-Roman

> 
> -- Mikio
> 
> 
> 2016-12-18 5:49 GMT+09:00 Michael Gottesman via swift-dev 
> mailto:swift-dev@swift.org>>:
> 
>> On Dec 17, 2016, at 11:13 AM, Brian Gesiak via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hello all!
>> 
>> I really enjoyed Chris Lattner's slides from his talk at IBM 
>> > >. 
>> 
>> The speaker notes mention ARC:
>> 
>> "There are two principle downsides to ARC that people cite: one is the need 
>> for atomic increment/decrements, which can be slow." [...] "The performance 
>> problems it can cause are real in some important cases"
>> 
>> Can someone point me to a good resource that explains these problems? I 
>> guess atomic reference count changes create overhead in multithreaded 
>> applications? Are there more detailed explorations into this topic?
> 
> With a proper concurrency model, I believe you can make most reference 
> counting operations local (my opinion). I have done some explorations in this 
> area in the past using what I call thread local vs global reference counts 
> and using marked concurrency boundaries to mediate transitions in between 
> them (moving from thread local -> atomic of course if one escapes in an 
> undefined way).
> 
> If you are interested in the perf difference with ARC atomics, Roman recently 
> added a mode to the compiler called -assume-single-threaded that uses 
> non-atomic reference counts anywhere.
> 
> There are some interesting optimizations in this area as well, specifically 
> even today, COW gives a nice guarantee of thread localness allowing you to 
> eliminate atomic reference counts once you have a uniqued cow data structure.
> 
> Michael
> 
>> 
>> Thanks!
>> 
>> - Brian Gesiak
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
> 
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
>

Re: [swift-dev] Linux Swift API

2017-01-31 Thread Johannes Weiß via swift-dev

Hi Roman,

> On 31 Jan 2017, at 15:51, Roman Pastushkov via swift-dev 
>  wrote:
> 
> Hello everyone! Now i am trying (newbie) on Ubuntu Swift 3. I am trying to 
> Read String from File Using FileHandle
> 
> import Foundation
> let filemgr = FileManager.default
> let filepath1 = "/home/roman/test"
> 
> let file: FileHandle? = FileHandle(forReadingAtPath: filepath1)
> 
> if file == nil {
> print("File open failed")
> } else {
> let databuffer = file?.readDataToEndOfFile
> let String1 = String(databuffer, encoding: String.Encoding.utf8)
> file?.closeFile()
> print(String1)
> } 
> 
> But get error from compiler 
> /home/roman/swift/Sources/main.swift:11:19: error: 'init' has been renamed to 
> 'init(describing:)'
> let String1 = String(databuffer, encoding: String.Encoding.utf8)
>   ^
> Swift.String:21:12: note: 'init' has been explicitly marked unavailable here
> public init(_: T)
>^

the error message is actually quite misleading. There are a few things that you 
need to correct:

you want the following constructor:
String(data: databuffer, encoding: String.Encoding.utf8)
   ^

also, readDataToEndOfFile is a method, so you'll need to call it 
(`file?.readDataToEndOfFile()`) and lastly, databuffer will then have the type 
Data? (aka Optional) so you might want to use a 'if let'. The working 
program could then look like this:

import Foundation
let filemgr = FileManager.default
let filepath1 = "/home/roman/test"

let file: FileHandle? = FileHandle(forReadingAtPath: filepath1)

if file == nil {
print("File open failed")
} else {
if let databuffer = file?.readDataToEndOfFile() {
let String1 = String(data: databuffer, encoding: String.Encoding.utf8)
file?.closeFile()
print("\(String1)")
} else {
print("File read failed")
}   
}

HTH,
  Johannes
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] Linux Swift API

2017-01-31 Thread Roman Pastushkov via swift-dev


Hello everyone! Now i am trying (newbie) on Ubuntu Swift 3. I am trying to Read 
String from File Using FileHandle


import Foundation
let filemgr = FileManager.default
let filepath1 = "/home/roman/test"


let file: FileHandle? = FileHandle(forReadingAtPath: filepath1)


if file == nil {
print("File open failed")
} else {
let databuffer = file?.readDataToEndOfFile
let String1 = String(databuffer, encoding: String.Encoding.utf8)
file?.closeFile()
print(String1)
} 


But get error from compiler 

/home/roman/swift/Sources/main.swift:11:19: error: 'init' has been renamed to 
'init(describing:)'
let String1 = String(databuffer, encoding: String.Encoding.utf8)
  ^
Swift.String:21:12: note: 'init' has been explicitly marked unavailable here
public init(_: T)
   ^
:0: error: build had 1 command failures
error: exit(1): 
/home/roman/swift-3.0.2-RELEASE-ubuntu16.04/usr/bin/swift-build-tool -f 
/home/roman/swift/.build/debug.yaml


Why it talking about init? when i use String


Roman Pastushkov
xnucleargemi...@aol.com


___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

2017-01-31 Thread Mikio Takeuchi via swift-dev

Hi Michael,

> If you are interested in the perf difference with ARC atomics, Roman
recently added a mode to the compiler called -assume-single-threaded that
uses non-atomic reference counts anywhere.

I think that is not exactly true.   As of now, -assume-single-threaded
option can eliminate atomic reference counts only for reference types.

I tried -assume-single-threaded for compiling applications as well as swift
runtime, and found that atomic reference counts were still used for value
types and improvements were limited because of them.

SIL Instructions on value types (such as CopyValue) are not subtype of
RefCountingInst, therefore they don't have a mechanism to represent
atomicity.  COW requires reference counts and, because of the lack of
information, atomic reference counts are assumed at many places in their
codegen and runtime.

I made a prototype which returns the right atomicity based on the compiler
option in order to eliminate atomic reference counts from generated code. I
also modified value witness functions to eliminate atomic reference counts
from them.  With these changes, atomic reference counts almost disappeared.

If it makes sense, I am happy to contribute my changes to the community.

I understand there are two problems with my prototype.
1) We may need to introduce a mechanism to represent atomicity for value
types as well.  It will open an opportunity for compiler to use non-atomic
reference counts for thread-local values.
2) We need to either extend value witness table to add non-atomic version
of functions, or pass atomicity information to the functions as an extra
parameter.

Since they are not trivial changes, I would like your endorsement before
starting serious work.

-- Mikio

2016-12-18 5:49 GMT+09:00 Michael Gottesman via swift-dev <
swift-dev@swift.org>:

>
> On Dec 17, 2016, at 11:13 AM, Brian Gesiak via swift-dev <
> swift-dev@swift.org> wrote:
>
> Hello all!
>
> I really enjoyed Chris Lattner's slides from his talk at IBM <
> http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf
> >.
>
> The speaker notes mention ARC:
>
> "There are two principle downsides to ARC that people cite: one is the
> need for atomic increment/decrements, which can be slow." [...] "The
> performance problems it can cause are real in some important cases"
>
> Can someone point me to a good resource that explains these problems? I
> guess atomic reference count changes create overhead in multithreaded
> applications? Are there more detailed explorations into this topic?
>
>
> With a proper concurrency model, I believe you can make most reference
> counting operations local (my opinion). I have done some explorations in
> this area in the past using what I call thread local vs global reference
> counts and using marked concurrency boundaries to mediate transitions in
> between them (moving from thread local -> atomic of course if one escapes
> in an undefined way).
>
> If you are interested in the perf difference with ARC atomics, Roman
> recently added a mode to the compiler called -assume-single-threaded that
> uses non-atomic reference counts anywhere.
>
> There are some interesting optimizations in this area as well,
> specifically even today, COW gives a nice guarantee of thread localness
> allowing you to eliminate atomic reference counts once you have a uniqued
> cow data structure.
>
> Michael
>
>
> Thanks!
>
> - Brian Gesiak
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.04 (master) #421

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - LLDB Incremental - OS X (swift 3.1) #187

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #816

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

Re: [swift-dev] Linux Swift API

[swift-dev] Linux Swift API

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

15 matches

Site Navigation

Mail list logo

Footer information