[Issue 8973] core.cpuid.coresPerCPU returning incorrect value.
https://issues.dlang.org/show_bug.cgi?id=8973 --- Comment #1 from Joakim db...@joakim.fea.st --- Unless you can provide us with some debug data for this function, nobody can debug this unless they have the exact same or similar CPU, which I certainly don't have. --
[Issue 14476] core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #4 from Martin Nowak c...@dawg.eu --- (In reply to Jonathan M Davis from comment #2) It looks like it's this commit in druntime which broke things: I hope you used https://github.com/CyberShadow/Digger to bisect this. --
[Issue 14476] core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476 --- Comment #6 from Jonathan M Davis issues.dl...@jmdavisprog.com --- (In reply to Martin Nowak from comment #4) (In reply to Jonathan M Davis from comment #2) It looks like it's this commit in druntime which broke things: I hope you used https://github.com/CyberShadow/Digger to bisect this. I've never used Digger, and if I knew about it, I'd forgotten. But git-bisect was plenty, and given that that commit adds the test that fails and the code that it's testing, it's not exactly surprising. The harder part was figuring out what pull request the commit was associated with. But unfortunately, I don't know much about what the code is doing, which makes it harder for me to be helpful.(In reply to Martin Nowak from comment #5) (In reply to Jonathan M Davis from comment #2) The second failure with Testing link_linkdep 2.067.0 comes with shared library support for FreeBSD, not sure why they fail on 9.1. The ugly runtime liker bug is fixed in both 8.4 and 9.1. http://svnweb.freebsd.org/base?view=revisionrevision=226155 Hmmm. I'm using 10.1, so I would _hope_ that it would be fine given that the older versions are, but then again, the code in core.thread seems to work fine on 8.4 and not 9.1 or 10.1. However, looking at Joakim's post, his 32-bit 9.1 VM is failing in a different place earlier in the tests if he comments out the failing core.thread test, so for that problem, 9.1 and 10.1 don't seem to be acting the same (though maybe it's a 32-bit vs 64-bit problem, since he's using 32-bits, whereas I'm using 64). Regardless, it's clear that 8.4 is not acting the same as later versions, so the version of FreeBSD seems to matter more than would be desirable. Maybe I should figure out a way to get a FreeBSD 10.1 setup available for Brad on the autotester so that we're not just testing on an older version - though if he wants the current machines to be supported, he'll have to update the current FreeBSD machines by July according to what freebsd.org says about the support lifecycle of 8.4. But for better or worse, I'm now using FreeBSD 10.1 as my main OS, so I'm likely to start noticing some of these problems that have been getting passed the autotester. --
[Issue 13867] Overriding a method from an extern(C++) interface requires extern(C++) on the method definition
https://issues.dlang.org/show_bug.cgi?id=13867
--- Comment #1 from nick nicolas.jincher...@gmail.com ---
+1 for allowing extern(C++) interface members to be implemented without
specifying the linkage.
In fact, I believe it is a bug for this not to be the case.
Consider this example:
interface A {
void foo();
}
extern(C++) interface B {
void foo();
}
class Test : A, B {
void foo() { }
extern(C++) void foo(){}
}
void main() {
Test test = new Test();
test.foo();// error: ambiguous call to 'foo'
}
I believe the fact that the above example would compile fine if 'extern(C++)'
was removed reinforces this point.
I think this should be changed to a bug.
--
[Issue 14476] core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476 --- Comment #5 from Martin Nowak c...@dawg.eu --- (In reply to Jonathan M Davis from comment #2) The second failure with Testing link_linkdep 2.067.0 comes with shared library support for FreeBSD, not sure why they fail on 9.1. The ugly runtime liker bug is fixed in both 8.4 and 9.1. http://svnweb.freebsd.org/base?view=revisionrevision=226155 --
[Issue 14504] New: Regex Optimizer doesn't merge equivalent threads.
https://issues.dlang.org/show_bug.cgi?id=14504
Issue ID: 14504
Summary: Regex Optimizer doesn't merge equivalent threads.
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: reaperunr...@gmail.com
Given the following code:
import std.stdio, std.regex;
void main(string argv[]) {
string m = argv[1];
auto p =
ctRegex!(a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aaa);
if (match(m, p)) {
writeln(match);
} else {
writeln(no match);
}
}
Compile time becomes extremely long due to the regex optimizer not merging
equivalent threads as explained in the forum post here:
http://forum.dlang.org/post/gcxnuocczmdosombv...@forum.dlang.org
--
[Issue 13867] Overriding a method from an extern(C++) interface requires extern(C++) on the method definition
https://issues.dlang.org/show_bug.cgi?id=13867 nick nicolas.jincher...@gmail.com changed: What|Removed |Added CC||nicolas.jincher...@gmail.co ||m --
[Issue 14476] core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476 --- Comment #3 from Jonathan M Davis issues.dl...@jmdavisprog.com --- It looks like this was the pull request that introduced the change: https://github.com/D-Programming-Language/druntime/pull/1109 --
[Issue 11674] core.stdc.fenv.fenv_t declaration not architecture aware
https://issues.dlang.org/show_bug.cgi?id=11674 Joakim db...@joakim.fea.st changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Joakim db...@joakim.fea.st --- It appears this has since been fixed: https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/fenv.d#L30 --
[Issue 14491] Deprecate overriding without override
https://issues.dlang.org/show_bug.cgi?id=14491 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw ibuc...@gdcproject.org --- It's been in deprecation since 2.004 (I didn't realise it was /that/ long ago). Updating deprecated documentation as a start to reflect this: https://github.com/D-Programming-Language/dlang.org/pull/980 @yebblies, I'm happy with delaying removal until post DDMD switch-over. --
[Issue 14490] Deprecate .sort and .reverse properties for arrays
https://issues.dlang.org/show_bug.cgi?id=14490 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw ibuc...@gdcproject.org --- This became a warning in 2.067, raised PR to update documentation https://github.com/D-Programming-Language/dlang.org/pull/980 --
[Issue 11520] [bionic] qsort is missing on linux/bionic
https://issues.dlang.org/show_bug.cgi?id=11520 Joakim db...@joakim.fea.st changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --
[Issue 14503] New: BigInt to binary/octal and lower case %x (hexadecimal format)
https://issues.dlang.org/show_bug.cgi?id=14503
Issue ID: 14503
Summary: BigInt to binary/octal and lower case %x
(hexadecimal format)
Product: D
Version: future
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: dennis.m.ritc...@mail.ru
I believe that we need to add new format specifiers for the data type BigInt
also need to fix the uppercase letters to lowercase hexadecimal specifier %x:
-
import std.bigint : BigInt;
import std.string : format;
import std.stdio : writeln, writefln;
void main() {
BigInt n = 15;
string s = format(%x, n); // does not work properly
writeln(s);
writefln(%x, n); // prints F is a bug
// and to print a lower case
/*string t = format(%b, n); // Format specifier not understood: %b
writeln(t); // does not work
writefln(%b, t); // does not work */
/*string test = format(%o, n); // Format specifier not understood: %o
writeln(test); // does not work
writefln(%o, test); // does not work */
}
--
[Issue 14476] core.thread unit tests failing on FreeBSD 9+
https://issues.dlang.org/show_bug.cgi?id=14476 --- Comment #2 from Jonathan M Davis issues.dl...@jmdavisprog.com --- It looks like it's this commit in druntime which broke things: commit 5c96aca53bf63a9abc58fd45b59156e605c5fa3a Author: Martin Nowak c...@dawg.eu Date: Tue Jan 20 08:56:25 2015 +0100 round thread stack size to pagesize and min stack size The second failure with Testing link_linkdep is there before that commit, but that's the commit that introduces the failure in core.thread. --
[Issue 14490] Deprecate .sort and .reverse properties for arrays
https://issues.dlang.org/show_bug.cgi?id=14490 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc --- Is Phobos reverse returning the array? If this is not true, then I think you can't remove the built-in reverse yet. --
[Issue 14507] New: Installer doesn't configure VS2010 properly; missing mspdb100.dll
https://issues.dlang.org/show_bug.cgi?id=14507 Issue ID: 14507 Summary: Installer doesn't configure VS2010 properly; missing mspdb100.dll Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com This seems to be back again. Fresh install of 2.067.1, compiling for Win64, linker complains: The program can't start because mspdb100.dll is missing from your computer. My computer has VS2010, VS2012, and VS2013 on it. I am using VS2010. I think one problem is that Visual-D needs to ignore sc.ini when operating within each respective version of VS, and give the proper paths for the environment explicitly. Or maybe that *is* the problem, and this should be escalated to Rainer? --
[Issue 14507] Installer doesn't configure VS2010 properly; missing mspdb100.dll
https://issues.dlang.org/show_bug.cgi?id=14507 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com Component|DMD |installer --
[Issue 14504] Regex Optimizer doesn't merge equivalent threads.
https://issues.dlang.org/show_bug.cgi?id=14504 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com Assignee|nob...@puremagic.com|dmitry.o...@gmail.com --
[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows DMC
https://issues.dlang.org/show_bug.cgi?id=14505 Martin Nowak c...@dawg.eu changed: What|Removed |Added Hardware|All |x86 Summary|File doesn't rewind read|File doesn't rewind read |pointer for a+ mode on |pointer for a+ mode on |Windows |Windows DMC --- Comment #3 from Martin Nowak c...@dawg.eu --- Correction, this is only a DMC problem, works fine with MSVC. --
[Issue 14506] New: Wrong floating point type inferred for function with auto return type
https://issues.dlang.org/show_bug.cgi?id=14506
Issue ID: 14506
Summary: Wrong floating point type inferred for function with
auto return type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
import std.random;
auto test(int n)
{
if (n = 0 n 33)
{
return int(0);
}
else if (n = 33 n 66)
{
return float(0);
}
else
{
return real(0);
}
}
void main()
{
auto n = uniform(0, 100);
auto res = test(n);
//typeof(res) should be inferred as real
assert(is(typeof(res) == float));
}
Another example from Ali Çehreli:
import std.traits;
import std.typetuple;
import std.format;
auto foo(A, B)(int n)
{
if (n) {
return A(0);
} else {
return B(0);
}
}
void main()
{
alias types = TypeTuple!(float, double, real);
foreach (A; types) {
foreach (B; types) {
alias ReturnType = typeof(foo!(A, B)(0));
pragma(msg, format(%s %s - %s%s,
A.stringof, B.stringof,
ReturnType.stringof,
(is (ReturnType == CommonType!(A, B))
?
: -- BUG)));
}
}
}
Output:
float float - float
float double - float -- BUG
float real - float -- BUG
double float - double
double double - double
double real - double -- BUG
real float - real
real double - real
real real - real
--
[Issue 14470] Reuse of object memory: new emplace overload
https://issues.dlang.org/show_bug.cgi?id=14470 --- Comment #1 from rswhi...@gmail.com --- Related Thread: http://forum.dlang.org/thread/pllencnccodsfydjj...@forum.dlang.org --
[Issue 8973] core.cpuid.coresPerCPU returning incorrect value.
https://issues.dlang.org/show_bug.cgi?id=8973 Temtaime temta...@gmail.com changed: What|Removed |Added CC||temta...@gmail.com --- Comment #2 from Temtaime temta...@gmail.com --- Confirmed, returning 16 for me(fx 8350). --
[Issue 14503] BigInt to binary/octal and lower case %x (hexadecimal format)
https://issues.dlang.org/show_bug.cgi?id=14503 Ivan Kazmenko ga...@mail.ru changed: What|Removed |Added CC||ga...@mail.ru --
[Issue 14502] dmd -O optimization breaks app
https://issues.dlang.org/show_bug.cgi?id=14502 --- Comment #1 from Tomáš Chaloupka chalu...@gmail.com --- Its really hard for me (as a D noob) to dustmite something usable from this :( The output from gdb is: Program received signal SIGSEGV, Segmentation fault. 0x77aa5407 in object.TypeInfo_Class.getHash(const(void*)) () from /opt/dmd-2.067/lib64/libphobos2.so.0.67 #0 0x77aa5407 in object.TypeInfo_Class.getHash(const(void*)) () from /opt/dmd-2.067/lib64/libphobos2.so.0.67 #1 0x77ac371a in _aaInX () from /opt/dmd-2.067/lib64/libphobos2.so.0.67 #2 0x77ac36d0 in _aaGetRvalueX () from /opt/dmd-2.067/lib64/libphobos2.so.0.67 #3 0x00407bf8 in test.HavlakLoopFinder.DSF(test.BasicBlock, test.UnionFindNode[], int[test.BasicBlock], int[], int) () #4 0x00407c48 in test.HavlakLoopFinder.DSF(test.BasicBlock, test.UnionFindNode[], int[test.BasicBlock], int[], int) () #5 0x00407c48 in test.HavlakLoopFinder.DSF(test.BasicBlock, test.UnionFindNode[], int[test.BasicBlock], int[], int) () It has deterministic behaviour, always segfaults on the 12th iteration. I've made a PR https://github.com/kostya/benchmarks/pull/23 which ads final to classes to speed it up a bit and this problem no longer occur with these changes - I have no idea why --
[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows
https://issues.dlang.org/show_bug.cgi?id=14505 --- Comment #2 from Martin Nowak c...@dawg.eu --- (In reply to Martin Nowak from comment #1) Related to bug 14422. Issue 14422 --
[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows
https://issues.dlang.org/show_bug.cgi?id=14505 --- Comment #1 from Martin Nowak c...@dawg.eu --- Related to bug 14422. --
[Issue 14505] New: File doesn't rewind read pointer for a+ mode on Windows
https://issues.dlang.org/show_bug.cgi?id=14505
Issue ID: 14505
Summary: File doesn't rewind read pointer for a+ mode on
Windows
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat bug.d CODE
void main()
{
import std.file, std.stdio;
std.file.write(test.txt, content);
auto f = File(test.txt, a+);
assert(f.tell == 0);
}
CODE
dmd -run bug
Happens for DMC's and MSVC's runtime.
--
[Issue 13820] switch and case expressions should support alias this types
https://issues.dlang.org/show_bug.cgi?id=13820 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz Version|unspecified |D2 --
[Issue 13820] switch and case expressions should support alias this types
https://issues.dlang.org/show_bug.cgi?id=13820 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Martin Krejcirik m...@krej.cz --- https://github.com/D-Programming-Language/dmd/pull/4618 --
[Issue 14508] New: compiling with -unittest instantiates templates in non-root modules
https://issues.dlang.org/show_bug.cgi?id=14508
Issue ID: 14508
Summary: compiling with -unittest instantiates templates in
non-root modules
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat foo.d CODE
import bar;
CODE
cat bar.d CODE
struct MonoTimeImpl()
{
}
alias MonoTime = MonoTimeImpl!();
CODE
dmd -c -unittest foo
nm foo.o
As bar.d isn't a root module the MonoTimeImpl!() template shouldn't be
instantiated. It works correctly with -O -release -inline and only fails with
-unittest.
--
[Issue 14509] New: Can't override Object methods in synchronized classes
https://issues.dlang.org/show_bug.cgi?id=14509
Issue ID: 14509
Summary: Can't override Object methods in synchronized classes
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
===
synchronized class A
{
override equals_t opEquals(Object rhs) { return 0; }
}
===
Error: function test.A.opEquals does not override any function, did you mean to
override 'object.Object.opEquals'?
There does not seem to be any way to override Object methods in synchronised
classes as those become implicitly shared.
--
[Issue 14480] dmd 2.067 x64 release codegen
https://issues.dlang.org/show_bug.cgi?id=14480 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com Severity|normal |regression --
[Issue 14480] dmd 2.067 x64 release codegen
https://issues.dlang.org/show_bug.cgi?id=14480 --- Comment #7 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to fengli from comment #6) Here's a reduced test case // compile on windows with dmd -m64 -O test.d = BAD This program will give different output every time it's run, regardless of the compiler I tested. --
[Issue 14510] New: Bad tail call optimization with static arrays
https://issues.dlang.org/show_bug.cgi?id=14510
Issue ID: 14510
Summary: Bad tail call optimization with static arrays
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Keywords: wrong-code
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
Assertion fails with -O -m64 :
// test.d //
alias Vector = ulong[3];
void fun(Vector vec, bool recursive = false)
{
assert(vec[2] == 0);
if (recursive)
return;
fun(vec, true);
}
void main()
{
Vector vec;
fun(vec);
}
--
[Issue 14480] dmd 2.067 x64 release codegen
https://issues.dlang.org/show_bug.cgi?id=14480 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14510 --- Comment #9 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Vladimir Panteleev from comment #7) This program will give different output every time it's run, regardless of the compiler I tested. I reduced this behavior, but did not find this to be a regression, so I filed it as a new bug: https://issues.dlang.org/show_bug.cgi?id=14510 --
[Issue 14510] Bad tail call optimization with static arrays
https://issues.dlang.org/show_bug.cgi?id=14510 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14480 --
[Issue 14480] dmd 2.067 x64 release codegen
https://issues.dlang.org/show_bug.cgi?id=14480 --- Comment #8 from fen...@gmail.com --- Hi Vladimir, Are you saying the program producing different output even without -O -m64? In my tests this function produces identical and correct output on windows without -O -m64 and on OSX with any arguments. The expected output is [563.022, 319.849] [534.772, 266.534] [551.44, 365.862] [551.44, 365.862] [563.022, 319.849] [548.897, 293.192] [546.002, 304.695] [546.637, 322.862] [563.022, 319.849] [555.96, 306.52] [551.704, 302.732] [549.294, 304.546] [563.022, 319.849] [559.491, 313.185] [556.661, 308.905] [554.413, 306.519] [563.022, 319.849] [561.256, 316.517] [559.666, 313.781] [558.236, 311.58] [558.236, 311.58] [556.807, 309.379] [555.537, 307.712] [554.413, 306.519] [554.413, 306.519] [552.166, 304.132] [550.499, 303.639] [549.294, 304.546] [554.413, 306.519] [553.29, 305.326] [552.311, 304.606] [551.463, 304.297] [554.413, 306.519] [553.852, 305.922] [553.326, 305.444] [552.835, 305.076] [552.835, 305.076] [552.344, 304.709] [551.887, 304.452] [551.463, 304.297] [551.463, 304.297] [550.615, 303.989] [549.897, 304.093] [549.294, 304.546] [551.463, 304.297] [551.039, 304.143] [550.647, 304.092] [550.286, 304.136] [550.286, 304.136] [549.926, 304.18] [549.596, 304.319] [549.294, 304.546] [549.294, 304.546] [546.884, 306.361] [546.319, 313.779] [546.637, 322.862] [549.294, 304.546] [548.089, 305.454] [547.346, 307.762] [546.943, 310.978] [549.294, 304.546] [548.692, 305] [548.205, 305.804] [547.818, 306.896] [549.294, 304.546] [548.993, 304.773] [548.721, 305.087] [548.475, 305.482] [548.475, 305.482] [548.23, 305.876] [548.011, 306.35] [547.818, 306.896] [547.818, 306.896] [547.431, 307.989] [547.144, 309.37] [546.943, 310.978] [546.943, 310.978] [546.54, 314.195] [546.478, 318.32] [546.637, 322.862] [546.943, 310.978] [546.741, 312.587] [546.625, 314.422] [546.579, 316.423] [546.579, 316.423] [546.533, 318.425] [546.558, 320.591] [546.637, 322.862] [546.637, 322.862] [547.273, 341.03] [551.44, 365.862] [551.44, 365.862] [546.637, 322.862] [546.955, 331.946] [548.156, 342.696] [549.277, 351.175] [546.637, 322.862] [546.796, 327.404] [547.176, 332.363] [547.656, 337.246] [547.656, 337.246] [548.136, 342.128] [548.716, 346.936] [549.277, 351.175] [549.277, 351.175] [550.398, 359.654] [551.44, 365.862] [551.44, 365.862] --
[Issue 14480] dmd 2.067 x64 release codegen
https://issues.dlang.org/show_bug.cgi?id=14480 --- Comment #10 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to fengli from comment #8) Hi Vladimir, Are you saying the program producing different output even without -O -m64? No, I meant with -O -m64. --
