[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation
http://d.puremagic.com/issues/show_bug.cgi?id=7442
Jameson changed:
What|Removed |Added
CC||beatgam...@gmail.com
--- Comment #13 from Jameson 2013-06-06 23:21:22 PDT ---
(In reply to comment #12)
> (In reply to comment #0)
> > Test case:
> >
> >
> > import std.regex;
> > enum bug7442 = ctRegex!`\p{Letter}`;
> >
> >
> > Compile with `dmd -c test7442.d`. DMD will very quickly use up all system
> > memory. (I'll try to reduce the test case later.)
>
> Now this compiles for me in 2.063:
>
> import std.regex;
> enum bug7442 = ctRegex!`\p{Letter}`;
>
>
> Total time (ms): 11197.2
>
> And even both cases combined:
>
> import std.regex;
> enum bug7442 = ctRegex!`\p{Letter}`;
> void wcpx(string fn)
> {
> enum ctr = regex(r"\w+","g");
> }
>
>
> Total time (ms): 17443.3
>
> The latter takes around 600Mb virtual memory as measured on Win7 x64 with
> 32-bit executable. DMD lately has been tweaked to actually use up to 2GB of
> memory on win32.
>
> And the time is not all that bad.
>
> Should we close this as the root case of improving dmd's CTFE memory footprint
> is covered elsewhere? Just asking.
This now also compiles for me. I haven't tested the memory usage very well, but
it seems to only use about 400mb or so on my machine, which is completely
reasonable. Time is consistently around 3.5 seconds, so I'm happy.
Platform: Arch Linux x86_64.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10288] Direct lambda call and purity inference bug
http://d.puremagic.com/issues/show_bug.cgi?id=10288 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2013-06-06 22:26:34 PDT --- https://github.com/D-Programming-Language/dmd/pull/2143 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10288] New: Direct lambda call and purity inference bug
http://d.puremagic.com/issues/show_bug.cgi?id=10288
Summary: Direct lambda call and purity inference bug
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2013-06-06 22:16:56 PDT ---
In this code, foo and bar are essentially equivalent, but foo is not inferred
to pure.
T foo(T)(T x)
{
() @trusted { x += 10; } ();
return x;
}
T bar(T)(T x)
{
void lambda() @trusted nothrow { x += 10; }
lambda();
return x;
}
@safe pure nothrow void main()
{
assert(foo(10) == 20);
// -> Error: pure function 'main' cannot call impure function 'foo'
assert(bar(10) == 20);
// -> OK
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7848] pure and nothrow ignored on unittest blocks
http://d.puremagic.com/issues/show_bug.cgi?id=7848
Kenji Hara changed:
What|Removed |Added
Keywords||pull
Version|unspecified |D2
Summary|pure ignored on unittest|pure and nothrow ignored on
|blocks |unittest blocks
--- Comment #1 from Kenji Hara 2013-06-06 21:04:05 PDT ---
Same bug exists for nothrow unittest
void func() {}
nothrow unittest { func(); }
Compiler fix:
https://github.com/D-Programming-Language/dmd/pull/2142
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8651] Slice op Slice throws exceptions (not errors), and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=8651 Kenji Hara changed: What|Removed |Added Keywords||pull Version|unspecified |D2 --- Comment #9 from Kenji Hara 2013-06-06 20:46:04 PDT --- A while ago, built-in array-op implementations has been changed to @trusted nothrow by the druntime fix: https://github.com/D-Programming-Language/druntime/pull/306 But, as yebblies said in comment #6, this still needs compiler fix. I opened a new pull request for the compiler fix. https://github.com/D-Programming-Language/dmd/pull/2141 (In reply to comment #6) > (In reply to comment #5) > A lot of druntime functions should probably have D linkage to prevent mistakes > like this. >From 2.063, we can use pragma(mangle). Using it could add D linkages to the druntime functions with hiding internal module packages. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6311] Some array ops aren't nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=6311 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kenji Hara 2013-06-06 19:10:05 PDT --- *** This issue has been marked as a duplicate of issue 8651 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8651] Slice op Slice throws exceptions (not errors), and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=8651 Kenji Hara changed: What|Removed |Added CC||simend...@gmail.com --- Comment #7 from Kenji Hara 2013-06-06 19:10:06 PDT --- *** Issue 6311 has been marked as a duplicate of this issue. *** --- Comment #8 from Kenji Hara 2013-06-06 19:10:07 PDT --- *** Issue 9933 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9933] Vector operations cannot be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=9933 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Kenji Hara 2013-06-06 19:10:07 PDT --- *** This issue has been marked as a duplicate of issue 8651 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8651] Slice op Slice throws exceptions (not errors), and nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=8651 Kenji Hara changed: What|Removed |Added CC||simend...@gmail.com --- Comment #7 from Kenji Hara 2013-06-06 19:10:06 PDT --- *** Issue 6311 has been marked as a duplicate of this issue. *** --- Comment #8 from Kenji Hara 2013-06-06 19:10:07 PDT --- *** Issue 9933 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10287] std.random.uniform is very slow with dmd
http://d.puremagic.com/issues/show_bug.cgi?id=10287
--- Comment #1 from bearophile_h...@eml.cc 2013-06-06 17:54:27 PDT ---
This alternative version of the program is handy to produce a more readable asm
output:
import core.stdc.stdio: printf;
import core.stdc.stdlib: atoi;
import std.random: Xorshift, uniform;
uint randomSum(in uint n, Xorshift rng) {
uint total = 0;
for (uint i = 0; i < n; i++)
total += uniform(0, 10, rng);
return total;
}
void main(in string[] args) {
immutable uint N = (args.length == 2) ?
atoi((args[1] ~ '\0').ptr) :
1_000;
auto rng = Xorshift(0);
immutable result = randomSum(N, rng);
printf("%u\n", result);
}
LDC2 produces for the randomSum() function (the inner loop is 26 instructions
long, with no call instructions):
__D4temp9randomSumFxkS3std6random38__T14XorshiftEngineTkVi128Vi11Vi8Vi19Z14XorshiftEngineZk:
pushl %ebp
pushl %ebx
pushl %edi
pushl %esi
pushl %eax
xorl%eax, %eax
cmpl$0, 40(%esp)
je LBB0_5
leal24(%esp), %ecx
movl8(%ecx), %esi
movl(%ecx), %eax
movl4(%ecx), %edx
movl12(%ecx), %ebp
xorl%ebx, %ebx
movl$0, (%esp)
.align 16, 0x90
LBB0_2:
movl%esi, %edi
movl%edx, %ecx
movl%ebp, %esi
movl%eax, %ebp
shll$11, %ebp
xorl%eax, %ebp
movl%esi, %eax
shrl$19, %eax
xorl%esi, %eax
xorl%ebp, %eax
shrl$8, %ebp
xorl%eax, %ebp
cmpl$-7, %esi
movl%edi, %edx
movl%ecx, %eax
ja LBB0_2
movl%esi, %eax
movl$671088641, %edx
mull%edx
shrl$26, %edx
addl%edx, (%esp)
incl%ebx
cmpl40(%esp), %ebx
movl%edi, %edx
movl%ecx, %eax
jne LBB0_2
leal24(%esp), %eax
movl%ebp, 12(%eax)
movl%ecx, (%eax)
movl%edi, 4(%eax)
movl%esi, 8(%eax)
movl(%esp), %eax
LBB0_5:
addl$4, %esp
popl%esi
popl%edi
popl%ebx
popl%ebp
ret $20
Maybe it's also a matter of missed inlining.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10287] New: std.random.uniform is very slow with dmd
http://d.puremagic.com/issues/show_bug.cgi?id=10287
Summary: std.random.uniform is very slow with dmd
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-06-06 17:39:54 PDT ---
This program runs about 6 times faster compiled with ldc2 compared to dmd (I
run it with 1 command line argument):
import core.stdc.stdio, std.random, std.conv;
void main(in string[] args) {
immutable uint N = (args.length == 2) ?
args[1].to!uint :
1_000;
auto rng = Xorshift(0);
uint total = 0;
for (uint i = 0; i < N; i++)
total += uniform(0, 10, rng);
printf("%u\n", total);
}
If I replace this line:
total += uniform(0, 10, rng);
with:
total += rng.front; rng.popFront;
Then the code compiled with ldc2 is only about 30% faster.
dmd 2.064alpha, -O -release -inline -noboundscheck.
Ldc2 V. 0.11.0, based on DMD v2.062 and LLVM 3.3svn, -O5 -release
-profile-verifier-noassert.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10286] New: Better optimization for struct constructors?
http://d.puremagic.com/issues/show_bug.cgi?id=10286
Summary: Better optimization for struct constructors?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-06-06 17:35:31 PDT ---
Created an attachment (id=1220)
A small raytracer
This is a benchmark program that shows the difference in run-time between a
struct with and without explicit constructor:
import core.stdc.stdio: printf;
import core.stdc.stdlib: atoi;
struct V3a {
double x, y, z;
this(in double x_, in double y_, in double z_)
pure nothrow {
this.x = x_;
this.y = y_;
this.z = z_;
}
}
struct V3b {
double x, y, z;
}
double spam1(in uint N) pure nothrow {
double total = 0.0;
for (uint i = 0; i < N; i++) {
immutable v = V3a(i, i, i);
total += v.y;
}
return total;
}
double spam2(in uint N) pure nothrow {
double total = 0.0;
for (uint i = 0; i < N; i++) {
immutable v = V3b(i, i, i);
total += v.y;
}
return total;
}
void main(in string[] args) {
immutable uint N = (args.length >= 2) ?
atoi((args[1] ~ '\0').ptr) :
1_000;
if (args.length >= 3 && args[2] == "1")
printf("%f\n", spam1(N));
else
printf("%f\n", spam2(N));
}
If you run it you see a performance difference between creating V3a and V3b.
This is the asm generated by dmd (dmd 2.064alpha, -O -release -inline
-noboundscheck):
_D5test25spam1FNaNbxkZd:
subESP,030h
movEDX,EAX
xorECX,ECX
pushEBX
testEDX,EDX
pushESI
pushEDI
movdword ptr 034h[ESP],0
movdword ptr 038h[ESP],0
jeL52
L1E:movESI,offset FLAT:_D5test23V3a6__initZ
leaEDI,01Ch[ESP]
movsd
movsd
movsd
movsd
movsd
movsd
xorEBX,EBX
movEAX,ECX
mov0Ch[ESP],ECX
incECX
cmpECX,EDX
mov010h[ESP],EBX
fildlong64 ptr 0Ch[ESP]
fstpqword ptr 024h[ESP]
fldqword ptr 024h[ESP]
faddqword ptr 034h[ESP]
fstpqword ptr 034h[ESP]
jbL1E
L52:fldqword ptr 034h[ESP]
popEDI
popESI
popEBX
addESP,030h
ret
_D5test25spam2FNaNbxkZd:
subESP,030h
movEDX,EAX
xorECX,ECX
pushEBX
testEDX,EDX
movdword ptr 02Ch[ESP],0
movdword ptr 030h[ESP],0
jeL63
L1C:mov4[ESP],ECX
xorEBX,EBX
movEAX,ECX
mov8[ESP],EBX
incECX
cmpECX,EDX
fildlong64 ptr 4[ESP]
fstpqword ptr 014h[ESP]
mov4[ESP],EAX
mov8[ESP],EBX
fildlong64 ptr 4[ESP]
fstpqword ptr 01Ch[ESP]
mov4[ESP],EAX
mov8[ESP],EBX
fildlong64 ptr 4[ESP]
fldqword ptr 01Ch[ESP]
fxchST1
fstpqword ptr 024h[ESP]
faddqword ptr 02Ch[ESP]
fstpqword ptr 02Ch[ESP]
jbL1C
L63:fldqword ptr 02Ch[ESP]
popEBX
addESP,030h
ret
One visible difference is that block of movsd:
movsd
movsd
movsd
movsd
movsd
movsd
Compiling with ldc2 (V. 0.11.0, based on DMD v2.062 and LLVM 3.3svn, -O5
-release -profile-verifier-noassert):
__D5test25spam1FNaNbxkZd:
pushl%ebp
movl%esp, %ebp
andl$-8, %esp
subl$8, %esp
xorps%xmm0, %xmm0
testl%eax, %eax
jeLBB1_1
movsdLCPI1_0, %xmm2
xorps%xmm1, %xmm1
.align16, 0x90
LBB1_3:
addsd%xmm0, %xmm1
addsd%xmm2, %xmm0
decl%eax
jneLBB1_3
jmpLBB1_4
LBB1_1:
xorps%xmm1, %xmm1
LBB1_4:
movsd%xmm1, (%esp)
fldl(%esp)
movl%ebp, %esp
popl%ebp
ret
__D5test25spam2FNaNbxkZd:
pushl%ebp
movl%esp, %ebp
andl$-8, %esp
subl$8, %esp
xorps%xmm0, %xmm0
testl%eax, %eax
jeLBB2_3
movsdLCPI2_0, %xmm1
xorps%xmm2, %xmm2
.align16, 0x90
LBB2_2:
addsd%xmm2, %xmm0
addsd%xmm1, %xmm2
decl%eax
jneLBB2_2
LBB2_3:
movsd%xmm0, (%esp)
fldl(%esp)
movl%ebp, %esp
popl%ebp
ret
You see that ldc2 compiles the two functions at the same way, and indeed their
run-time is the same.
But the problem is not limited to DMD. As soon as your program becomes a little
longer than such tiny benchm
[Issue 10229] RDMD: --compiler flag doesn't work properly when not adding .exe on win32
http://d.puremagic.com/issues/show_bug.cgi?id=10229 Nils changed: What|Removed |Added CC||nilsboss...@googlemail.com --- Comment #1 from Nils 2013-06-06 16:15:25 PDT --- Could your rdmd be out of date? Sounds like this should have fixed the issue: https://github.com/D-Programming-Language/tools/commit/d259d8dc1ebf7376b20a69461ad87e578611480f -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10229] RDMD: --compiler flag doesn't work properly when not adding .exe on win32
http://d.puremagic.com/issues/show_bug.cgi?id=10229 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #2 from Andrej Mitrovic 2013-06-06 16:18:24 PDT --- (In reply to comment #1) > Could your rdmd be out of date? Sounds like this should have fixed the issue: > https://github.com/D-Programming-Language/tools/commit/d259d8dc1ebf7376b20a69461ad87e578611480f Thanks, it does! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10210] GDB might trash EAX when stepping into a PLT call
http://d.puremagic.com/issues/show_bug.cgi?id=10210
Martin Nowak changed:
What|Removed |Added
Keywords|wrong-code |
Summary|calling through PLT trashes |GDB might trash EAX when
|EAX |stepping into a PLT call
Severity|critical|minor
--- Comment #3 from Martin Nowak 2013-06-06 15:14:37 PDT ---
cat > bug.d << CODE
import lib;
void main()
{
int val;
printf("%p\n", &val);
deref(&val) == 0 || assert(0);
}
CODE
cat > lib.d << CODE
extern(C) int printf(const char*, ...);
int deref(int* p)
{
printf("%p\n", p);
return *p;
}
CODE
dmd -g -m32 -fPIC -shared lib.d -ofliblib.so
dmd -g -m32 -fPIC bug.d -L-L. -L-llib -L-rpath=.
./bug
Oh, the above code actually works. It's not the PLT stub but the attached
debugger (gdb-7.5.1) that trashes EAX. It only happens when stepping into a
function called via PLT and I can only reproduce with emacs-GUD, probably
because of some automatic variable update.
It also means there is another reason why phobos unittests crash on X86 :(.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10285] New: Enum grammar documentation is incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=10285 Summary: Enum grammar documentation is incorrect Product: D Version: D1 & D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: brian-sch...@cox.net --- Comment #0 from brian-sch...@cox.net 2013-06-06 14:28:06 PDT --- The documentation for EnumMember states that it can consist of "type '=' assignExpression", but comments in the the compiler source code indicate that this should actually be "type Identifer '=' assignExpression". Another issue is that the grammar does not disallow the "type Identifier '=' assignExpression" syntax if the enum has a name or base type specified, but DMD's parser does. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10210] calling through PLT trashes EAX
http://d.puremagic.com/issues/show_bug.cgi?id=10210 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2013-06-06 14:10:46 PDT --- An example would be nice, please! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570 --- Comment #38 from David Nadlinger 2013-06-06 13:20:26 PDT --- I don't think the three byte struct issue (see linked bug) has been fixed yet, but I haven't checked in a while. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #37 from Martin Nowak 2013-06-06 13:18:21 PDT --- Is this finally finished? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10274] DMD 2.063 produces broken binaries
http://d.puremagic.com/issues/show_bug.cgi?id=10274 --- Comment #3 from Jerry Quinn 2013-06-06 08:44:06 PDT --- (In reply to comment #1) > Can you please post the output of "ldd -r executable"? jlquinn@wyvern:~/re/test$ ldd -r junk linux-vdso.so.1 => (0x7fff32dff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f63b1ae3000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f63b18db000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f63b151b000) /lib64/ld-linux-x86-64.so.2 (0x7f63b1d21000) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10274] DMD 2.063 produces broken binaries
http://d.puremagic.com/issues/show_bug.cgi?id=10274 --- Comment #4 from Jerry Quinn 2013-06-06 08:44:57 PDT --- Detailed compilation output: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 config/home/jlquinn/dmd2/linux/bin64/dmd.conf parse junk importall junk importobject (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/object.di) importstd.stdio (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/stdio.d) importcore.stdc.stdio (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdio.d) importcore.stdc.config (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/config.d) importcore.stdc.stddef (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stddef.d) importcore.stdc.stdarg (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdarg.d) importstd.string (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/string.d) importcore.exception (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/exception.d) importcore.vararg (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/vararg.d) importcore.stdc.stdlib (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdlib.d) importcore.stdc.string (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/string.d) importstd.algorithm (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/algorithm.d) importstd.c.string (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/c/string.d) importcore.bitop (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/bitop.d) importstd.array (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/array.d) importcore.memory (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/memory.d) importstd.ascii (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/ascii.d) importstd.conv (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/conv.d) importstd.math (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/math.d) importcore.stdc.math (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/math.d) importstd.range (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/range.d) importstd.exception (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/exception.d) importstd.traits (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/traits.d) importstd.typetuple (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/typetuple.d) importstd.typecons (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/typecons.d) importstd.format (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/format.d) importstd.bitmanip (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/bitmanip.d) importstd.system (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/system.d) importstd.functional (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/functional.d) importstd.utf (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/utf.d) importcore.stdc.errno (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/errno.d) importstd.uni (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/uni.d) importstd.container (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/container.d) importstd.random (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/random.d) importstd.c.time (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/c/time.d) importcore.stdc.time (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/time.d) importstd.numeric (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/numeric.d) importstd.c.stdlib (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/c/stdlib.d) importstd.complex (/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/complex.d) importcore.thread (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/thread.di) importcore.time (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/time.d) importcore.sys.posix.time (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/sys/posix/time.d) importcore.sys.posix.config (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/sys/posix/config.d) importcore.sys.posix.sys.types (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/sys/posix/sys/types.d) importcore.stdc.stdint (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdint.d) importcore.stdc.signal (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/signal.d) importcore.stdc.wchar_ (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/wchar_.d) importcore.sys.posix.signal (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/sys/posix/signal.d) i
[Issue 10284] New: dlang.org/phobos/index.html needs redesign
http://d.puremagic.com/issues/show_bug.cgi?id=10284 Summary: dlang.org/phobos/index.html needs redesign Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: peter.alexander...@gmail.com --- Comment #0 from Peter Alexander 2013-06-06 07:18:29 PDT --- The Phobos main page is in need of a complete overhall. The library list is out of date by several years, and the bulk of the page is taken up by a philosophy statement, which 99% of people won't care about (they just want a library reference). http://dlang.org/phobos/index.html I would suggest that the philosophy statement is either moved to another page, or moved to the bottom of the page. Also, the library list in the navbar on the left should be moved onto the main part of the page, possibly in multiple columns so that everything fits on one screen. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10283] New: ICE(interpret.c): passing struct with failed initalizer to CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10283
Summary: ICE(interpret.c): passing struct with failed
initalizer to CTFE
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2013-06-06 05:38:37 PDT ---
Repy blah(Repy xxx) { return xxx; }
Repy repy = blah(Repy());
struct Repy
{
string source = 7;
}
---
bug.d(7): Error: cannot implicitly convert expression (7) of type int to string
CTFE: ErrorExp in bug.d(3)
dmd: interpret.c:310: static int CompiledCtfeFunction::walkAllVars(Expression*,
void*): Assertion `0' failed.
Aborted
This is a failure of error propagation.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 199] Label causes scope to collapse into parent
http://d.puremagic.com/issues/show_bug.cgi?id=199 --- Comment #32 from Nick Treleaven 2013-06-06 05:20:21 PDT --- (In reply to comment #31) > >> The (imo correct) path is that the NoScopeStatment should still > >> provide no scope, but emit a deprecated message if anything > >> declared in the scope is used. > > If you're going to go as far as that, why not emit a deprecation message if > any > declarations appear in it at all? That sounds easier to implement, and IMO is a bit better than deprecating having a non-empty block after a label. We would also need to deprecate having scope() statements in a labelled block. Bug 827 would also need a solution. comment #30: > I understand your position, but deprecation really implies that something WILL > be removed, and usage NEEDS to stop. Having something permanently deprecated > is > not tenable: there is a compile mode that makes deprecated calls errors, and > here, it is not an error. If a user has chosen to enable deprecation errors, that is their problem IMO. By default the code would not break. Note: GTK2 kept its deprecated symbols until GTK3, rather than scheduling removal at a certain date. Anyway, a limited period of deprecation rather than just changing behaviour might be a good compromise. Perhaps 2 years? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10282] New: Refused assignment of vector op result to const array
http://d.puremagic.com/issues/show_bug.cgi?id=10282
Summary: Refused assignment of vector op result to const array
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic, rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-06-06 05:04:57 PDT ---
struct Foo {
double[1] x;
}
void main() {
Foo[] foos;
foreach (f; foos)
const double[1] a = f.x[] - f.x[];
}
DMD 2.064alpha gives a not meaningful error message with no line number:
Error: cannot modify const expression p2[p]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10281] New: pure methods can use shared fields
http://d.puremagic.com/issues/show_bug.cgi?id=10281
Summary: pure methods can use shared fields
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: marco.le...@gmx.de
--- Comment #0 from Marco Leise 2013-06-06 04:23:00 PDT ---
Pure doesn't consider shared variables accessed by other threads.
In this sense m_fill is like a global variable even though local to the
circular buffer struct and the implicit this parameter.
struct SCircularBuffer
{
shared ℕ m_fill = 0;
@property ℕ availableBytesForReading() const pure nothrow
{
return atomicLoad(m_fill);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10273] ICE(ctfeexpr.c): using CTFE after error in struct default values
http://d.puremagic.com/issues/show_bug.cgi?id=10273 Henning Pohl changed: What|Removed |Added Status|NEW |RESOLVED CC||henn...@still-hidden.de Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10280] New: CTFE: Circular variable initializers should be detected properly
http://d.puremagic.com/issues/show_bug.cgi?id=10280
Summary: CTFE: Circular variable initializers should be
detected properly
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2013-06-06 00:13:01 PDT ---
Currently, when the initializer for a variable accesses that variable in CTFE,
it's only indirectly detected via the 'recursion limit exceeded' message.
It should be detected directly.
---
const int q = foo();
int foo() { return q; }
---
rr.d(3): Error: function rr.foo CTFE recursion limit exceeded
rr.d(1):called from here: foo()
rr.d(3):1000 recursive calls to function foo
rr.d(3):while evaluating q.init
rr.d(1):called from here: foo()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 Benjamin Thaut changed: What|Removed |Added CC||c...@benjamin-thaut.de --- Comment #21 from Benjamin Thaut 2013-06-06 00:04:57 PDT --- Awesome, thanks for fixing this. This was my number 1 most annoying bug in D. Because when not using a GC the old behavior always leaked memory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10279] New: Calling a typesafe variadic @trusted function from an @safe function results in an error.
http://d.puremagic.com/issues/show_bug.cgi?id=10279
Summary: Calling a typesafe variadic @trusted function from an
@safe function results in an error.
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tcdknut...@gmail.com
--- Comment #0 from Dylan 2013-06-06 00:03:13 PDT ---
The following code will not compile, however it seems like it's valid:
ulong foo(string[] strs...) @trusted {
return strs.length;
}
void bar() @safe {
foo("asdf");
}
void main() {}
The error "Error: variable maybebug.bar.__arrayArg4 void initializers for
pointers not allowed in safe functions" will be emitted.
DMD version: 2.064, Windows x64
and DMD version 2.063 on Linux x64
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
