[Issue 13350] is(typeof(fun)) causes link error when template fun calls undefined reference
https://issues.dlang.org/show_bug.cgi?id=13350 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13350] is(typeof(fun)) causes link error when template fun calls undefined reference
https://issues.dlang.org/show_bug.cgi?id=13350 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ae716b0859c97a9f22ad616070b3d77e9ca6f088 fix Issue 13350 - is(typeof(fun)) causes link error when template fun calls undefined reference Evaluate the type in IsExp, then unspeculative declared symbols. https://github.com/D-Programming-Language/dmd/commit/a6a5dd2cfb32cba7dca55d261d8ddca4ff482704 Merge pull request #3894 from 9rnsr/fix13350 Issue 13350 - is(typeof(fun)) causes link error when template fun calls undefined reference --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #16 from badlink andrea.9...@gmail.com --- (In reply to Sean Kelly from comment #15) Okay, I can't reproduce this using the provided code on Oracle Linux 64-bit. If someone has a reliable repro, please let me know. My Linux machine is using Arch Linux, 3.14.17-1-lts x86_64 kernel, GNU libc 2.19. Oracle Linux is completely different as it is using the 3.8.13 x86_64 kernel and glibc 2.17 (http://www.oracle.com/us/technologies/linux/product/specifications/index.html). Try Manjaro Linux wich is based on Arch but come with a ready desktop environment (just run `pacman -S dlang-dmd` to get DMD) --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #17 from badlink andrea.9...@gmail.com --- Created attachment 1416 -- https://issues.dlang.org/attachment.cgi?id=1416action=edit stack trace --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 Marco Leise marco.le...@gmx.de changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #18 from Marco Leise marco.le...@gmx.de --- *** Issue 10351 has been marked as a duplicate of this issue. *** --
[Issue 10351] [GC] GC deadlocks in thread_suspendAll()
https://issues.dlang.org/show_bug.cgi?id=10351 Marco Leise marco.le...@gmx.de changed: What|Removed |Added Resolution|REMIND |DUPLICATE --- Comment #3 from Marco Leise marco.le...@gmx.de --- *** This issue has been marked as a duplicate of issue 4890 *** --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424
--- Comment #2 from hst...@quickfur.ath.cx ---
Ah, sorry, forgot to post complete example. Here it is:
--
struct S {
void delegate(dchar) onChar = (dchar) {};
}
void main() {
S s;
s.onChar('a');
}
--
--
[Issue 13417] segmentation fault when deduce template type
https://issues.dlang.org/show_bug.cgi?id=13417 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Hmm. What's an alias string supposed to do? I've never seen that before. Usually for passing compile-time strings, we just write string. What did you wish to accomplish with alias string? --
[Issue 13417] segmentation fault when deduce template type
https://issues.dlang.org/show_bug.cgi?id=13417 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||ice --
[Issue 13417] segmentation fault when deduce template type
https://issues.dlang.org/show_bug.cgi?id=13417 --- Comment #2 from hst...@quickfur.ath.cx --- Actually, that doesn't appear to be related to the problem. Removing alias still causes the compiler to crash... --
[Issue 13417] segmentation fault when deduce template type
https://issues.dlang.org/show_bug.cgi?id=13417
--- Comment #3 from hst...@quickfur.ath.cx ---
I managed to reduce the test case a little more:
--
struct Vector(string x, E) { }
void someFunc(E)(Vector!(, E)) { }
void main() {
someFunc(Vector!(, float)());
}
--
Here's the compiler stacktrace under gdb:
--
Program received signal SIGSEGV, Segmentation fault.
0x0047670a in ctfeInterpret(Expression*) ()
(gdb) bt
#0 0x0047670a in ctfeInterpret(Expression*) ()
#1 0x0045793a in deduceType(RootObject*, Scope*, Type*,
ArrayTemplateParameter**, ArrayRootObject**, unsigned int*, unsigned
long)::DeduceType::visit(TypeInstance*) ()
#2 0x00456734 in deduceType(RootObject*, Scope*, Type*,
ArrayTemplateParameter**, ArrayRootObject**, unsigned int*, unsigned long)
()
#3 0x00457307 in deduceType(RootObject*, Scope*, Type*,
ArrayTemplateParameter**, ArrayRootObject**, unsigned int*, unsigned
long)::DeduceType::visit(TypeStruct*) ()
#4 0x0045a93d in deduceType(RootObject*, Scope*, Type*,
ArrayTemplateParameter**, ArrayRootObject**, unsigned int*, unsigned
long)::DeduceType::visit(Expression*) ()
#5 0x00456717 in deduceType(RootObject*, Scope*, Type*,
ArrayTemplateParameter**, ArrayRootObject**, unsigned int*, unsigned long)
()
#6 0x00459238 in
TemplateDeclaration::deduceFunctionTemplateMatch(TemplateInstance*, Scope*,
FuncDeclaration*, Type*, ArrayExpression**) ()
#7 0x004635ab in functionResolve(Match*, Dsymbol*, Loc, Scope*,
ArrayRootObject**, Type*, ArrayExpression**)::ParamDeduce::fp(void*,
Dsymbol*) ()
#8 0x004f9d93 in overloadApply(Dsymbol*, void*, int (*)(void*,
Dsymbol*)) ()
#9 0x00462ebf in functionResolve(Match*, Dsymbol*, Loc, Scope*,
ArrayRootObject**, Type*, ArrayExpression**) ()
#10 0x004faabd in resolveFuncCall(Loc, Scope*, Dsymbol*,
ArrayRootObject**, Type*, ArrayExpression**, int) ()
#11 0x004e1839 in CallExp::semantic(Scope*) [clone .part.122] ()
#12 0x00441d0b in ExpStatement::semantic(Scope*) ()
#13 0x0044683f in CompoundStatement::semantic(Scope*) ()
#14 0x004fc94a in FuncDeclaration::semantic3(Scope*) ()
#15 0x00407d48 in Module::semantic3() ()
#16 0x00405484 in tryMain(unsigned long, char const**) ()
#17 0x770b5eed in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#18 0x00402c75 in _start ()
--
--
[Issue 13417] segmentation fault when deduce template type
https://issues.dlang.org/show_bug.cgi?id=13417 hst...@quickfur.ath.cx changed: What|Removed |Added Severity|critical|regression --- Comment #4 from hst...@quickfur.ath.cx --- This is a regression caused by dmd commit b16f80834e4f9fa9bd62320f132f77fb22fc65b6 (https://github.com/D-Programming-Language/dmd/pull/3824). --
[Issue 13425] New: DList.linearRemove on last element returns non-empty range
https://issues.dlang.org/show_bug.cgi?id=13425 Issue ID: 13425 Summary: DList.linearRemove on last element returns non-empty range Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: murphyslaw...@gmail.com Created attachment 1417 -- https://issues.dlang.org/attachment.cgi?id=1417action=edit The example above, in case you care to test it If a range refers to the last element in a DList, I would expect linearRemove to return an empty range. Instead it returns a non-empty range that appears to access memory outside the list's bounds. Example: auto list = DList!int([1,2,3,4,5]); auto r = list[].drop(4); // r is a view of the last element of list assert(r.front == 5 r.walkLength == 1); r = list.linearRemove(r.take(1)); assert(r.empty); // fails --
[Issue 13425] DList.linearRemove on last element returns non-empty range
https://issues.dlang.org/show_bug.cgi?id=13425 murphyslaw...@gmail.com changed: What|Removed |Added CC||murphyslaw...@gmail.com --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #19 from Sobirari Muhomori dfj1es...@sneakemail.com --- (In reply to badlink from comment #17) stack trace Hmm... if a thread hangs on a mutex, does it handle signals? --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #20 from Sean Kelly s...@invisibleduck.org --- It should. Not doing so seems pretty broken. But it this particular kernel it seems like maybe signals are ignored in this situation. What's happening specifically is that the one thread is blocked on the mutex protecting the GC, and another thread holds that lock and is attempting a collection. I could change this code to use a spin lock instead, but the same problem could crop up with any mutex if I understand the problem correctly. I'm kind of curious to see whether the Boehm GC deadlocks in a similar situation with this kernel. It should, since last time I checked it coordinated collections the exact same way on Linux. --
[Issue 13391] BigInt division by ulong rejected
https://issues.dlang.org/show_bug.cgi?id=13391 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5862d718116a63a3c8686649b7b45a9791636612 Fix Issue 13391 - Allow division of BigInt by long/ulong https://github.com/D-Programming-Language/phobos/commit/7e6d8d715fea7e227c867a881d529f77250d7026 Merge pull request #2477 from fb-pja/bug13391 Fix Issue 13391 - Allow division of BigInt by long/ulong --
[Issue 13391] BigInt division by ulong rejected
https://issues.dlang.org/show_bug.cgi?id=13391 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #21 from Sobirari Muhomori dfj1es...@sneakemail.com --- This mutex protects various global data like the list of threads in core.thread, not GC. --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #22 from Sean Kelly s...@invisibleduck.org --- Yes I misspoke somewhat. The GC acquires the lock to the global thread list while collecting to ensure that everything remains in a consistent state while the collection takes place. In this case the GC already holds this lock and Thread.start() is blocked on it waiting to add the new thread to the list. --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 --- Comment #3 from Daniel Čejchan czda...@gmail.com --- What compiler are you using? http://dpaste.dzfl.pl/9f8f1dc801cd I have tried 2.065 and 2.066 and it doesn't compile. --
[Issue 13426] New: crash when using exceptions in a non-d thread (in thread_stackBottom)
https://issues.dlang.org/show_bug.cgi?id=13426 Issue ID: 13426 Summary: crash when using exceptions in a non-d thread (in thread_stackBottom) Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: blastr...@free.fr Created attachment 1418 -- https://issues.dlang.org/attachment.cgi?id=1418action=edit minimal example that crashes Hi, When a thread is created from C++ (or probably any other language) and this thread calls back to a D function which deals with exceptions (even if they are properly caught), the program will crash. Here is the stack: #0 0x0041f469 in thread_stackBottom () #1 0x0041ee5a in core.runtime.defaultTraceHandler() () #2 0x0041ee01 in core.runtime.defaultTraceHandler() () #3 0x0041e6a1 in _d_traceContext () #4 0x0041bf78 in _d_createTrace () #5 0x00417872 in _d_throwc () #6 0x0041746d in test.throwit() () at test.d:15 #7 0x004173fe in callback() () at test.d:6 #8 0x77bd956d in std::_Bind_simplevoid (*())()::_M_invoke(std::_Index_tuple) (this=0x647708) at /usr/include/c++/4.9/functional:1700 #9 0x77bd94b5 in std::_Bind_simplevoid (*())()::operator()() (this=0x647708) at /usr/include/c++/4.9/functional:1688 #10 0x77bd9432 in std::thread::_Implstd::_Bind_simplevoid (*())() ::_M_run() ( this=0x6476f0) at /usr/include/c++/4.9/thread:115 #11 0x76eac8a0 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #12 0x777b30a4 in start_thread (arg=0x76bdf700) at pthread_create.c:309 #13 0x771e7c2d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I attached a minimal example. Just run build_and_gdb.sh which will compile the c++ library, the d program and start gdb on it. --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 --- Comment #4 from hst...@quickfur.ath.cx --- git HEAD. Could it be a regression? --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 --- Comment #5 from hst...@quickfur.ath.cx --- Strange, I just checked out v2.066.0 and it still compiles and gives me the segfault. Could it be a platform-specific bug?? I'm testing on Linux/64-bit. Or maybe the tag isn't actually what was released? I'm confused. --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 --- Comment #6 from Daniel Čejchan czda...@gmail.com --- Hmm, I tried it again under 2.066 and it now does the same thing as for you. I must have missed something last time checking. Looks like a bug :) --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 --- Comment #7 from hst...@quickfur.ath.cx --- Seems the compile error was removed by this commit: 180a6aabbb5d5db72e6650f8cedc4ba4b7899017 (https://github.com/D-Programming-Language/dmd/pull/2824). Not sure if this is a regression, or a new bug introduced by the PR. --
[Issue 3918] Parameter use before its use in an AndAnd expression with reals treats NaN as false
https://issues.dlang.org/show_bug.cgi?id=3918 --- Comment #10 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d089a3a059915d84170b549de1fc2215eada3334 Fix Issue 3918 - Parameter use before its use in an AndAnd expression with reals treats NaN as false https://github.com/D-Programming-Language/dmd/commit/1ea942a60971472a09e6764a28ccfbfea1bdb501 Merge pull request #3812 from yebblies/issue3918 Issue 3918 - Parameter use before its use in an AndAnd expression with reals treats NaN as false --
[Issue 3761] [Tracker]: DMD optimizer bugs
https://issues.dlang.org/show_bug.cgi?id=3761 Issue 3761 depends on issue 3918, which changed state. Issue 3918 Summary: Parameter use before its use in an AndAnd expression with reals treats NaN as false https://issues.dlang.org/show_bug.cgi?id=3918 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13427] New: [REG2.066] cannot inline default argument alloca(...)
https://issues.dlang.org/show_bug.cgi?id=13427
Issue ID: 13427
Summary: [REG2.066] cannot inline default argument alloca(...)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: marco.le...@gmx.de
A trick that Andrei and I came up with not long ago, to use alloca as part of a
default argument does not work any more. I developed this with someone on #D
one night and use it everywhere I need to pass a D string to a C API.
Use cases:
http://forum.dlang.org/thread/i1gnlo$18g0$1...@digitalmars.com#post-i1gql2:241k6o:241:40digitalmars.com
https://github.com/mleise/fast/blob/master/source/fast/cstring.d#L92
---8
import core.stdc.stdlib;
enum allocaLimit = 1024;
auto wcharPtr(alias str)(void* buffer = 2*(str.length+1) = allocaLimit ?
alloca(2*(str.length+1)) : null)
{
// ...
}
void main()
{
wcharPtr!abcw;
}
-8
--
[Issue 13417] [REG2.066] segmentation fault when deduce template type
https://issues.dlang.org/show_bug.cgi?id=13417 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All Summary|segmentation fault when |[REG2.066] segmentation |deduce template type|fault when deduce template ||type OS|Linux |All --- Comment #5 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3950 --
[Issue 13424] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86 |All OS|Linux |All --- Comment #8 from Kenji Hara k.hara...@gmail.com --- (In reply to hsteoh from comment #7) Seems the compile error was removed by this commit: 180a6aabbb5d5db72e6650f8cedc4ba4b7899017 (https://github.com/D-Programming-Language/dmd/pull/2824). Not sure if this is a regression, or a new bug introduced by the PR. This is a regression issue introduced in the commit. https://github.com/D-Programming-Language/dmd/pull/3951 --
[Issue 13424] [REG2.066] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Summary|Initialization of delegate |[REG2.066] Initialization |to do-nothing default |of delegate to do-nothing |causes segfault at runtime |default causes segfault at ||runtime --
[Issue 13424] [REG2.066] Initialization of delegate to do-nothing default causes segfault at runtime
https://issues.dlang.org/show_bug.cgi?id=13424 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Severity|critical|regression --
