[Issue 2080] ICE(mangle.c) alias corrupts type inference of static variables
http://d.puremagic.com/issues/show_bug.cgi?id=2080 Don clugd...@yahoo.com.au changed: What|Removed |Added Summary|ICE(D1 only, mangle.c) |ICE(mangle.c) alias |alias corrupts type |corrupts type inference of |inference of static |static variables |variables | --- Comment #7 from Don clugd...@yahoo.com.au 2009-11-17 23:56:15 PST --- This applies to D2 as well. The D2 test case (below) generates: Error: forward reference to type int* on D1. On D2 it ICEs in mangle.c(81) fd fd-inferRetType Removing the alias fixes both the ICE and the forward reference error. Happens with typedef as well as alias. - alias int * any_old_alias; typeof(foo) bar = foo; const int * foo = null; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 --- Comment #4 from Tomas Lindquist Olsen to...@famolsen.dk 2009-11-18 03:40:17 PST --- Created an attachment (id=501) draft patch for fixing typesafe variadic and ctfe -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 --- Comment #6 from Tomas Lindquist Olsen to...@famolsen.dk 2009-11-18 03:48:50 PST --- I forgot to mention, the patch is against the latest dmd-1.x branch -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 --- Comment #5 from Tomas Lindquist Olsen to...@famolsen.dk 2009-11-18 03:46:13 PST --- I've attached a draft patch that replaces the typesafe variadic ast rewrites to something that works in any scope (and with ctfe). without the patch the following function: void foo(int[] arr ...) when called: foo(1,2,3); is rewritten as: int[3] _args; (_args[0] = 1, _args[1] = 2, _args[2] = 3, foo(_args[])); .. In global scope, this breaks, as you cannot assign to globals from ctfe, and in normal ctfe, breaks somehow as well. This patch changes the rewrite to: foo([1,2,3]); with each element being implicitly converted to the array element type. One downside is that codegen always allocates array literals on the heap, so it degrades performance a bit, but that needs to be fixed for http://d.puremagic.com/issues/show_bug.cgi?id=2356 as well (though it's probably a slightly different issue), and generally I'm not getting an impression that it's a concern (performance is secondary). In any case I added a new scopedLiteral field to ArrayLiteralExp so that codegen knows it's allowed to put the array on the stack if it wants to. Comments appreciated. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3115] Illegal optimization to unsigned right shift (only array)
http://d.puremagic.com/issues/show_bug.cgi?id=3115
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #1 from Don clugd...@yahoo.com.au 2009-11-18 05:18:30 PST ---
Here's a variation that doesn't even require the optimizer. In the code below,
= gets changed into =.
void main()
{
long[1] b = void;
b[0] = -1L;
b[0] = 2;
assert( (b[0]) == 0x3FFFL);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3522] New: ICE(cg87.c): variable*array[].
http://d.puremagic.com/issues/show_bug.cgi?id=3522
Summary: ICE(cg87.c): variable*array[].
Product: D
Version: 1.051
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-invalid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2009-11-18 07:13:26 PST ---
void main() {
double[] foo = [1.0, 2.0, 3.0];
double y = 2.0;
double[] c = y * foo[];
}
Internal error: backend\cg87.c 1363
Related to bug 2549.
Doesn't ICE with foo[]*y; generates bad code instead. Applies to both D1 and
D2.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3175] rejects templated ref return function
http://d.puremagic.com/issues/show_bug.cgi?id=3175
Luther Tychonievich la...@virginia.edu changed:
What|Removed |Added
CC||la...@virginia.edu
Severity|normal |trivial
--- Comment #1 from Luther Tychonievich la...@virginia.edu 2009-11-18
10:30:44 PST ---
This is only a problem with template parameter deduction:
ref int foo(int x)(int[x] v) if (x0) { return v[0]; }
foo!(2)([1,2]); // works
foo([1,2]); // gives only parameters or foreach... error message
It can be sidestepped by explicit template declaration:
template foo(int x) if (x0) {
ref int foo(int[x] v) { return v[0]; }
}
foo([1,2]); // works
While obviously not as nice as function template syntax, this workaround is not
difficult to read or write and contains full functionality.
I posit the error message is wrong either way: declarations.c line 908 should
read:
error(only function return types, parameters, and foreach declarations can
be ref);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3485] [tdpl] Double bug in typedef
http://d.puremagic.com/issues/show_bug.cgi?id=3485 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WONTFIX --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-11-18 10:53:01 PST --- Dropping typedef, so won't fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3486] [tdpl] Incorrect result type of binary operators applied to typedef'd types
http://d.puremagic.com/issues/show_bug.cgi?id=3486 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WONTFIX --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-11-18 10:54:09 PST --- Dropping typedef, so won't fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #17 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18 13:13:14 PST --- Hi, I today found remarkable bug: int k = -1; uint n = 7; assert(k n); Code above should execute without proble, but dmd it computing false as value of (kn) which absolutly nonsensical. casting n to int, resolves problem int k = -1; uint n = 7; assert(k cast(T)n); How it can be so long time not resolved? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1417] templated final const member can't be assigned in constructor from the const const argument
http://d.puremagic.com/issues/show_bug.cgi?id=1417 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18 13:27:44 PST --- Closing, as #1410 is already working correctly, and I think this also. Tested in v2.032. Probably working since 2.022. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1417] templated final const member can't be assigned in constructor from the const const argument
http://d.puremagic.com/issues/show_bug.cgi?id=1417 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added Depends on||1410 --- Comment #2 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18 13:28:20 PST --- Closing, as #1410 is already working correctly, and I think this also. Tested in v2.032. Probably working since 2.022. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3377] [tdpl] static foreach should be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=3377 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WONTFIX --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-11-18 13:38:27 PST --- Many problems have come up with the design of this, so will mark as won't implement until a thorough design is developed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3523] New: Fiber is not garbage collected properly
http://d.puremagic.com/issues/show_bug.cgi?id=3523
Summary: Fiber is not garbage collected properly
Product: D
Version: 2.032
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: bary...@smp.if.uj.edu.pl
--- Comment #0 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18
19:50:33 PST ---
Program below leaks memory.
import core.thread;
import std.stdio;
lass DerivedFiber : Fiber {
this() { super( run ); }
private void run() { Fiber.yield(); }
}
import core.memory : GC;
void main() {
foreach (i ; 1 .. 100) {
Fiber derived = new DerivedFiber();
derived.call();
GC.collect(); // doesn't work
}
}
Manual destruction of fiber works:
delete derived;
}
and then it doesn't leek.
chaning Fiber to scope also works (just like delete befor }
I know it have something to do with similarity of Fiber to thread, that Fiber
have own pool of root variables and own stack. But if Fiber is not running, and
it is not accesible by any reference from any Thread, then it is imposible to
resume its operation by call(), so also it's root variables and stack is not
avaible, so it can (and should?) be garbage collected.
I have code which creates few fibers, do milions call/yield operations, then
destroy fibers, and recreat new ones, for and essentially repeats. I was hoping
this would not leak memory. Unfortonetly it is.
I this is intended behaviour it should be documented somewhere.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3523] Fiber is not garbage collected properly
http://d.puremagic.com/issues/show_bug.cgi?id=3523 --- Comment #1 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18 19:56:25 PST --- If one will not call derived.call() (so leaving Fiber in TERM state, and never running it at all) it will be properly collected. Adding after derived.call(), a derived.reset() to make it back to TERM state, doesn't help (still it is not collected). Adding second derived.call(), after first one, will make collect() to work correctly. So i can assume it run() method terminates correctly and underlaying stack is destroyed, object is properly destructed in colletion phase. Essentially my problem is because my Fibers doesn't terminate at all they yield infinitly (saving some auxilary data in fields of some objects, so this data can be used outside of yield, essentiall in thread which called call), but i want to terminate them automatically (when they are not referenced by any thread or other Fiber) if needed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3524] New: Internal error: e2ir.c 725, after scoped error and processing inrevelant file.
http://d.puremagic.com/issues/show_bug.cgi?id=3524 Summary: Internal error: e2ir.c 725, after scoped error and processing inrevelant file. Product: D Version: 2.032 Platform: x86 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bary...@smp.if.uj.edu.pl --- Comment #0 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18 20:31:59 PST --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3524] Internal error: e2ir.c 725, after scoped error and processing inrevelant file.
http://d.puremagic.com/issues/show_bug.cgi?id=3524
--- Comment #1 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18
20:34:58 PST ---
file1.d:
--
class F(T, alias s) {
this() {
s.c += cast(T)2;
}
}
class A(T) {
T c;
}
void main() {
for (int Mi = 0; Mi 10; Mi++) {
scope a = new A!(float)();
scope f = new F!(float, a)();
}
}
--
file2.d:
--
class A {
void foo() {}
}
class B(alias G) {
void bar() {
G.foo();
}
}
void bzium(A g) {
new B!(g)();
}
--
$ dmd2 file1.d file2.d
file1.d(13): Error: variable bug35xx.main.a has scoped destruction, cannot
build closure
Internal error: e2ir.c 725
$
This is minimal test case I found in big program. actually removing file2.d
from command line helps (file1.d doesn't need anything from file2.d)
$ dmd2 file1.d
file1.d(13): Error: variable bug35xx.main.a has scoped destruction, cannot
build closure
$
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 918] Template order matter, version block change something with typedef, and another template bug.
http://d.puremagic.com/issues/show_bug.cgi?id=918
--- Comment #4 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18
21:25:29 PST ---
I recently retested this code in DMD 2.032:
a918.d:
-
import std.stdio;
typedef int num = 42;
version (A) {
void pow(alias b)() { writefln(alias %d, b); }
void pow(num b)() {writefln(num %d, b); }
void pow(int b)() {writefln(int %d, b); }
} else version (B) {
void pow(num b)() {writefln(num %d, b); }
void pow(alias b)() { writefln(alias %d, b); }
void pow(int b)() {writefln(int %d, b); }
} else version (C) {
void pow(num b)() {writefln(num %d, b); }
void pow(alias b)() { writefln(alias %d, b); }
} else {
static assert(false, Provide version);
}
void main() {
num wyk = 22;
writeln(calling num wyk=22?);
pow!(wyk)();
writeln(calling int=4?);
pow!(4)();
uint x = 333;
writeln(calling alias=x=333?);
pow!(x)();
}
-
It looks it behaves much better than original bug report:
--
bary...@sredniczarny:/tmp$ dmd2 -version=A -w a918.d ; ./a918
calling num wyk=22?
num -1077524476
calling int=4?
int 4
calling alias=x=333?
alias 333
bary...@sredniczarny:/tmp$ dmd2 -version=B -w a918.d ; ./a918
calling num wyk=22?
num -1081977116
calling int=4?
int 4
calling alias=x=333?
alias 333
bary...@sredniczarny:/tmp$ dmd2 -version=C -w a918.d ; ./a918
calling num wyk=22?
num -1076793804
calling int=4?
alias 4
calling alias=x=333?
alias 333
bary...@sredniczarny:/tmp$
-
We have the same behaviour regardles of version. In version C int properly uses
alias template. Order of templates doesn't metter. Removing or leaving
version blocks, doesn't change behaviour.
But here we also see regression. num is not passed correctly. Even after
removing version blocks, and leaving only B part. It also doesn't print any
0 or 42, or desired 22, but some random negative number.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1245] static foreach shouldn't define new scope and introduce new variables
http://d.puremagic.com/issues/show_bug.cgi?id=1245 --- Comment #6 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-11-18 21:41:58 PST --- I just tested this both my codes (from Description and Comment 5) in DMD 2.032, and they works correctly! (only switch isn't full optimal in asm, but this not conected with this bug). BCS's example with nop's is also not optimal, there are some operations on EBP register: movdword ptr -034h[EBP],1 nop movdword ptr -02Ch[EBP],2 nop movdword ptr -024h[EBP],3 nop movdword ptr -01Ch[EBP],5 nop movdword ptr -014h[EBP],6 nop movdword ptr -0Ch[EBP],7 nop I don't remember any changelog entry mentioning anything about foreach over tuples... Anyone want to enlighten me? :) And what about DMD 1.x? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
