[swift-dev] SIMD in open source Swift?
Robert F Dickerson
rfdickerson at us.ibm.com
Mon Apr 18 12:55:05 CDT 2016
I think that would be excellent. I am a maintainer for Surge which depends
on the Accelerate module. I believe we can create a wrapper around the
xmmintrin.h headers and expose the API similar to Accelerate.
From: swift-dev-request at swift.org
To: swift-dev at swift.org
Date: 04/18/2016 11:57 AM
Subject: swift-dev Digest, Vol 5, Issue 18
Sent by: swift-dev-bounces at swift.org
Send swift-dev mailing list submissions to
swift-dev at swift.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.swift.org/mailman/listinfo/swift-dev
or, via email, send a message with subject or body 'help' to
swift-dev-request at swift.org
You can reach the person managing the list at
swift-dev-owner at swift.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of swift-dev digest..."
Today's Topics:
1. Re: [SR-710][RFC] Automatically detecting XCTest test methods
on Linux: Reflection? SourceKit? (Brian Gesiak)
2. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Timothy Wood)
3. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Joe Bell)
4. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Timothy Wood)
5. Random failure when building Swift on Pi (Timothy Wood)
6. Re: [SR-710][RFC] Automatically detecting XCTest test methods
on Linux: Reflection? SourceKit? (Drew Crawford)
7. Re: R_ARM_GOT_PREL error when building Swift on Pi from
source (Timothy Wood)
8. SIMD in open source Swift? (Geordie Jay)
9. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
Ubuntu 15.10 (master) #4254 (Sean Callanan)
10. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
Ubuntu 15.10 (master) #4254 (Sean Callanan)
11. Re: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA -
OS X (master) #3432 (Sean Callanan)
----------------------------------------------------------------------
Message: 1
Date: Sun, 17 Apr 2016 14:36:08 -0400
From: Brian Gesiak <modocache at gmail.com>
To: Daniel Dunbar <daniel_dunbar at apple.com>
Cc: swift-dev <swift-dev at swift.org>
Subject: Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest
test methods on Linux: Reflection? SourceKit?
Message-ID:
<CAN7MxmX3aeuCK3TQepC5cwJ+hzVK8v1FXQQwiqEt5c0tqF7t
+A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
In case anyone interested missed it, John Holdsworth mentions another
approach in a comment on https://bugs.swift.org/browse/SR-710: using
runtime metadata to find a list of tests. The linked project contains an
example. It:
1. Specifies a test method regex:
https://github.com/johnno1962/TestRunner/blob/201bd04af14fdebf1a7fa2ae0a419fc59d6266ed/TestRunner/AppDelegate.swift#L69
2. In Swift, the project exposes metadata information for Swift objects:
https://github.com/johnno1962/TestRunner/blob/201bd04af14fdebf1a7fa2ae0a419fc59d6266ed/TestRunner/TestRunner.swift#L52
3. Uses an UnsafeMutablePointer<ClassMetadataSwift> to get a reference to
the methods defined on an instance:
https://github.com/johnno1962/TestRunner/blob/201bd04af14fdebf1a7fa2ae0a419fc59d6266ed/TestRunner/TestRunner.swift#L97
I assume this approach won't be acceptable to some because it relies on
private information about Swift objects, but I don't know for sure. Please
chime in if this approach seems reasonable to you!
Based on the assumption that we can't use metadata, however, I'm going to
try to begin working on approaches #2 or #3, which I mentioned in my
original email. I think the preliminary work is the same (like
moving SourceKit::FuncDeclEntityInfo.IsTestCandidate to libIDE), so I'll
hold off on making a hard decision between #2 and #3 until necessary.
- Brian Gesiak
On Mon, Apr 4, 2016 at 12:23 AM, Daniel Dunbar <daniel_dunbar at apple.com>
wrote:
>
> > On Apr 3, 2016, at 3:36 PM, Dmitri Gribenko <gribozavr at gmail.com>
wrote:
> >
> > On Sun, Apr 3, 2016 at 2:11 PM, Brian Gesiak <modocache at gmail.com>
> wrote:
> >> I think #2 is the best option. It’s less work than both #1 and #3. I
> believe
> >> logic like IsTestCandidate belongs in libIDE anyway—SourceKit should
> stick
> >> to XPC and asynchronous communication with libIDE.
> >
> > I like #3 better (an option to swiftc), because that would decouple
> > the test discovery tool from the Swift compiler. That would allow you
> > to use the discovery tool with different compilers. And, because we
> > would avoid statically linking libIDE, it would mean one less copy of
> > LLVM, Clang and Swift in the toolchain.
>
> Ultimately my opinion is that it is likely that the package manager will
> want an API interface to Swift in any case. I personally would rather we
> simply plan on that.
>
> I also would like to avoid duplicating anything in the toolchain, but
> think that should be done by moving the driver to sitting on top of a
> shared library.
>
> >> Not being an expert in many of these components, I have several
> questions:
> >>
> >> I’m assuming the reflection API to return a list of instance methods
on
> a
> >> XCTestCase subclass is not ready yet, and won’t be for some time. Is
> this
> >> accurate?
> >
> > I think so.
> >
> >> I’m assuming that SourceKit is intended to be an asynchronous wrapper
> over
> >> libIDE, and that logic like IsTestCandidate should be moved to libIDE.
> Is
> >> this accurate?
> >
> > SourceKit has a lot of functionality of its own, but moving this
> > particular piece of logic to libIDE sounds reasonable.
> >
> >> I’m assuming that SourceKit is coupled with XPC, and that it would be
> more
> >> work to port it to Linux than it would be to move its logic to libIDE.
> Is
> >> this accurate?
> >
> > It is not tightly coupled with XPC, there is a portability layer that
> > you could implement for Linux. You would need to decide on an IPC
> > mechanism and serialization format though.
>
> For our purposes, I don't think we need IPC. I think a direct (C) library
> interface would be fine. Clients can implement the IPC/XPC if they need
it.
>
> >> If you have thoughts/feedback, please reply to this email or comment
on
> >> SR-710. Your input would be greatly appreciated!!
> >
> > I'm wondering how feasible is it to change the XCTest API to
> > accommodate better the Swift language that we have, rather than trying
> > to add custom tooling to make the existing API work. Adding magic
> > tooling that adds behavior not present in the language seems unnatural
> > to me.
>
> I agree with you that it is unnatural, but I think this ship has sailed
> for XCTest, we have a need to support the existing API in a cross
platform
> manner.
>
> My personal preference is that eventually we would build features like
> this on top of general support for attributes (a la Java/Python/C#).
>
> > Compare with StdlibUnittest -- by using an API to build tests we get
> > the following advantages:
> >
> > - We completely avoid having the issue of test discovery, executing
> > the code discovers the tests. No reflection needed!
>
> While I think StdlibUnittest is neat, I also believe that there are very
> good reasons for supporting test discovery in a test suite. I have used
> these features in other suites to great avail to create (bidirectional,
> sometimes) lit bridge adaptors between various test frameworks (Python
> unittest, googletest, XCTest).
>
> In an IDE context, it is also very useful to be able to perform test
> discovery independent of test execution.
>
> As one other example, I've used lit with suites with hundreds of
thousands
> of tests... it would be unfortunate to have to dynamically discover all
of
> those tests when the user is just trying to run a single one.
>
> > - We can add attributes to tests (for example, skip, xfail). In the
> > current XCTest API this would require adding some kind of user-defined
> > attributes, which is another language which is a long way from being
> > designed and implemented.
>
> This isn't necessarily the case, XCTest could in theory provide explicit
> APIs to do these things as part of test execution. I agree attributes are
a
> better fit in the current model.
>
> > - We can define data-parameterized tests.
>
> > - Tests can be dynamically synthesized by control flow. In the
> > current XCTest API, dynamically generating tests would mean
> > dynamically generating methods, which is even more far off than
> > read-only method reflection.
>
> FWIW, XCTest has some support for doing these kinds of things, they just
> don't take the form of the pattern-matched methods.
>
> - Daniel
>
> >
> > Dmitri
> >
> > --
> > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/1346eb08/attachment-0001.html
>
------------------------------
Message: 2
Date: Sun, 17 Apr 2016 13:46:33 -0700
From: Timothy Wood <tjw at omnigroup.com>
To: William Dillon <william at housedillon.com>
Cc: Kenny Leung via swift-dev <swift-dev at swift.org>
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <29ABC0C6-92D9-4A67-ABD0-4CDDE2F5C45E at omnigroup.com>
Content-Type: text/plain; charset="utf-8"
> On Apr 16, 2016, at 2:23 PM, William Dillon <william at housedillon.com>
wrote:
>
> What LLVM are you using?
>
> You have to use the one from my github (and the arm branch) or it won't
work:
>
> https://github.com/hpux735/swift-llvm/tree/arm <
https://github.com/hpux735/swift-llvm/tree/arm>
>
> I haven't had time to upstream the changes to LLVM.
>
> - Will
Ah, thanks! I was using <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch>>, but will give
your fork a try!
-tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/5349c220/attachment-0001.html
>
------------------------------
Message: 3
Date: Sun, 17 Apr 2016 15:52:20 -0500
From: Joe Bell <joe at iachieved.it>
To: Timothy Wood <tjw at omnigroup.com>
Cc: Kenny Leung via swift-dev <swift-dev at swift.org>
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <5D20A476-5349-426C-B884-49E202631D80 at iachieved.it>
Content-Type: text/plain; charset="utf-8"
I'll join in Tim and try compiling again on the BeagleX15, it failed the
other day but I forgot about using Wills LLVM
Joe
> On Apr 17, 2016, at 3:46 PM, Timothy Wood via swift-dev
<swift-dev at swift.org> wrote:
>
>
>> On Apr 16, 2016, at 2:23 PM, William Dillon <william at housedillon.com>
wrote:
>>
>> What LLVM are you using?
>>
>> You have to use the one from my github (and the arm branch) or it won't
work:
>>
>> https://github.com/hpux735/swift-llvm/tree/arm
>>
>> I haven't had time to upstream the changes to LLVM.
>>
>> - Will
>
>
> Ah, thanks! I was using <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch>, but will give
your fork a try!
>
> -tim
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/ac2ace8e/attachment-0001.html
>
------------------------------
Message: 4
Date: Sun, 17 Apr 2016 13:55:31 -0700
From: Timothy Wood <tjw at omnigroup.com>
To: Joe Groff <jgroff at apple.com>
Cc: swift-dev at swift.org
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <FFDED274-9542-4266-A319-DAD6B10184CC at omnigroup.com>
Content-Type: text/plain; charset=utf-8
> On Apr 15, 2016, at 6:45 PM, Joe Groff <jgroff at apple.com> wrote:
> What linker are you using? GNU ld 2.26 in particular changed the behavior
of protected visibility in a way that's incompatible with our usage, and we
haven't fully implemented a workaround. You might try using gold or an
older binutils, if that's what you're currently using.
I could have sworn I was using gold, but looking at my logs it was using
the standard linker. Perhaps I’m remembering an attempt from the Swift 3
sources… Anyway, my current attempts are using this invocation now (though
I’m getting other failures now):
utils/build-script -t -R -j 4 -- --use-gold-linker
Thanks!
-tim
------------------------------
Message: 5
Date: Sun, 17 Apr 2016 13:55:35 -0700
From: Timothy Wood <tjw at me.com>
To: swift-dev at swift.org
Subject: [swift-dev] Random failure when building Swift on Pi
Message-ID: <6904C5F0-0395-48B7-9092-8117D82342BE at me.com>
Content-Type: text/plain; charset="utf-8"
I’m encountering random build compile failures when building on Pi, using
clang-3.6 (as suggested in the various instructions to do so), and when
using <https://github.com/hpux735/swift-llvm/tree/arm>
One example looks like:
FAILED: /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Ilib/Support -I/home/pi/Source/Swift/llvm/lib/Support -Iinclude
-I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O3
-UNDEBUG -fno-exceptions -fno-rtti -MMD -MT
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o -MF
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
-c /home/pi/Source/Swift/llvm/lib/Support/YAMLTraits.cpp
Stack dump:
0. Program arguments: /usr/lib/llvm-3.6/bin/clang -cc1 -triple
armv6-unknown-linux-gnueabihf -emit-obj -disable-free
-disable-llvm-verifier -main-file-name YAMLTraits.cpp -mrelocation-model
pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu
arm1136jf-s -target-abi aapcs-linux -mfloat-abi hard -target-linker-version
2.25 -dwarf-column-info -ffunction-sections -fdata-sections
-coverage-file /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7/lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
-resource-dir /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 -dependency-file
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o.d -MT
lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o -D GTEST_HAS_RTTI=0
-D _DEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS
-D __STDC_LIMIT_MACROS -U NDEBUG -I lib/Support
-I /home/pi/Source/Swift/llvm/lib/Support -I include
-I /home/pi/Source/Swift/llvm/include
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9/backward -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
-internal-externc-isystem /usr/include/arm-linux-gnueabihf
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-O3 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -pedantic -std=c++11
-fdeprecated-macro
-fdebug-compilation-dir /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7
-ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden
-mstackrealign -fno-rtti -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops
-vectorize-slp -o lib/Support/CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o
-x c++ /home/pi/Source/Swift/llvm/lib/Support/YAMLTraits.cpp
1. /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c+
+/4.9/ext/type_traits.h:113:6: current parser token ';'
2. /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c+
+/4.9/ext/type_traits.h:37:1: parsing namespace '__gnu_cxx'
3. /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c+
+/4.9/ext/type_traits.h:106:5: parsing struct/union/class body
'__remove_unsigned'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://bugs.debian.org/ and include the crash backtrace, preprocessed
source, and associated run script.
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/YAMLTraits-d1f411.cpp
clang: note: diagnostic msg: /tmp/YAMLTraits-d1f411.sh
clang: note: diagnostic msg:
But, if I run the emitted script it works fine:
pushd /tmp
bash /tmp/YAMLTraits-d1f411.sh
Or, another example (where clang++ isn’t crashing):
FAILED: /usr/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Iutils/TableGen -I/home/pi/Source/Swift/llvm/utils/TableGen -Iinclude
-I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O3
-UNDEBUG -fno-exceptions -fno-rtti -MMD -MT
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o -MF
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o.d -o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
-c /home/pi/Source/Swift/llvm/utils/TableGen/CodeGenInstruction.cpp
Stack dump:
0. Program arguments: /usr/lib/llvm-3.6/bin/clang -cc1 -triple
armv6-unknown-linux-gnueabihf -emit-obj -disable-free
-disable-llvm-verifier -main-file-name CodeGenInstruction.cpp
-mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array
-target-cpu arm1136jf-s -target-abi aapcs-linux -mfloat-abi hard
-target-linker-version 2.25 -dwarf-column-info -ffunction-sections
-fdata-sections
-coverage-file /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7/utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
-resource-dir /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2 -dependency-file
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o.d
-MT utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
-D GTEST_HAS_RTTI=0 -D _DEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D
__STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -U NDEBUG -I utils/TableGen
-I /home/pi/Source/Swift/llvm/utils/TableGen -I include
-I /home/pi/Source/Swift/llvm/include
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/arm-linux-gnueabihf/c
++/4.9
-internal-isystem /usr/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c
++/4.9/backward -internal-isystem /usr/local/include
-internal-isystem /usr/lib/llvm-3.6/bin/../lib/clang/3.6.2/include
-internal-externc-isystem /usr/include/arm-linux-gnueabihf
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-O3 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -pedantic -std=c++11
-fdeprecated-macro
-fdebug-compilation-dir /home/pi/Source/Swift/build/Ninja-ReleaseAssert/llvm-linux-armv7
-ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden
-mstackrealign -fno-rtti -fno-signed-char -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops
-vectorize-slp -o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o -x c
++ /home/pi/Source/Swift/llvm/utils/TableGen/CodeGenInstruction.cpp
1. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:718:44:
current parser token ')'
2. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:31:1: parsing
namespace 'llvm'
3. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:700:56:
parsing function body 'swap'
4. /home/pi/Source/Swift/llvm/include/llvm/ADT/SmallVector.h:700:56: in
compound statement ('{}')
error: unable to rename temporary
'utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o-9c605f46'
to output file
'utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o':
'No such file or directory'
1 error generated.
Each time I invoke the build script I get a few files further:
utils/build-script -t -R -j 4 -- --use-gold-linker
In my previous attempts to build Swift on Pi, I’d not seen this, so I’m
confused why it’s started now. My only working theories so far are that
when I did an `apt-get update`/`apt-get upgrade` to check for a new Swift
build, I applied a whole bunch of other updates to the system or second,
maybe my microSD card is going bad =/
-tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/089ccc30/attachment-0001.html
>
------------------------------
Message: 6
Date: Sun, 17 Apr 2016 16:50:47 -0500
From: Drew Crawford <drew at sealedabstract.com>
To: Dmitri Gribenko <gribozavr at gmail.com>
Cc: swift-dev <swift-dev at swift.org>
Subject: Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest
test methods on Linux: Reflection? SourceKit?
Message-ID: <CD4EB0A4-4521-4E81-8FDC-5D3B27DD70BC at sealedabstract.com>
Content-Type: text/plain; charset="utf-8"
> On Apr 3, 2016, at 10:05 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>
>> Hmm... but then wouldn't that more tightly couple the test discovery
tool
>> and the Swift compiler? In an earlier email you said you "like #3 better
>> [...] because that would decouple the test discovery tool from the Swift
>> compiler." I think that part is confusing me.
>
> Sorry -- what I meant is that the compiler remains the point of truth
> about the language and can find the tests. The tools that actually
> generate glue code won't need to parse code, and would be decoupled
> from the compiler.
I am internally shipping a test framework that discovers tests via an
out-of-tree parser. Teaching swiftc about XCTest syntax is not sufficient
to deprecate my parser, and therefore is not sufficient for the compiler to
be the source of truth for my tests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/00b0efb5/attachment-0001.html
>
------------------------------
Message: 7
Date: Sun, 17 Apr 2016 23:33:08 -0700
From: Timothy Wood <tjw at me.com>
To: William Dillon <william at housedillon.com>, Kenny Leung via
swift-dev <swift-dev at swift.org>
Subject: Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on
Pi from source
Message-ID: <BB74C65D-3547-4FCB-A43D-F74E8B81CBA7 at me.com>
Content-Type: text/plain; charset="utf-8"
> On Apr 17, 2016, at 1:46 PM, Timothy Wood via swift-dev
<swift-dev at swift.org> wrote:
>
>
>> On Apr 16, 2016, at 2:23 PM, William Dillon <william at housedillon.com <
mailto:william at housedillon.com>> wrote:
>>
>> What LLVM are you using?
>>
>> You have to use the one from my github (and the arm branch) or it won't
work:
>>
>> https://github.com/hpux735/swift-llvm/tree/arm <
https://github.com/hpux735/swift-llvm/tree/arm>
>>
>> I haven't had time to upstream the changes to LLVM.
>>
>> - Will
>
>
> Ah, thanks! I was using <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch <
https://github.com/apple/swift-llvm/tree/swift-2.2-branch>>, but will give
your fork a try!
>
> -tim
>
I reset my Pi 3 to a fresh install of Jessie (2016-03-18), did the
clang-3.6 install from <
http://dev.iachieved.it/iachievedit/open-source-swift-on-raspberry-pi-2/>
and tried building with the above mentioned branch of llvm. This fixed the
spurious build failures I was seeing, but I’m hitting a persistent build
failure now:
[939/1818] Building CXX object
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
FAILED: /usr/bin/clang++-3.6 -DCLANG_ENABLE_ARCMT
-DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/utils/TableGen
-I/home/pi/Source/Swift/llvm/tools/clang/utils/TableGen
-I/home/pi/Source/Swift/llvm/tools/clang/include -Itools/clang/include
-Iinclude -I/home/pi/Source/Swift/llvm/include -fno-stack-protector -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections
-fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3 -UNDEBUG
-fno-exceptions -fno-rtti -MMD -MT
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
-MF
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o.d
-o
tools/clang/utils/TableGen/CMakeFiles/obj.clang-tblgen.dir/ClangAttrEmitter.cpp.o
-c /home/pi/Source/Swift/llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp
/home/pi/Source/Swift/llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp:1075:23:
error: no viable conversion from 'ArrayRef<std::pair<Record *, SMRange>>'
to 'ArrayRef<llvm::Record *>'
ArrayRef<Record*> Bases = Search->getSuperClasses();
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/Source/Swift/llvm/include/llvm/ADT/ArrayRef.h:32:9: note:
candidate constructor (the implicit copy constructor) not viable: no known
conversion from 'ArrayRef<std::pair<Record *, SMRange> >' to 'const
llvm::ArrayRef<llvm::Record *> &' for 1st argument
class ArrayRef {
^
/home/pi/Source/Swift/llvm/include/llvm/ADT/ArrayRef.h:32:9: note:
candidate constructor (the implicit move constructor) not viable: no known
conversion from 'ArrayRef<std::pair<Record *, SMRange> >' to
'llvm::ArrayRef<llvm::Record *> &&' for 1st argument
class ArrayRef {
...
I might try again tomorrow updating to a newer clang build, or maybe I
should just wave the white flag and rewrite my tiny codebase in C++ instead
of trying to use Swift here, and wait for it to be a bit more
stable/supported.
-tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160417/789510bf/attachment-0001.html
>
------------------------------
Message: 8
Date: Mon, 18 Apr 2016 17:39:51 +0200
From: Geordie Jay <geojay at gmail.com>
To: swift-dev at swift.org
Subject: [swift-dev] SIMD in open source Swift?
Message-ID: <B4B1849C-8046-4C00-A34A-72BDC4CB08A8 at gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear fellow Swift-Devvers,
On Darwin we have a SIMD module, but I’m assuming (based on playing around
with it in the past) that it is unavailable in open-source Swift.
Does anyone know another way of using SIMD intrinsics in a cross-platform
way (Linux-only would also do)? Also, is it a goal to provide at least SIMD
intrinsics and basic operations within Swift’s core in the future, or is
the general philosophy that this kind of thing will be maintained by the
community?
Regards,
Geordie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <
https://lists.swift.org/pipermail/swift-dev/attachments/20160418/7083c5d4/attachment-0001.sig
>
------------------------------
Message: 9
Date: Fri, 15 Apr 2016 17:00:18 -0700
From: Sean Callanan <scallanan at apple.com>
To: swift-dev at swift.org
Subject: Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift
Incremental RA - Ubuntu 15.10 (master) #4254
Message-ID: <5DC21488-5922-40B9-9EDA-E3159B1B0099 at apple.com>
Content-Type: text/plain; charset="utf-8"
I’m on it.
Sean
> On Apr 15, 2016, at 4:56 PM, no-reply at swift.org wrote:
>
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#4254]
>
> Build URL:
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/
<https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/
>
> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build: Fri, 15 Apr 2016 16:48:20 -0700
> Build duration: 8 min 3 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 <
https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/consoleFull#-1652570388ee1a197b-acac-4b17-83cf-a53b95139a76
>
> Regression test failed: This build failed because a regression test in
the test suite FAILed. Below is a list of all errors:
> Indication 1 <
https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/consoleFull#1729578532fca400bf-2f4a-462e-b517-e058d770b2d7
>
> Tests:
>
> Name: Swift
> Failed: 11 test(s), Passed: 7798 test(s), Total: 7809 test(s)
> Failed: Swift.PlaygroundTransform.array.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/array_swift
>
> Failed: Swift.PlaygroundTransform.array_did_set.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/array_did_set_swift
>
> Failed: Swift.PlaygroundTransform.bare_value.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/bare_value_swift
>
> Failed: Swift.PlaygroundTransform.control-flow.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/control_flow_swift
>
> Failed: Swift.PlaygroundTransform.declarations.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/declarations_swift
>
> Failed: Swift.PlaygroundTransform.do-catch.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/do_catch_swift
>
> Failed: Swift.PlaygroundTransform.do.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/do_swift
>
> Failed: Swift.PlaygroundTransform.high_performance.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/high_performance_swift
>
> Failed: Swift.PlaygroundTransform.init.swift <
https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4254/testReport/junit/Swift/PlaygroundTransform/init_swift
>
> Failed: Swift.PlaygroundTransform.mutation.swift <
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160418/4d550935/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160418/4d550935/attachment.gif>
More information about the swift-dev
mailing list