[Issue 3716] Regression (D2 only) with multi dimensional array literals
http://d.puremagic.com/issues/show_bug.cgi?id=3716
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Don clugd...@yahoo.com.au 2010-06-24 00:00:18 PDT ---
This was caused by the change in 2.037:
The type inferred from an ArrayLiteral is now a dynamic array, not a static
one.
typeMerge() in cast.c, needed to be modified in response, since [[]] is now of
type void[][] instead of void[][0]
I've patched this with a more general test for void array literals.
I'm not terribly happy with the patch, the dimensionality check seems
unnecessarily complicated.
// TEST CASES
void bug3716() {
auto k1 = true ? [1,2] : []; // OK
auto k2 = true ? [[1,2]] : [[]];
auto k3 = true ? [] : [[1,2]];
auto k4 = true ? [[[]]] : [[[1,2]]];
auto k5 = true ? [[[1,2]]] : [[[]]];
auto k6 = true ? [] : [[[]]];
static assert(!is(typeof(true ? [[[]]] : [[1,2]]))); // Must fail
}
--
Index: cast.c
===
--- cast.c(revision 557)
+++ cast.c(working copy)
@@ -1499,6 +1499,30 @@
}
/**
+ * Return true if e is an empty array literal with dimensionality
+ * equal to or less than type of other array.
+ * [], [[]], [[[]]], etc.
+ */
+bool isVoidArrayLiteral(Expression *e, Type *other)
+{
+while (e-op == TOKarrayliteral e-type-ty == Tarray
+ (((ArrayLiteralExp *)e)-elements-dim == 1))
+{
+e = (Expression *)((ArrayLiteralExp *)e)-elements-data[0];
+if (other-ty == Tsarray || other-ty == Tarray)
+other = other-nextOf();
+else
+return false;
+}
+if (other-ty != Tsarray other-ty != Tarray)
+return false;
+Type *t = e-type;
+return (e-op == TOKarrayliteral t-ty == Tarray
+t-nextOf()-ty == Tvoid
+((ArrayLiteralExp *)e)-elements-dim == 0);
+}
+
+/**
* Combine types.
* Output:
* *pt merged type, if *pt is not NULL
@@ -1616,7 +1640,7 @@
else if ((t1-ty == Tsarray || t1-ty == Tarray)
(e2-op == TOKnull t2-ty == Tpointer t2-nextOf()-ty ==
Tvoid ||
e2-op == TOKarrayliteral t2-ty == Tsarray
t2-nextOf()-ty == Tvoid ((TypeSArray *)t2)-dim-toInteger() == 0 ||
- e2-op == TOKarrayliteral t2-ty == Tarray
t2-nextOf()-ty == Tvoid ((ArrayLiteralExp *)e2)-elements-dim == 0)
+ isVoidArrayLiteral(e2, t1))
)
{ /* (T[n] op void*) = T[]
* (T[] op void*) = T[]
@@ -1630,7 +1654,7 @@
else if ((t2-ty == Tsarray || t2-ty == Tarray)
(e1-op == TOKnull t1-ty == Tpointer t1-nextOf()-ty ==
Tvoid ||
e1-op == TOKarrayliteral t1-ty == Tsarray
t1-nextOf()-ty == Tvoid ((TypeSArray *)t1)-dim-toInteger() == 0 ||
- e1-op == TOKarrayliteral t1-ty == Tarray
t1-nextOf()-ty == Tvoid ((ArrayLiteralExp *)e1)-elements-dim == 0)
+ isVoidArrayLiteral(e1, t2))
)
{ /* (void* op T[n]) = T[]
* (void* op T[]) = T[]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4366] ICE(mtype.c) constrained template pure function with array/pointer parameter
http://d.puremagic.com/issues/show_bug.cgi?id=4366 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2010-06-24 00:29:57 PDT --- The ICE occurs during the call in these lines in template.c, makeParamNamesVisibleInConstraint(). if (fd-type fd-isPure()) vtype = vtype-addMod(MODconst); Removing those lines allows the code to compile, and the DMD test suite still passes. So why are they there? I wrote the makeParamNamesVisibleInConstraint() function, but I just copied those lines from func.c, where interestingly they don't cause any problems. Still need to work out what the difference is. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3461] Unittests and assert don't work at all (Mac D1 only)
http://d.puremagic.com/issues/show_bug.cgi?id=3461 --- Comment #1 from Don clugd...@yahoo.com.au 2010-06-24 00:43:21 PDT --- Can somebody please check if this bug is still valid? It's hard to believe that anyone could be using DMD1 on OSX if this still applies. If it still fails, is it really a regression? Was there ever a version of D1 where it worked? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4380] New: Poor optimisation of x*x, where x is real
http://d.puremagic.com/issues/show_bug.cgi?id=4380
Summary: Poor optimisation of x*x, where x is real
Product: D
Version: D1 D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: performance
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-06-24 03:02:44 PDT ---
// TEST CASE
int main(string[] args) {
real x = args.length == 2 ? 6.0 : 4.0; // just to defeat the optimiser
real y = x*x;
return cast(int)y;
}
With double x, produces:
fstpqword ptr [ESP] // store x
fld qword ptr [ESP]
fmulST,ST(0)
Does the same for float x.
With real x, produces
fstptbyte ptr [ESP] // store x
fld tbyte ptr [ESP]
fld tbyte ptr [ESP] // Why is it loading this twice???
fmulp ST(1),ST
The last two lines should just be fmul ST, ST(0)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4381] New: Length attribute for std.typecons.Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=4381
Summary: Length attribute for std.typecons.Tuple
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-06-24 04:01:13 PDT ---
This little program (that doesn't work with DMD v2.047) shows why a (constant)
length attribute can be quite useful for tuples:
import std.typecons: Tuple;
import std.typetuple: TypeTuple;
template Iota(int start, int stop) { // 2 argument version
static if (stop = start)
alias TypeTuple!() Iota;
else
alias TypeTuple!(Iota!(start, stop-1), stop-1) Iota;
}
void main() {
alias Tuple!(char, int, int) Unit;
auto u1 = Unit('x', 1, 2);
auto u2 = Unit('y', 10, 20);
foreach (i; Iota!(1, Unit.length))
u1.field[i] += u2.field[i];
}
In that program u1.length (and maybe Unit.length too) needs to be 3.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4382] New: Same syntax to access items of Proxy and Tuple and more
http://d.puremagic.com/issues/show_bug.cgi?id=4382 Summary: Same syntax to access items of Proxy and Tuple and more Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-06-24 04:10:44 PDT --- std.range.Proxy uses .at!(i) to access items, while std.typecons.Tuple uses .field[i] to access items. Is it possible for them to use the same syntaxname to access single items? (A more general comment about the situation: Zip yields Proxies, this is probably done for efficiency, but makes Zip itself less standard. If Zip yields Tuples instead this allows people to use it in a more standard way. To maximize interoperability D2 needs to standardize more its usage of Tuples. A possibility is to move the Proxy struct to std.typecons and consider both Tuple and Proxy the two standard ways to create tuples in D2.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #4 from nfx...@gmail.com 2010-06-24 05:32:46 PDT --- How is this supposed to work correctly? Hidden allocation of an array on the heap every time a struct of that type is constructed? Disallow initializing non-immutable, non-static array members? This is not a bug, it's just D _works_. If you assign an array to a global variable, of course it's shared by everyone. Dynamic arrays are reference types. The variable being a struct initializer doesn't change this. I think this really should be marked as INVALID. (I'm sure it's somewhat confusing for programmers coming from C++ or Java. Especially in Java, the array would be reconstructed every time the constructor is called. Stuff like this _never_ happens in D: structs are always initialized by what boils down to a memcpy.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4379] DMD chokes on large nested loop over tuple.
http://d.puremagic.com/issues/show_bug.cgi?id=4379 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com Severity|normal |regression --- Comment #2 from nfx...@gmail.com 2010-06-24 05:35:43 PDT --- Can't reproduce it with 2.046. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4383] New: Optimizer doesn't keep floating point values on the stack if used more than once
http://d.puremagic.com/issues/show_bug.cgi?id=4383
Summary: Optimizer doesn't keep floating point values on the
stack if used more than once
Product: D
Version: D1 D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: performance
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-06-24 05:51:03 PDT ---
Consider this example code.
int main(string[] args) {
real x = args.length == 2 ? 6.0 : 4.0; // just to defeat the optimiser
//real y = x * 2; // (1)
real y = x + x;// (2)
return cast(int)y;
}
--
After the first line, x is in ST(0). Here's how the compiler calculates y.
Case (1) y = x * 2
faddST(0),ST
Case (2) y = x + x
fstptbyte ptr [ESP] // store x
fld tbyte ptr [ESP] // load x
fld tbyte ptr [ESP] // load x again
faddp ST(1),ST
It's very interesting that in the first case, the compiler is able to eliminate
the store of x, yet it doesn't do it in the second case.
The compiler's inability to do this is the primary cause of DMD's poor floating
point performance.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4383] Optimizer doesn't keep floating point values on the stack if used more than once
http://d.puremagic.com/issues/show_bug.cgi?id=4383 Don clugd...@yahoo.com.au changed: What|Removed |Added Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4380] Poor optimisation of x*x, where x is real
http://d.puremagic.com/issues/show_bug.cgi?id=4380 Don clugd...@yahoo.com.au changed: What|Removed |Added Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4383] Optimizer doesn't keep floating point values on the stack if used more than once
http://d.puremagic.com/issues/show_bug.cgi?id=4383 BCS shro8...@vandals.uidaho.edu changed: What|Removed |Added CC||shro8...@vandals.uidaho.edu --- Comment #1 from BCS shro8...@vandals.uidaho.edu 2010-06-24 06:59:59 PDT --- Sounds like a prime case for a keyhole optimization. Does DMD have the infrastructure in place to do that? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4384] New: Cyclic dependency check for modules is broken
http://d.puremagic.com/issues/show_bug.cgi?id=4384
Summary: Cyclic dependency check for modules is broken
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2010-06-24
07:07:15 PDT ---
Example code that compiles/runs but results in undetermined behavior:
mod1.d:
public import mod2;
public import mod3;
import std.stdio;
void main()
{
writefln(x = %d, y = %d, x, y);
}
mod2.d:
import mod1;
__gshared int x = 1;
static this()
{
x = y;
}
mod3.d:
import mod1;
__gshared int y = 2;
static this()
{
y = x;
}
The problem stems from the code assuming that an import with no static
ctors/dtors is finished after the first time it is encountered. This is done
because trivial cycles are allowed, that is, cycles that involve only one
module with static ctors/dtors. Such cycles are ok because a module can
trivially depend on itself or other modules without ctors/dtors. However, when
a cycle requires going through such a module (sans ctor/dtor) twice as in the
above example, it will not be detected.
The logical way around this is to remove those nodes from the dependency graph,
forwarding all edges to incoming connections. Such an algorithm would be an
O(n^2) task. I don't know if there's a way to do this without creating a
separate table. If the compiler could generate transitive dependencies, then
we could do this trivially by just skipping those modules. But I'm pretty sure
that's can be impossible if the modules are not compiled together.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 --- Comment #5 from Jonathan M Davis jmdavisp...@gmail.com 2010-06-24 10:07:27 PDT --- bar is a member varible _not_ a class variable and should _not_ be global. As such, two independently constructed variables of type Foo should have bars which referenc totally separate arrays. If bar were static, then they'd be shared, but it's not. Now, if the second Foo were constructed by copying the first one, then sure, that's going to result in both bars referencing the same array, and setting an element of one will affect the other. However, in this case, both variables of type Foo were constructed independently, so their bars should not point to the same array. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4383] Optimizer doesn't keep floating point values on the stack if used more than once
http://d.puremagic.com/issues/show_bug.cgi?id=4383 --- Comment #2 from Don clugd...@yahoo.com.au 2010-06-24 12:52:21 PDT --- (In reply to comment #1) Sounds like a prime case for a keyhole optimization. Does DMD have the infrastructure in place to do that? Yes, there's pinholeopt() in cod3.c. But this optimisation should be done earlier. Although it seems as though you could replace: fstp XXX; fld XXX; with fst XXX; there's unfortunately no fst instruction for 80-bit reals, and for doubles and floats it can change the rounding. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3792] Regression: non-constant expression for a template inside a struct using a struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=3792
--- Comment #7 from Don clugd...@yahoo.com.au 2010-06-24 13:55:11 PDT ---
The D2 version of this code never compiled without error.
struct S {
int x;
template T(int val) {
enum S T = { x: val };
}
}
const x = S.T!(0);
It fails to compile because init.c, StructInitializer::toExpression() returns
NULL if any of the fields have names ( if (field.data[i]) goto Lno; )
And this is just because it's never been implemented.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4080] Patch for building dynamic libraries on Mac OS X
http://d.puremagic.com/issues/show_bug.cgi?id=4080 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2010-06-24 14:29:00 PDT --- dmd portion: http://www.dsource.org/projects/dmd/changeset/559 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4385] New: Uncaught exceptions should dump a core
http://d.puremagic.com/issues/show_bug.cgi?id=4385 Summary: Uncaught exceptions should dump a core Product: D Version: D1 D2 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: llu...@gmail.com --- Comment #0 from Leandro Lucarella llu...@gmail.com 2010-06-24 17:43:57 PDT --- Right now an uncaught exception just prints the exception name (or the backtrace in the better case) and make the program exit with status 1. This is really bad for debugging purposes, and specially harmful for the assert statement. I find the assert statement close to useless because this limitation, because I can't inspect the dead program to see what happened as one usually do with C++ (which calls abort when there is an uncaught exception, resulting in a core dump). I'm finding myself removing asserts (specially when they test for null pointers, as the null pointer gives me a dump eventually) or doing a custom assert that calls C's abort(). PS: I'm marking this as a druntime issue even when applies to D1 because it is a runtime issue (and maybe nobody wants to touch Phobo's 1 runtime). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2571] const/invariant/immutable static arrays: const(T)[N] and const(T[N]) are the same, but DMD treats them as different
http://d.puremagic.com/issues/show_bug.cgi?id=2571 --- Comment #2 from Stewart Gordon s...@iname.com 2010-06-24 17:49:56 PDT --- Created an attachment (id=675) Example of a squashed summary line Rendered by Firefox 3.6.3 at inner width 1000. If you make it much narrower, you get a horizontal scrollbar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2571] const/invariant/immutable static arrays: const(T)[N] and const(T[N]) are the same, but DMD treats them as different
http://d.puremagic.com/issues/show_bug.cgi?id=2571 Stewart Gordon s...@iname.com changed: What|Removed |Added Attachment #675 is|0 |1 obsolete|| --- Comment #3 from Stewart Gordon s...@iname.com 2010-06-24 17:52:10 PDT --- (From update of attachment 675) Sorry, attached to wrong bug report. Reposted on issue 4386. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4379] DMD chokes on large nested loop over tuple.
http://d.puremagic.com/issues/show_bug.cgi?id=4379 David Simcha dsim...@yahoo.com changed: What|Removed |Added Severity|regression |normal --- Comment #3 from David Simcha dsim...@yahoo.com 2010-06-24 19:42:08 PDT --- I was able to reproduce this on 2.046. Try making the tuples bigger. Maybe it's at least somewhat nondeterministic, a memory allocation bug or something. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4387] New: std.range.Cycle assumes lvalue elements
http://d.puremagic.com/issues/show_bug.cgi?id=4387 Summary: std.range.Cycle assumes lvalue elements Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com Depends on: 3294 --- Comment #0 from David Simcha dsim...@yahoo.com 2010-06-24 20:01:35 PDT --- std.range.Cycle assumes lvalue elements. Documenting this in Bugzilla to remind someone (possibly me) to check in the fix once bug 3294 is fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4388] New: std.range.Radial assumes lvalue elements
http://d.puremagic.com/issues/show_bug.cgi?id=4388 Summary: std.range.Radial assumes lvalue elements Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com Depends on: 3294 --- Comment #0 from David Simcha dsim...@yahoo.com 2010-06-24 20:04:01 PDT --- std.range.Radial assumes lvalue elements. Documenting this in Bugzilla to remind someone (possibly me) to check in the fix once bug 3294 is fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3874] std.range.stride assumes a bidirectional input range
http://d.puremagic.com/issues/show_bug.cgi?id=3874 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||dsim...@yahoo.com Resolution||FIXED --- Comment #1 from David Simcha dsim...@yahoo.com 2010-06-24 20:07:37 PDT --- Fixed in SVN. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4305] Take, Chain on top of ranges w/o moveFront()
http://d.puremagic.com/issues/show_bug.cgi?id=4305 David Simcha dsim...@yahoo.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from David Simcha dsim...@yahoo.com 2010-06-24 20:07:48 PDT --- Fixed in SVN. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
