I see that in our Linux builds clang complains that it does not support the swiftcall attribute.
In file included from /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/unittests/runtime/Metadata.cpp:13:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/include/swift/Runtime/Metadata.h:3015:1: warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes]
How bad is this? Do we not use a custom calling convention on Linux platforms today?
This is while building the metadata unit tests — I’m assuming those are built with the host clang? Do we build the runtime with the Swift clang on Linux? If so, we should still be able to use swiftcall.
Slava
···
On Nov 13, 2017, at 10:47 PM, Greg Parker via swift-dev <swift-dev@swift.org> wrote:
I see that in our Linux builds clang complains that it does not support the swiftcall attribute.
In file included from /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/unittests/runtime/Metadata.cpp:13:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/include/swift/Runtime/Metadata.h:3015:1: warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes]
How bad is this? Do we not use a custom calling convention on Linux platforms today?
This is while building the metadata unit tests — I’m assuming those are built with the host clang? Do we build the runtime with the Swift clang on Linux? If so, we should still be able to use swiftcall.
Yes we build the runtime with the “just built clang”. We should switch over the unit tests tests too. They definitely could call code in the runtime where the ABI difference matters: for example heap object destructors use swiftcc.
···
On Nov 14, 2017, at 12:33 AM, Slava Pestov via swift-dev <swift-dev@swift.org> wrote:
Slava
On Nov 13, 2017, at 10:47 PM, Greg Parker via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I see that in our Linux builds clang complains that it does not support the swiftcall attribute.
In file included from /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/unittests/runtime/Metadata.cpp:13:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/include/swift/Runtime/Metadata.h:3015:1: warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes]
How bad is this? Do we not use a custom calling convention on Linux platforms today?
On Nov 14, 2017, at 7:52 AM, Arnold Schwaighofer <aschwaighofer@apple.com> wrote:
On Nov 14, 2017, at 12:33 AM, Slava Pestov via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
On Nov 13, 2017, at 10:47 PM, Greg Parker via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
I see that in our Linux builds clang complains that it does not support the swiftcall attribute.
In file included from /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/unittests/runtime/Metadata.cpp:13:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/swift/include/swift/Runtime/Metadata.h:3015:1: warning: unknown attribute 'swiftcall' ignored [-Wunknown-attributes]
How bad is this? Do we not use a custom calling convention on Linux platforms today?
This is while building the metadata unit tests — I’m assuming those are built with the host clang? Do we build the runtime with the Swift clang on Linux? If so, we should still be able to use swiftcall.
Yes we build the runtime with the “just built clang”. We should switch over the unit tests tests too. They definitely could call code in the runtime where the ABI difference matters: for example heap object destructors use swiftcc.