[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 --- Comment #4 from Sean Kelly 2010-07-20 23:37:58 PDT --- Darnit, I did it again didn't I? I hope I still have the patch lying around. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #29 from Leandro Lucarella 2010-07-20 20:01:30 PDT --- Woops! I'm sorry about the noise, I just found out what the problem was. I was trying building DMD as a 64 bits app, so sizeof(size_t) was 8, but the generated code was 32 bits, so it should be 4. Anyway, the lesson learned is that this patch doesn't look right for cross compilation. I don't even know if DMD is supposed to work as a cross-compiler, though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #28 from Leandro Lucarella 2010-07-20 19:51:19
PDT ---
Some extra info:
(gdb) up
#5 0x004679d4 in VarDeclaration::fillPointerMap (this=0x1130700,
pm=0x7fff15974fc0, a_offset=0) at declaration.c:1379
1379type->fillPointerMap(pm, offset + a_offset);
(gdb) list
1374
1375void VarDeclaration::fillPointerMap(PointerMap *pm, size_t a_offset)
1376{
1377//printf("VarDeclaration::fillPointerMap() %s, ty = %d, offs=%d\n",
toChars(), type->ty, (int)offset);
1378if (!isDataseg())
1379type->fillPointerMap(pm, offset + a_offset);
1380}
1381
1382/**
1383 * If a variable has an auto destructor call, return call for it.
I have commented out that printf() and this is what I got:
VarDeclaration::fillPointerMap() bytes, ty = 19, offs=8
VarDeclaration::fillPointerMap() buffer, ty = 0, offs=12
dmd: mtype.c:5671: void PointerMap::pointer(size_t): Assertion `offset <
m_size' failed.
And this is the piece of D code triggering the assertion:
package class MerkleDamgard : Digest
{
private uintbytes;
private ubyte[] buffer; < This one!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2544] implicit const casting rules allow violations of const-safety
http://d.puremagic.com/issues/show_bug.cgi?id=2544 Leandro Lucarella changed: What|Removed |Added Version|D1 & D2 |2.022 --- Comment #11 from Leandro Lucarella 2010-07-20 19:35:41 PDT --- I'm sorry about the last version change, I accidentally changed it thinking I was editing bug 3463 instead (I hate bugzilla for automatically moving to the next bug report when committing changes). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #27 from Leandro Lucarella 2010-07-20 19:33:05
PDT ---
I'm trying to test this patch but I'm having some problems compiling Tango (I'm
using 0.99.9, not trunk). With the patched DMD, I get this error:
dmd: mtype.c:5671: void PointerMap::pointer(size_t): Assertion `offset <
m_size' failed.
Compiling the file: tango/util/digest/MerkleDamgard.d
Here is some output from a GDB session:
(gdb) bt
#0 0x2b421bf3c175 in *__GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2b421bf3ef80 in *__GI_abort () at abort.c:92
#2 0x2b421bf352b1 in *__GI___assert_fail (assertion=0x58be62 "offset <
m_size", file=, line=5671, function=0x58bea0 "void
PointerMap::pointer(size_t)") at assert.c:81
#3 0x004f5d55 in PointerMap::pointer (this=0x7fff15974fc0, offset=20)
at mtype.c:5671
#4 0x004eaf15 in TypeDArray::fillPointerMap (this=0x11735e0,
pm=0x7fff15974fc0, offset=12) at mtype.c:2241
#5 0x004679d4 in VarDeclaration::fillPointerMap (this=0x1130700,
pm=0x7fff15974fc0, a_offset=0) at declaration.c:1379
#6 0x0040488b in AttribDeclaration::fillPointerMap (this=0x11307c0,
pm=0x7fff15974fc0, offset=0) at attrib.c:289
#7 0x00542327 in ClassDeclaration::toObjFile (this=0x1130150,
multiobj=0) at toobj.c:484
#8 0x00404689 in AttribDeclaration::toObjFile (this=0x113afd0,
multiobj=0) at attrib.c:240
#9 0x004c0da1 in Module::genobjfile (this=0x112bfd0, multiobj=0) at
glue.c:267
#10 0x004e1560 in main (argc=13, argv=0x111f930) at mars.c:1285
(gdb) list
5666 * Actually does nothing if the offset isn't aligned.
5667 */
5668
5669void PointerMap::pointer(size_t offset)
5670{
5671assert(offset < m_size);
5672//reject unaligned pointers
5673if (offset % sizeof(size_t))
5674return;
5675size_t bitpos = offset / sizeof(size_t);
(gdb) print offset
$1 = 20
(gdb) print m_size
$2 = 20
(gdb) up
#4 0x004eaf15 in TypeDArray::fillPointerMap (this=0x11735e0,
pm=0x7fff15974fc0, offset=12) at mtype.c:2241
2241pm->pointer(offset + sizeof(size_t));
(gdb) list
2236}
2237
2238void TypeDArray::fillPointerMap(PointerMap *pm, size_t offset)
2239{
2240// like struct Array { size_t length; byte* data; }
2241pm->pointer(offset + sizeof(size_t));
2242}
2243
2244/* TypeAArray
*/
2245
(gdb) print *pm
$3 = {
m_bits = {
= {
_vptr.Object = 0x5939d0
},
members of Bits:
bitdim = 3,
allocdim = 1,
data = 0x11e4c70
},
m_size = 20
}
(gdb) print offset
$4 = 12
I don't know enough about DMD internals to debug this myself, so any help will
be very much appreciated.
I'd like to run my test suite to the GC with precise scanning to see how it
goes. I've noticed that false pointers can add a lot of variance in the time a
program can take in Linux, where the addresses returned by mmap() is
randomized, so there are times where the address range returned by mmap() is
much more prone to receive false pointers. See this for the full story:
http://www.llucax.com.ar/blog/blog/post/-7a56a111
Running dil to generate the full Tango documentation can take from 50 to 80
seconds depending on the address range returned by the OS (I suspect because of
false pointers; which I hope to prove trying this patch :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 --- Comment #3 from Leandro Lucarella 2010-07-20 17:36:01 PDT --- (In reply to comment #2) > Missed the patch? I don't think it's been applied yet, at least as far as I > can tell from looking at the DMD source. I mean, the bug is marked with the keyword "patch" so I though your intention was to publish the patch in this bug-report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3462] Add a clean way to exit a process.
http://d.puremagic.com/issues/show_bug.cgi?id=3462 --- Comment #6 from Leandro Lucarella 2010-07-20 17:33:30 PDT --- I'm not very familiar with the new threading model in D2, I'm mostly a D1 user, so I can't really say. Sorry and thanks to take the time to answer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4385] Uncaught exceptions should dump a core
http://d.puremagic.com/issues/show_bug.cgi?id=4385 --- Comment #1 from Leandro Lucarella 2010-07-20 16:32:55 PDT --- I just saw changeset 341 (http://www.dsource.org/projects/druntime/changeset/341), thanks for giving this issue some attention. But unless I'm missing something, this change doesn't help much, because the core will be at the point the call to abort() was made, that (again unless I'm missing something) won't be deep in the call stack, where the throw was done. Having a core dumped where the *throw* was made is what is really valuable, as it let you analyze the dead program in the point where it really died. I don't know how hard would be to achieve this, I just know is possible because the C++ runtime (GCC at least) do it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 --- Comment #2 from Sean Kelly 2010-07-20 15:18:59 PDT --- Missed the patch? I don't think it's been applied yet, at least as far as I can tell from looking at the DMD source. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4104] No way to get notified about D runtime termination.
http://d.puremagic.com/issues/show_bug.cgi?id=4104 Sean Kelly changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Sean Kelly 2010-07-20 15:09:44 PDT --- Is this something that can be addressed via a shared module dtor, or is that too early/late in the termination process? isHalting seems of limited utility so I tentatively deprecated it, but perhaps it should be replaced by a status field instead? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3462] Add a clean way to exit a process.
http://d.puremagic.com/issues/show_bug.cgi?id=3462 --- Comment #5 from Sean Kelly 2010-07-20 15:03:10 PDT --- Do you think this may have been addressed by the new messaging protocol in Phobos? I know it's not druntime-specific, but the thread ownership hierarchy seems like a potentially decent solution to this problem. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 190] Cannot forward reference typedef/alias in default value for function parameter
http://d.puremagic.com/issues/show_bug.cgi?id=190 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #3 from Rainer Schuetze 2010-07-20 14:07:12 PDT --- The problem of the original test case is the default initializer. It is evaluated when the type of the function is inferred, but the referenced variable has not yet been semantically analyzed. Here's a patch: Index: expression.c === --- expression.c(revision 576) +++ expression.c(working copy) @@ -4350,6 +4350,8 @@ } #endif } +if(type && !type->deco) +type = type->semantic(loc, sc); /* Fix for 1161 doesn't work because it causes protection * problems when instantiating imported templates passing private @@ -6046,7 +6048,8 @@ e->type = v->type; } } -return e->deref(); +e = e->deref(); +return e->semantic(sc); } FuncDeclaration *f = s->isFuncDeclaration(); The test case in comment 2 is something different and compiles with DMD 2.047. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3979] Order-of-compilation and forward reference errors
http://d.puremagic.com/issues/show_bug.cgi?id=3979 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #4 from Rainer Schuetze 2010-07-20 13:24:50 PDT --- Now, it very much looks like bug 190 with the forward reference hidden in the cyclic import. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4490] New: File ref counting broken for anonymous File structs
http://d.puremagic.com/issues/show_bug.cgi?id=4490
Summary: File ref counting broken for anonymous File structs
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha 2010-07-20 13:24:51 PDT ---
The following runs out of file handles on both Windows and Linux:
import std.stdio;
void main() {
// Assumes you have a file called "foo.txt" laying around. If you don't,
// create one.
while(1) {
File("foo.txt");
}
}
The following while loop body also does:
auto lines = File("foo.txt").byLine();
The following does not:
auto handle = File("foo.txt");
Marking as major because it silently breaks code in subtle ways. I wrote
several small programs that relied on reference counting to free the file
handle, which seemed to work fine until one day I made them use a lot more file
handles than they usually do.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3979] Order-of-compilation and forward reference errors
http://d.puremagic.com/issues/show_bug.cgi?id=3979
Lars T. Kyllingstad changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #3 from Lars T. Kyllingstad 2010-07-20
11:41:52 PDT ---
Anxious to get this extremely annoying problem fixed, I've finally been able to
reduce it to a small test case:
// This is a.d
module a;
import b;
struct Foo {}
Foo foo;
// This is b.d
module b;
import a;
void fun(Foo f = a.foo);
Compilation gives:
$ dmd -c a.d b.d
b.d(4): Error: cannot implicitly convert expression (foo) of type Foo to Foo
Phew! It took a while, hopefully it's worth it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4489] New: std.array.insert is slow
http://d.puremagic.com/issues/show_bug.cgi?id=4489
Summary: std.array.insert is slow
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: performance
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: to...@yahoo.com
--- Comment #0 from to...@yahoo.com 2010-07-20 10:14:18 PDT ---
DMD 2.046.
std.array.insert seemed slow when I tried it, so I made a simple benchmark
comparing it to a simple alternative using memmove.
When compiled with -O -release -inline, the lowest numbers I got where 127 ms
for myInsert and 254 ms for std.array.insert. That's a 100% speedup just from
using the most obvious implementation.
---
import std.array;
import std.perf;
import std.stdio;
import std.c.string;
enum COUNT = 100_000;
void myInsert(T)(ref T[] arr, size_t where, T value)
{
assert(where <= arr.length);
size_t oldLen = arr.length;
arr.length = arr.length + 1;
T* ptr = arr.ptr + where;
memmove(ptr + 1, ptr, (oldLen - where) * T.sizeof);
arr[where] = value;
}
void bench(alias insert)(ref int[] arr)
{
auto pc = new PerformanceCounter;
pc.start();
foreach (_; 0..10) {
arr.length = 0;
foreach (i; 0..COUNT)
insert(arr, i, i);
}
pc.stop();
writeln(pc.milliseconds);
}
void main()
{
int[] arr = new int[COUNT];
bench!(myInsert)(arr);
bench!(std.array.insert)(arr);
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4483] Make foreach over string or wstring where element type not specified a warning
http://d.puremagic.com/issues/show_bug.cgi?id=4483 Max changed: What|Removed |Added CC||awishform...@gmail.com --- Comment #1 from Max 2010-07-20 05:30:51 PDT --- I agree. I'm absolutely happy with the way D handles foreach loops on strings and char[]. However, disambiguation of foreach loops for char and wchar is a an issue that should be addressed. I think the best solution would be to mave it the coding standard to specify the char/dchar/wchar. Issuing a warning whenever you iterate over a string or dstring without explicitely declaring char/char/wchar would indeed be the way to do so. The user is still free to ignore the warning, but accidental misuse would be avoided and a consistently clear coding style would be encouraged. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3273] Regression(2.031): struct invariant + dtor fails to compile (no line number)
http://d.puremagic.com/issues/show_bug.cgi?id=3273 --- Comment #4 from Don 2010-07-20 00:21:01 PDT --- (In reply to comment #3) > (In reply to comment #2) > > (3) invariant + dtor + a non-void function with this struct as parameter, > > has > > never worked. > > For example this code fails on 2.022 with "cannot goto forward into > > different > > try block level". It's never worked. > > I've moved that case into a new bug, bug 4339, since it's not a regression, > unlike the test case in this bug. Now that bug 4339 is fixed, there's a reasonable workaround for this bug: create an opAssign. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
