Joakim writes:
> On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
>> On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
>>> That sounds like this issue I ran into with ARM EH:
>>>
>>> https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075
>>>
>>> I was a
Joakim writes:
> On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
>> Joakim writes:
>>
>>> On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
[...]
>>>
>>> Sounds good, submit a PR and let's get it in.
>>
>> Was planning to get that PR going then got side tracked by
Joakim writes:
> On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
>> Joakim writes:
>
>> The bug is a bad stack pointer which blows up when the last unittest
>> returns. This unittest has all the right conditions to generate
>> stack adjustments around some of the function calls that
On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
Joakim writes:
On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
[...]
Sounds good, submit a PR and let's get it in.
Was planning to get that PR going then got side tracked by a
more difficult ARM exeption unwindin
Joakim writes:
> On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
>> On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
>>> That sounds like this issue I ran into with ARM EH:
>>>
>>> https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075
>>>
>>> I was a
On Thursday, 31 December 2015 at 10:10:20 UTC, Jacob Carlborg
wrote:
On Wednesday, 30 December 2015 at 20:55:44 UTC, Dan Olson wrote:
I'm going to start with Plan B.1 though because LLVM does nice
optimizations for TLS.
What is Plan B.1?
--
/Jacob Carlborg
Getting it into llvm:
http://for
On Wednesday, 30 December 2015 at 20:55:44 UTC, Dan Olson wrote:
I'm going to start with Plan B.1 though because LLVM does nice
optimizations for TLS.
What is Plan B.1?
--
/Jacob Carlborg
On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
That sounds like this issue I ran into with ARM EH:
https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075
I was able to work around it by disabling th
On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
That sounds like this issue I ran into with ARM EH:
https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075
I was able to work around it by disabling the mentioned llvm
optimization pass:
https://gist.github.com/jo
On Wednesday, 30 December 2015 at 21:56:46 UTC, Dan Olson wrote:
Dan Olson writes:
A little progress report. More to come later when I get
something pushed to github.
I bought a returned Apple Watch yesterday at discount for
$223.99 US and tried to see how much of D would work on it
using
Dan Olson writes:
> A little progress report. More to come later when I get something pushed
> to github.
>
> I bought a returned Apple Watch yesterday at discount for $223.99 US and
> tried to see how much of D would work on it using my iOS fork of LDC.
> There were a few bumps, like dealing wit
Jacob Carlborg writes:
> On 2015-12-30 08:02, Dan Olson wrote:
>
>> I know some of it from hacking dyld for iOS, but not all. How does this
>> fit in with "Plan B.2"?
>
> If you need to figure out how TLS works, I can give you some help,
> that's all I'm saying :)
Oh, good. Always like help.
On 2015-12-30 08:02, Dan Olson wrote:
I know some of it from hacking dyld for iOS, but not all. How does this
fit in with "Plan B.2"?
If you need to figure out how TLS works, I can give you some help,
that's all I'm saying :)
--
/Jacob Carlborg
Jacob Carlborg writes:
> On 2015-12-28 20:02, Dan Olson wrote:
>
>> That is Plan B.2
>
> I'm working on implementing native TLS for OS X in DMD. I think I've
> figured out how everything works. Unless you already know how it
> works, I could tell you what I have figured out.
I know some of it fr
On 2015-12-28 20:02, Dan Olson wrote:
That is Plan B.2
I'm working on implementing native TLS for OS X in DMD. I think I've
figured out how everything works. Unless you already know how it works,
I could tell you what I have figured out.
--
/Jacob Carlborg
Jacob Carlborg writes:
>
> Would it be possible to bypass LLVM and do the thread local specific
> parts in LDC?
That is Plan B.2
Joakim writes:
>
> Thanks for the detailed answer; I'm sure this will now become the
> definitive answer online. I've gone googling for technical info only
> to sometimes be directed back to a post in these D forums. :)
Me too! Its very funny when that happens.
> Time to get emulated TLS for M
On 2015-12-28 09:45, Dan Olson wrote:
On implication of Apple requiring bitcode: if Apple is compiling the
bitcode with their clang or llc, then it means using a modifed LLVM like
I do to support thread-locals on watchOS, tvOS, or iOS is only good for
side loading. Probably going to have to wor
On Monday, 28 December 2015 at 08:45:46 UTC, Dan Olson wrote:
Joakim writes:
I don't understand how the bitcode requirement works on your
own device: I thought that was for an Apple-submitted app that
they then compiled to binary themselves? Do you have to go
through the same process even
Joakim writes:
>
> I don't understand how the bitcode requirement works on your own
> device: I thought that was for an Apple-submitted app that they then
> compiled to binary themselves? Do you have to go through the same
> process even for test apps, ie no sideloading? Or does the device
> its
On Monday, 28 December 2015 at 01:17:15 UTC, Dan Olson wrote:
A little progress report. More to come later when I get
something pushed to github.
I bought a returned Apple Watch yesterday at discount for
$223.99 US and tried to see how much of D would work on it
using my iOS fork of LDC. Ther
21 matches
Mail list logo