http://bugzilla.gdcproject.org/show_bug.cgi?id=202
--- Comment #3 from Sebastien Alaiwan ---
I was thinking too long symbol names generated by gdc could cause a memory
corruption in the linker.
However, I was able to reproduce the exact same symptoms if I try to link the
resulting object file wi
http://bugzilla.gdcproject.org/show_bug.cgi?id=148
--- Comment #3 from Iain Buclaw ---
For resolving any kind of symbol to string via CTFE, I'd suggest we defer
running semantic analysis until the second pass.
See for instance:
https://github.com/D-Programming-Language/dmd/pull/5302/files#diff-0
On Wednesday, 10 February 2016 at 17:03:35 UTC, Dan Olson wrote:
I noticed that even thumb-1 has different instruction set based
on arm architecture.
Yes. I did a little more research into this, as it peeked my
curiosity. Take a look at this Wikipedia entry
(https://en.wikipedia.org/wiki/
Mike writes:
> I think to do this properly with ARM you need to consider the ARM
> architecture (ARMv6, ARMv7, ARMv7-A, ARMv7-M, etc..) AND the
> instruction set (ARM or ARM_Thumb). I read it somewhere, but I'm
> having trouble finding it again.
>
> Anyway, used in conjunction with the architectu
http://bugzilla.gdcproject.org/show_bug.cgi?id=202
--- Comment #2 from Sebastien Alaiwan ---
My version:
gdc (Debian 5.3.1-7) 5.3.1 20160121
--
You are receiving this mail because:
You are watching all bug changes.
http://bugzilla.gdcproject.org/show_bug.cgi?id=202
--- Comment #1 from Sebastien Alaiwan ---
It seems to occur when std.conv and byLine are used in the same module.
Here's another example which causes link issues:
// cantlink.d
int main()
{
import std.stdio;
stdin.byLine().front();
return
