Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev > wrote: > > In swift_retain/release, we have an early-exit check to pass through a nil > pointer. Since we're already burning branch, I'm thinking we could pass > through not only zero but negative pointer values too on 64-bit systems, >

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 12, 2016, at 4:36 PM, John McCall via swift-dev > wrote: > >> On Oct 12, 2016, at 3:46 PM, Greg Parker > > wrote: >>> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> On Oct 11, 2016, at 8:10 PM, Joe Gr

Re: [swift-dev] copy-on-write proposal

> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev > wrote: > > This is a proposal for representing copy-on-write buffers in SIL. Actually > it’s still a draft for a proposal. It also heavily depends on how we move > forward with SIL ownership. > > If you have any comments, please le

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 9:04 AM, Joe Groff via swift-dev > wrote: > > >> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev > > wrote: >> >> In swift_retain/release, we have an early-exit check to pass through a nil >> pointer. Since we're already burning branch, I

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 13, 2016, at 9:30 AM, Michael Gottesman wrote: >> On Oct 12, 2016, at 4:36 PM, John McCall via swift-dev > > wrote: >> >>> On Oct 12, 2016, at 3:46 PM, Greg Parker >> > wrote: On Oct 12, 2016, at 11:11 AM, John McCall via swift-d

[swift-dev] Dictionary Collision Resolution Guarantees

I’m currently cleaning up the docs on Dictionary to reflect the new indexing model, and I stumbled across the note that the following code should work assuming no reallocations occur: // // var (i, found) = d.find(k) // i is associated with d's buffer // if found { // var e = d

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 10:46 AM, John McCall via swift-dev > wrote: > >> On Oct 13, 2016, at 9:04 AM, Joe Groff via swift-dev > > wrote: >> >>> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev >> > wrote: >>> >>> In swift_retain/releas

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 1:18 PM, Greg Parker wrote: > > >> On Oct 13, 2016, at 10:46 AM, John McCall via swift-dev >> wrote: >> >>> On Oct 13, 2016, at 9:04 AM, Joe Groff via swift-dev >>> wrote: >>> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev wrote: In swift_

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and AArch64? Would this then mean any attempt to use Swift in kernel-space requires a distinct ABI? > On Oct 13, 2016, at 12:04 PM, Joe Groff via swift-dev > wrote: > > >> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift

Re: [swift-dev] Differences between Xcode official toolchains and tagged releases from repository

I can confirm that both issues were solved/bypassed by rebuilding the toolchain with assertions disabled. The provided examples compiled successfully, so we finally got the same result as the official 2.2 toolchain. Thank you again for the input! 2016-10-06 9:26 GMT+02:00 Xavier Jurado : > Thank

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 2:04 PM, Alexis wrote: > > Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and > AArch64? Would this then mean any attempt to use Swift in kernel-space > requires a distinct ABI? That's correct, but we'd likely already have to have a separate "ke

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 2:14 PM, Joe Groff via swift-dev > wrote: > > >> On Oct 13, 2016, at 2:04 PM, Alexis wrote: >> >> Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and >> AArch64? Would this then mean any attempt to use Swift in kernel-space >> requires a disti

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 5:14 PM, Joe Groff wrote: > > >> On Oct 13, 2016, at 2:04 PM, Alexis wrote: >> >> Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and >> AArch64? Would this then mean any attempt to use Swift in kernel-space >> requires a distinct ABI? > > Th

Re: [swift-dev] Dictionary Collision Resolution Guarantees

on Thu Oct 13 2016, Alexis wrote: > I’m currently cleaning up the docs on Dictionary to reflect the new indexing > model, and I stumbled > across the note that the following code should work assuming no reallocations > occur: > > // > // var (i, found) = d.find(k) // i is associated with d's

Re: [swift-dev] copy-on-write proposal

> On Oct 13, 2016, at 10:36 AM, Joe Groff wrote: > > >> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >> wrote: >> >> This is a proposal for representing copy-on-write buffers in SIL. Actually >> it’s still a draft for a proposal. It also heavily depends on how we move >> forwar

Re: [swift-dev] Dictionary Collision Resolution Guarantees

> On Oct 13, 2016, at 6:09 PM, Dave Abrahams via swift-dev > wrote: > > > on Thu Oct 13 2016, Alexis > wrote: > >> I’m currently cleaning up the docs on Dictionary to reflect the new indexing >> model, and I stumbled >> across the note that the following code

Re: [swift-dev] Dictionary Collision Resolution Guarantees

on Thu Oct 13 2016, Alexis wrote: >>> This is effectively assuming that the open-addressing scheme being >>> used is first-come-first-serve (FCFS). That is, any element being >>> inserted can *only* be inserted into vacant buckets, rather than >>> displacing existing elements. This is currently