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

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

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

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

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

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

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

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

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

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 >>

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

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 >>>

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