[Issue 2893] Type const(int) does not have an Unsigned counterpart
http://d.puremagic.com/issues/show_bug.cgi?id=2893 and...@metalanguage.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from and...@metalanguage.com 2009-04-25 06:12 --- Fixed in svn. Thank you. --
[Issue 2895] std.stream.File access violation on close() in dtor
http://d.puremagic.com/issues/show_bug.cgi?id=2895 fvbom...@wxs.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from fvbom...@wxs.nl 2009-04-25 07:10 --- This is a bug in your code. Don't access GC-allocated memory from the destructor unless you're sure it won't be collected before the destructor is called. In this case, the likely sequence of events when the GC runs on program exit is as follows: 1) The GC sees the File is no longer referenced from any root, and frees its memory pool slot. 2) Since it was the last (only) item in its memory pool, the memory for the pool gets unmapped. 3) The GC determines there are no more references to your XXX. 4) The GC first calls the destructor for the XXX. 5) The destructor accesses unmapped memory (previously known as a File) and triggers an access violation. If you shrink the XXX class by removing members, it probably shrinks enough to be put into the same pool as the File object (which is presumably smaller). This causes the File to no longer be the last item in its memory pool just before it gets collected, so the pool is not freed yet. The XXX destructor then accesses deallocated (but not unmapped) memory before returning and letting the program close down gracefully, without detecting the bug. --
[Issue 2894] abstract classes sometimes allow non-abstract bodyless functions
http://d.puremagic.com/issues/show_bug.cgi?id=2894
s...@iname.com changed:
What|Removed |Added
CC||s...@iname.com
Keywords|wrong-code |link-failure, spec
--- Comment #1 from s...@iname.com 2009-04-25 08:36 ---
That the first example links is understandable - because C.foo is never used,
the compiler doesn't create any references to it.
That the second example fails is semi-understandable - presumably the compiler
creates a vtbl for C's implementation of I, but the linker cannot resolve it
because no implementation of C.foo() has been linked in. However, it does seem
that DMD could be better at DCE.
Less understandable is that this fails with the same error:
--
abstract class C { void foo(); }
class D : C {}
void main() { }
--
It was my understanding as well that a function in an abstract class is
automatically abstract if no body is given. But it appears now that it's the
same as in a non-abstract - if the function isn't declared abstract, it
references an externally-defined function. Still, the spec probably needs to
be clearer on the issue.
--
[Issue 2847] ICE when struct includes type real variable (minor situation)
http://d.puremagic.com/issues/show_bug.cgi?id=2847 somea...@yahoo.com changed: What|Removed |Added Priority|P4 |P1 --- Comment #2 from somea...@yahoo.com 2009-04-25 14:58 --- v2.029 has the same bug. Raise to P1, since the compiler crashes. --
[Issue 2648] Unnecessary struct ABI inconsistency
http://d.puremagic.com/issues/show_bug.cgi?id=2648 dhase...@gmail.com changed: What|Removed |Added Keywords||spec --- Comment #1 from dhase...@gmail.com 2009-04-25 15:25 --- The ABI as implemented in DMD with regards to returning structs appears to be as the spec describes for Windows, as confirmed by mucking about with obj2asm. (Note that, to create a 3-byte struct, you need to use align(1).) I ascertained this using dmd2.029; other versions might have different behavior. --
[Issue 2900] Array appending slowed drastically since integration of druntime
http://d.puremagic.com/issues/show_bug.cgi?id=2900 --- Comment #1 from dsim...@yahoo.com 2009-04-25 23:09 --- Created an attachment (id=340) -- (http://d.puremagic.com/issues/attachment.cgi?id=340action=view) Fix by adding BlkInfo caching to druntime GC. I've figured out the problem. In lifetime.d, the druntime devs tried to improve the allocation model in a way that required the whole BlkInfo struct from the GC, so the caching of size info wasn't used. This patch addresses this by adding caching of BlkInfo similar to caching of size to the GC. It also fixes a subtle bug in the size caching that I found while reading the code: When free() is called on the block whose size is currently being cached, that cache information is not cleared. --
