[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 --- Comment #8 from David Simcha 2011-02-20 18:29:43 PST --- Created an attachment (id=921) New gcx.d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 David Simcha changed: What|Removed |Added Attachment #918 is|0 |1 obsolete|| --- Comment #7 from David Simcha 2011-02-20 18:29:08 PST --- Created an attachment (id=920) New patch. Here's a new patch that adds one small but important optimization that I forgot. Now that we're storing the number of pages for B_PAGE stuff, we can skip over large blocks in O(1) time when doing allocPages(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5629] core.time unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5629 --- Comment #1 from Brad Roberts 2011-02-20 18:26:33 PST --- in TickDuration's static this. freebsd has clock_gettime, so it uses the clock_getres api. The results: ts.tv_nsec = 280, ticksPerSec = 3571428 Later, during the unit test: auto t = TickDuration.from!"nsecs"(1_000_000_000); assert(t.nsecs == 1_000_000_000); t.nsecs is slightly less: t.nsecs = 99840 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: Hidden links for Language Reference on d-programming-language.org
On 2/21/2011 7:47 AM, Tyro[a.c.edwards] wrote: The links for Documentation: Language Reference gets hidden when you click on any of the following four items: o Lexical o Templates o Inline Assembler o Documentation Comments - Andrew By the way you cannot get to the list by clicking on Language Reference (http://d-programming-language.org/language-reference.html).
[Issue 5278] DMD generates programs that immediately segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=5278 Vladimir changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #12 from Vladimir 2011-02-20 15:27:04 PST --- I just thought I'd mention that I had some similar problems with DMD on Gentoo due to bad permissions of certain libraries. Do your programs run under root? If so, check permissions for libphobos and whatever 32-bit libraries your program / libphobos uses (glibc? libstdc++?). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 --- Comment #6 from bearophile_h...@eml.cc 2011-02-20 15:11:18 PST --- (In reply to comment #4) > We already knew Java's GC is much better than D's. The purpose of a 3-legged comparison: the Java timing is used as a rough zero-scale, to allow an estimate of the absolute difference between the other two timings. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 --- Comment #5 from bearophile_h...@eml.cc 2011-02-20 15:07:17 PST --- (In reply to comment #4) > I'm not sure what this told us that we didn't already know, though. Thank you for the timings. This synthetic benchmark tells us something important: that for a different situation (but an important one, because that benchmark is quite revealing, despite being so simple) your patch doesn't make the GC significantly worse (it may even improve things a bit). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5630] New: array() of iterable of immutable items
http://d.puremagic.com/issues/show_bug.cgi?id=5630 Summary: array() of iterable of immutable items Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Keywords: rejects-valid Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2011-02-20 15:01:52 PST --- A D2 program: import std.algorithm: map; import std.array: array; void main() { auto r = map!q{ "A"[0] }([0, 1, 2]); auto a = array(r); // Error: result[i] isn't mutable assert(a == "AAA"); } DMD 2.052 gives the errors: ...\dmd\src\phobos\std\array.d(62): Error: result[i] isn't mutable test.d(5): Error: template instance std.array.array!(Map!(result,int[])) error instantiating In my opinion array() needs to be able to build an array of immutable items too, like a string from its immutable chars. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Hidden links for Language Reference on d-programming-language.org
The links for Documentation: Language Reference gets hidden when you click on any of the following four items: o Lexical o Templates o Inline Assembler o Documentation Comments - Andrew
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 --- Comment #4 from David Simcha 2011-02-20 14:48:45 PST --- (In reply to comment #3) > A very simple benchmark, in D and Java. You may use the D version with and > without your patch, and then the Java version too, and show the three timings, > with N = 15 or 18 or more: > > http://codepad.org/yMGK34cb > http://codepad.org/DIOeYn6p I didn't both(In reply to comment #3) > A very simple benchmark, in D and Java. You may use the D version with and > without your patch, and then the Java version too, and show the three timings, > with N = 15 or 18 or more: > > http://codepad.org/yMGK34cb > http://codepad.org/DIOeYn6p Using n = 18: D (with patch): 62 seconds D (without patch): 68 seconds Java: 6 seconds I'm not sure what this told us that we didn't already know, though. We already knew Java's GC is much better than D's. My patch is meant to address issues with large object allocation, not small object. (Large is defined as at least one full page. If no large objects are allocated for the duration of the program, then my patch has virtually no effect.) This benchmark does tons of small object allocation and no large object allocation. The small difference between with and without patch may even just be noise. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5629] New: core.time unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5629 Summary: core.time unittest disabled Product: D Version: D2 Platform: x86 OS/Version: FreeBSD Status: NEW Severity: major Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 14:46:32 PST --- Testing obj/core/time core.exception.asserter...@core.time(1544): unittest failure -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5628] New: std.math unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5628 Summary: std.math unittest disabled Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 14:25:05 PST --- The test either takes an enormous amount of time or it goes into an infinite loop somewhere. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5627] New: std.internal.math.biguintnoasm unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5627 Summary: std.internal.math.biguintnoasm unittest disabled Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 14:23:05 PST --- Testing generated/linux/debug/64/unittest/std/internal/math/biguintnoasm core.exception.asserter...@std.internal.math.biguintnoasm(263): unittest failure -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5626] New: std.random unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5626 Summary: std.random unittest disabled Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 14:22:13 PST --- Testing generated/linux/debug/64/unittest/std/random core.exception.AssertError@std.random(796): unittest failure -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5625] New: std.format unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5625 Summary: std.format unittest disabled Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 14:21:04 PST --- Testing generated/linux/debug/64/unittest/std/format core.exception.AssertError@std.format(3651): unittest failure -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5624] New: std.conv unittest disabled
http://d.puremagic.com/issues/show_bug.cgi?id=5624 Summary: std.conv unittest disabled Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 14:19:56 PST --- the debug version passes the release version segvs -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from bearophile_h...@eml.cc 2011-02-20 13:19:15 PST --- A very simple benchmark, in D and Java. You may use the D version with and without your patch, and then the Java version too, and show the three timings, with N = 15 or 18 or more: http://codepad.org/yMGK34cb http://codepad.org/DIOeYn6p -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 937] C-style variadic functions broken
http://d.puremagic.com/issues/show_bug.cgi?id=937 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright 2011-02-20 13:11:53 PST --- https://github.com/D-Programming-Language/dmd/commit/888bd52ab4d07c132c38f231dfabea648bf94cba https://github.com/D-Programming-Language/dmd/commit/8d2bf812530f51b40fe08c9b0f526b60575ae604 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2011-02-20 13:03:57 PST --- More explanation from David from the n.g.: I've found a way to speed up the GC massively on large heaps without excessive ripple effects. Technically it's still O(N), but with about a hundred fold smaller constant in the case of large heaps with most stuff not scanned. Now, I think the O(N) (where N is the total size of the heap) term has such a small constant that it's for almost all practcal purposes the GC is O(S) (where S is the size of the scanned portion of the heap). It also no longer has any O(N^2) pathological case (which I had discovered while reading the code). So far all unittests for Phobos, dstats and std.parallelism/parallelfuture pass with this enabled. Please test some other code so we can wring out the corner cases in time for the next release. Basically all I did was diverge the Pool struct slightly into large and small object sub-varieties. The large object sub-variety is used to allocate objects of at least a page. It only stores gcbits at page-size offsets, and tracks the offsets of B_PAGEPLUS bins from the nearest B_PAGE bin so that they can be found in O(1). I also added a field to the Pool struct so that the number of free pages in a pool can be tracked in O(1). This should drastically lessen the time it takes to perform large allocations on large heaps. Right now a free memory region is found by a linear search through the pools in the case of large allocations. Unfortunately, I don't see any easy way to fix this. This patch at least allows short circuiting a large number of pools, if there isn't enough free space in the whole pool, let alone contiguous space. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 --- Comment #1 from David Simcha 2011-02-20 12:12:02 PST --- Created an attachment (id=919) The whole gcx.d file, in case you have trouble applying the patch. Here's the whole gcx.d file, in case you have trouble applying the patch. (These things never quite work for me.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5623] New: Slow GC with large heaps
http://d.puremagic.com/issues/show_bug.cgi?id=5623 Summary: Slow GC with large heaps Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Keywords: patch, performance Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha 2011-02-20 12:10:57 PST --- Created an attachment (id=918) The patch. Here's a GC benchmark and its performance on the stock GC. import std.stdio, std.datetime, core.memory, std.conv; void main(string[] args) { if(args.length < 2) { stderr.writeln("Need size."); return; } immutable mul = to!size_t(args[1]); auto ptr = GC.malloc(mul * 1_048_576, GC.BlkAttr.NO_SCAN); auto sw = StopWatch(autoStart); GC.collect(); immutable msec = sw.peek.msecs; writefln("Collected a %s megabyte heap in %s milliseconds.", mul, msec); } Outputs for various sizes (pre-patch): Collected a 10 megabyte heap in 1 milliseconds. Collected a 50 megabyte heap in 4 milliseconds. Collected a 200 megabyte heap in 16 milliseconds. Collected a 500 megabyte heap in 41 milliseconds. Collected a 1000 megabyte heap in 80 milliseconds. Collected a 5000 megabyte heap in 397 milliseconds. Collected a 1 megabyte heap in 801 milliseconds. Collected a 3 megabyte heap in 2454 milliseconds. Collected a 5 megabyte heap in 4096 milliseconds. Attached is a patch that creates separate large and small object pools, only stores the GC bits for the large object pool at pagesize offsets, not 16-byte offsets, and stores, rather than computes, offsets for B_PAGEPLUS pages. So far, all unit tests for Phobos, dstats and std.parallelism/parallelfuture pass with this enabled. Here are the new benchmarks (post-patch): Collected a 10 megabyte heap in 0 milliseconds. Collected a 50 megabyte heap in 0 milliseconds. Collected a 250 megabyte heap in 1 milliseconds. Collected a 500 megabyte heap in 0 milliseconds. Collected a 1000 megabyte heap in 1 milliseconds. Collected a 5000 megabyte heap in 3 milliseconds. Collected a 1 megabyte heap in 6 milliseconds. Collected a 3 megabyte heap in 16 milliseconds. Collected a 5 megabyte heap in 26 milliseconds. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5622] New: [qtd] Static members imported with "alias this" are inaccessible
http://d.puremagic.com/issues/show_bug.cgi?id=5622 Summary: [qtd] Static members imported with "alias this" are inaccessible Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: samu...@voliacable.com --- Comment #0 from Max Samukha 2011-02-20 08:49:26 PST --- class A { enum E { value } alias E.value value; static void foo() { } } class B { A a; alias a this; } void main() { enum v = B.E.value; enum v2 = B.value; B.foo(); } Error: 'this' is only defined in non-static member functions, not main -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 --- Comment #6 from Don 2011-02-20 08:40:20 PST --- (In reply to comment #4) > I don't agree this is an enhancement, it is a bug, It's neither. It is a task. Bugzilla's options are ridiculously limited. > Why is this being handled by assembly code, all the operating systems must > have > APIs for handling this? The most recent ones do, the older ones don't. Really, this code is primarily intended for determining which features should be supported for low-level operations used by the runtime; and as such, it must be available at a very early stage in the initialization process, regardless of the OS. It replaces several ad-hoc and incorrect functions which had been used in the runtime. It would be good to supplement this with systems calls for the most recent OSes, but to do this without breaking older OSes. Although, probably all 64-bit OSes support it, so maybe it's only a issue for 32-bit systems. > Of course with Mac hardware with 64-bit processors where the boot ROM is 32-bit > the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. > > A hypothesis: the current assembly code can only deal with a single processor > which is why it reports 4 in 32-bit mode on my dual quad-core workstation. If > this is the case should a new bug be raised or can this be handled here? That should be a new bug. The value should be correct, if the BIOS has done its job in setting the processor APIC values correctly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5621] New: speller.c: enhancement request
http://d.puremagic.com/issues/show_bug.cgi?id=5621 Summary: speller.c: enhancement request Product: D Version: D1 & D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: ibuc...@ubuntu.com --- Comment #0 from Iain Buclaw 2011-02-20 08:29:52 PST --- The current implementation of the spell checker (as far as I can tell) always finds the nearest match to the incorrectly spelled symbol. So the following example: struct S2 {} struct S10 {} void main() { S10 a = S(); } Will emit the error: spell.d(6): Error: undefined identifier S, did you mean struct S2? Whereas it would be an improvement in these cases if it were to suggest the lhs type instead. Regards -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5620] New: Implicit conversion of RegexMatch to bool
http://d.puremagic.com/issues/show_bug.cgi?id=5620 Summary: Implicit conversion of RegexMatch to bool Product: D Version: D2 Platform: Other OS/Version: Mac OS X Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg 2011-02-20 08:13:34 PST --- It would be nice if RegexMatch could be implicit converted to a bool. Returning true for a match and false for no match. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4944] Missing tzname even though we have tzset
http://d.puremagic.com/issues/show_bug.cgi?id=4944 Jonathan M Davis changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jonathan M Davis 2011-02-20 05:30:19 PST --- Michel Fortin has confirmed that Mac OS X does indeed declare daylight. It seemed rather silly to create a pull request for just one line of code, so I just pushed it. In any case, with Sean adding tzname to core.stdc.time, this bug appears to be fixed. It would probably, technically be more appropriate to have put tzname in core.sys.posix.time, but tzset is already in core.stdc.time anyway. The commit for Seans fix is: https://github.com/D-Programming-Language/druntime/commit/2860799026c9595785580b876173dc890d22451c -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: compile dmd 2.052 under XP -- error !
On Sunday 20 February 2011 04:13:35 David Wang wrote: > I've installed dmc and dmd2 by the "dinstaller.exe" from > http://ftp.digitalmars.com/dinstaller.exe > > After finished, I downloaded the latest dmd, druntime and phobos from > github.com Please don't post to the bug list. It's intended for messages from bugzilla, not for people to post to directly. If you have questions regarded to learning about D, post at D.learn. If you have questions about the development of D, post on D. But this list is not intended to be posted to. - Jonathan M Davis
compile dmd 2.052 under XP -- error !
I've installed dmc and dmd2 by the "dinstaller.exe" from http://ftp.digitalmars.com/dinstaller.exe After finished, I downloaded the latest dmd, druntime and phobos from github.com When I try to compile the dmd source through the command: "make -f win32.mak release", I got many errors, please view as follows: -- . freebsd.mak:532: warning: ignoring old commands for target `gcov' solaris.mak:602: warning: overriding commands for target `zip' freebsd.mak:602: warning: ignoring old commands for target `zip' win32.mak:40: warning: overriding commands for target `.c.obj' win32.mak:40: warning: ignoring old commands for target `.c.obj' win32.mak:43: warning: overriding commands for target `.asm.obj' win32.mak:43: warning: ignoring old commands for target `.asm.obj' win32.mak:50: warning: overriding commands for target `release' win32.mak:50: warning: ignoring old commands for target `release' win32.mak:57: warning: overriding commands for target `trace' win32.mak:57: warning: ignoring old commands for target `trace' win32.mak:60: warning: overriding commands for target `dmd' solaris.mak:97: warning: ignoring old commands for target `dmd' win32.mak:66: warning: overriding commands for target `debdmd' win32.mak:66: warning: ignoring old commands for target `debdmd' win32.mak:162: warning: overriding commands for target `dmd.exe' win32.mak:162: warning: ignoring old commands for target `dmd.exe' win32.mak:175: warning: overriding commands for target `msgs.h' win32.mak:175: warning: ignoring old commands for target `msgs.h' win32.mak:175: warning: overriding commands for target `msgs.c' win32.mak:175: warning: ignoring old commands for target `msgs.c' win32.mak:175: warning: overriding commands for target `sj1041.msg' win32.mak:175: warning: ignoring old commands for target `sj1041.msg' win32.mak:175: warning: overriding commands for target `sj1036.msg' win32.mak:175: warning: ignoring old commands for target `sj1036.msg' win32.mak:175: warning: overriding commands for target `sj1031.msg' win32.mak:175: warning: ignoring old commands for target `sj1031.msg' win32.mak:178: warning: overriding commands for target `msgsx.exe' win32.mak:178: warning: ignoring old commands for target `msgsx.exe' win32.mak:182: warning: overriding commands for target `elxxx.c' win32.mak:182: warning: ignoring old commands for target `elxxx.c' win32.mak:182: warning: overriding commands for target `cdxxx.c' win32.mak:182: warning: ignoring old commands for target `cdxxx.c' win32.mak:182: warning: overriding commands for target `optab.c' win32.mak:182: warning: ignoring old commands for target `optab.c' win32.mak:182: warning: overriding commands for target `debtab.c' win32.mak:182: warning: ignoring old commands for target `debtab.c' win32.mak:182: warning: overriding commands for target `fltables.c' win32.mak:182: warning: ignoring old commands for target `fltables.c' win32.mak:182: warning: overriding commands for target `tytab.c' win32.mak:182: warning: ignoring old commands for target `tytab.c' win32.mak:186: warning: overriding commands for target `impcnvtab.c' win32.mak:186: warning: ignoring old commands for target `impcnvtab.c' win32.mak:190: warning: overriding commands for target `id.h' win32.mak:190: warning: ignoring old commands for target `id.h' win32.mak:190: warning: overriding commands for target `id.c' win32.mak:190: warning: ignoring old commands for target `id.c' win32.mak:199: warning: overriding commands for target `total.sym' win32.mak:199: warning: ignoring old commands for target `total.sym' win32.mak:202: warning: overriding commands for target `impcnvtab.obj' win32.mak:202: warning: ignoring old commands for target `impcnvtab.obj' win32.mak:205: warning: overriding commands for target `iasm.obj' win32.mak:205: warning: ignoring old commands for target `iasm.obj' win32.mak:208: warning: overriding commands for target `bcomplex.obj' win32.mak:208: warning: ignoring old commands for target `bcomplex.obj' win32.mak:211: warning: overriding commands for target `aa.obj' win32.mak:211: warning: ignoring old commands for target `aa.obj' win32.mak:214: warning: overriding commands for target `bit.obj' win32.mak:214: warning: ignoring old commands for target `bit.obj' win32.mak:217: warning: overriding commands for target `blockopt.obj' win32.mak:217: warning: ignoring old commands for target `blockopt.obj' win32.mak:220: warning: overriding commands for target `cg.obj' win32.mak:220: warning: ignoring old commands for target `cg.obj' win32.mak:223: warning: overriding commands for target `cg87.obj' win32.mak:223: warning: ignoring old commands for target `cg87.obj' win32.mak:226: warning: overriding commands for target `cgcod.obj' win32.mak:226: warning: ignoring old commands for target `cgcod.obj' win32.mak:229: warning: overriding commands for target `cgcs.obj' win32.mak:229: warning: ignoring old commands for target `cgcs.obj' win32.mak:232: warning: overriding commands for target `cgcv.ob
[Issue 5618] Fix separator schizophrenia
http://d.puremagic.com/issues/show_bug.cgi?id=5618 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2011-02-20 03:53:25 PST --- See also bug 4468 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5619] New: coverage output path invalid
http://d.puremagic.com/issues/show_bug.cgi?id=5619 Summary: coverage output path invalid Product: D Version: D2 Platform: x86 OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzi...@digitalmars.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2011-02-20 03:14:02 PST --- This looks like a codegen problem. Slight alterations in druntime's src/rt/cover.d hides the problem. First, dmd's a20 test illustrates it. When run without change, the .lst file is place in test_results/runnablerunnable-a20.lst rather than test_results/runnable/runnable-a20.lst -- missing one of the separators. Adding printf's inside appendFN to show the results == no bug. Adding a temporary to pull the string assembly out of the fopen call at line 165 (only fopen in cover.d) also makes it go away. For now, disabling all coverage tests on freebsd. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 Brad Roberts changed: What|Removed |Added CC||bra...@puremagic.com Platform|Other |x86_64 OS/Version|Windows |All Severity|enhancement |major --- Comment #5 from Brad Roberts 2011-02-20 03:07:29 PST --- I agree, it's pretty important as parts of druntime and phobos use cpu info. Fixed up the platform as well. Don, is this something you might be able to own? You've done a lot of the past cpuid stuff, right? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5612] core.cpuid not implemented on 64
http://d.puremagic.com/issues/show_bug.cgi?id=5612 --- Comment #4 from Russel Winder 2011-02-20 02:51:59 PST --- I don't agree this is an enhancement, it is a bug, even if the 64-bit stuff is in early days. OpenMP, OpenMPI, just::thread and all the other C, C++ and Fortran paralellism frameworks handle this correctly. Why is this being handled by assembly code, all the operating systems must have APIs for handling this? Of course with Mac hardware with 64-bit processors where the boot ROM is 32-bit the OS boots 32-bit -- since Mac OS X refuses to boot 64-bit in this case. A hypothesis: the current assembly code can only deal with a single processor which is why it reports 4 in 32-bit mode on my dual quad-core workstation. If this is the case should a new bug be raised or can this be handled here? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5616] std.datetime: not cross-platform
http://d.puremagic.com/issues/show_bug.cgi?id=5616 Jonathan M Davis changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jonathan M Davis 2011-02-20 02:17:33 PST --- Fixed: https://github.com/D-Programming-Language/phobos/commit/ac040713d33bdb959007248cd695a1554c574dd0 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5485] TLS sections handled incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=5485 Brad Roberts changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Brad Roberts 2011-02-20 01:23:27 PST --- https://github.com/D-Programming-Language/druntime/commit/7d46be0ee4ba4a59a39f99d92756685c7452bcc8 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5485] TLS sections handled incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=5485 Brad Roberts changed: What|Removed |Added Attachment #879|application/octet-stream|text/plain mime type|| Attachment #879 is|0 |1 patch|| -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---