[Issue 5686] class template error
http://d.puremagic.com/issues/show_bug.cgi?id=5686
--- Comment #1 from changlon chang...@gmail.com 2011-03-03 00:27:11 PST ---
update test case:
-
class Test2(string name, string file = __FILE__, ptrdiff_t line = __LINE__){
static assert( line != __LINE__ -1 );
ptrdiff_t test( string file = __FILE__, ptrdiff_t line = __LINE__)(){
static assert( line != __LINE__ -1 );
return line ;
}
}
void main(){
auto test2 = new Test2!(test) ;
test2.test ;
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5687] std.string.format() error with %a
http://d.puremagic.com/issues/show_bug.cgi?id=5687 --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-03-03 00:27:42 PST --- I've found the cause for this: 1.2 is a double, and should be formatted as such, but it is converted to a real internally in std.format.doFormat(). I think the right way to go is to rewrite std.string.format() in terms of std.format.formattedWrite() instead of std.format.doFormat(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5656] dmd fails to compile optimized foreach over a big enum
http://d.puremagic.com/issues/show_bug.cgi?id=5656 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Don clugd...@yahoo.com.au 2011-03-03 00:39:59 PST --- *** This issue has been marked as a duplicate of issue 4379 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4379] ICE(blockopt.c): foreach over huge tuple, only with -O
http://d.puremagic.com/issues/show_bug.cgi?id=4379 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||jens.k.muel...@gmx.de --- Comment #7 from Don clugd...@yahoo.com.au 2011-03-03 00:39:59 PST --- *** Issue 5656 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5688] New: Poor optimization of (long 1)
http://d.puremagic.com/issues/show_bug.cgi?id=5688
Summary: Poor optimization of (long 1)
Product: D
Version: D1 D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2011-03-03 00:47:06 PST ---
The optimiser does a very poor job in a case like this:
bool foo(long v)
{
return v1;
}
It generates this:
mov EAX,4[ESP]
mov EDX,8[ESP]
and EAX,1
xor EDX,EDX
or EDX,EAX
jne L17
xor EAX,EAX
jmp short L1C
L17:mov EAX,1
L1C:ret 8
That's terrible code! It should just do:
mov EAX, 4[ESP]
and EAX, 1
ret 8
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5684] Extremely show compile times with large tuples with -O -inline
http://d.puremagic.com/issues/show_bug.cgi?id=5684 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2011-03-03 00:51:08 PST --- I think this is basically the same issue as bug 4379. Each optimiser pass can only remove ONE comma expression -- but the entire expression gets traversed each time. So, the optimisation time is O(n^^2) where n = depth of comma expressions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4750] fail_compilation/fail225.d causes dmd to segv
http://d.puremagic.com/issues/show_bug.cgi?id=4750 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Brad Roberts bra...@puremagic.com 2011-03-03 01:00:53 PST --- https://github.com/D-Programming-Language/dmd/commit/e199b4858775a417460ddea598aaf2f4f114dcae https://github.com/D-Programming-Language/dmd/commit/e3a7ca4f8c3c922b23d8d897a260b21849525b5f -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5689] New: [64-Bit] uniform() fails with -profile
http://d.puremagic.com/issues/show_bug.cgi?id=5689
Summary: [64-Bit] uniform() fails with -profile
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r mrmoc...@gmx.de 2011-03-03 01:04:42 PST ---
import std.random;
void main()
{
auto f = uniform(0.0, 1.0);
}
$ dmd -m64 -profile profile.d
$ ./profile
object.Exception@dmd/linux/bin/../../src/phobos/std/random.d(932): Invalid
distribution range: [0, 0)
Compiling it without -profile or m64 works.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5687] std.string.format() error with %a
http://d.puremagic.com/issues/show_bug.cgi?id=5687 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2011-03-03 01:12:37 PST --- (In reply to comment #1) I've found the cause for this: 1.2 is a double, and should be formatted as such, but it is converted to a real internally in std.format.doFormat(). I don't think that's the reason. On Windows, the %A format always begins with 0x1. (except of course for 0, NaN, inf). You will never, under any circumstances, see something beginning with 0x9. Is it actually true that %A on Linux for doubles always begins with 0x1. ? If so, then it's a Linux %A bug for reals. In fact, converting from double to real should NEVER change the %a result. I think the right way to go is to rewrite std.string.format() in terms of std.format.formattedWrite() instead of std.format.doFormat(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5687] std.string.format() error with %a
http://d.puremagic.com/issues/show_bug.cgi?id=5687
--- Comment #3 from Don clugd...@yahoo.com.au 2011-03-03 01:17:33 PST ---
On Windows:
import std.stdio;
import std.string;
void main()
{
writefln(%a, 1.2);
writeln(format(%a, 1.2));
}
---
0x1.3p+0
0x1.3p+0
---
This bug is Linux-only.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5687] std.string.format() error with %a
http://d.puremagic.com/issues/show_bug.cgi?id=5687 --- Comment #4 from Lars T. Kyllingstad bugzi...@kyllingen.net 2011-03-03 01:57:22 PST --- (In reply to comment #2) Is it actually true that %A on Linux for doubles always begins with 0x1. ? Having tested with a large number of random doubles, that certainly seems to be the case. If so, then it's a Linux %A bug for reals. Wow, you'd think someone would have discovered this before. In fact, converting from double to real should NEVER change the %a result. Thinking some more about it, that makes sense. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5686] class template error
http://d.puremagic.com/issues/show_bug.cgi?id=5686 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com 2011-03-03 06:36:13 PST --- (In reply to comment #2) In the static assert line (line 8), __LINE__ should be 8, and line should be 7, since the previous line contains the declaration of line. Wow, that was confusing :) Let's call the template parameter lineno. I'll try again: In the static assert line (line 8), __LINE__ should be 8, and lineno should be 7, since the previous line contains the declaration of lineno. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5686] class template error
http://d.puremagic.com/issues/show_bug.cgi?id=5686 --- Comment #4 from changlon chang...@gmail.com 2011-03-03 06:45:53 PST --- The lineno shoule be the lineno where template is be instantiated, not where it be declared . for template and function template it is working . for class template and class member template it is not working . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5686] class template error
http://d.puremagic.com/issues/show_bug.cgi?id=5686
--- Comment #5 from changlon chang...@gmail.com 2011-03-03 06:50:13 PST ---
---
ptrdiff_t Test1( string file = __FILE__, ptrdiff_t line = __LINE__)(){
pragma(msg, line.stringof);
return line ;
}
class Test2(string name, string file = __FILE__, ptrdiff_t line = __LINE__){
pragma(msg, line.stringof);
}
void main(){
auto test1 = Test1();
auto test2 = new Test2!(test) ;
}
---
compile this the dmd print 11, 7. dmd should print 11, 12 .
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5686] class template error
http://d.puremagic.com/issues/show_bug.cgi?id=5686
--- Comment #6 from Steven Schveighoffer schvei...@yahoo.com 2011-03-03
07:16:34 PST ---
With some testing, I discovered that it's the act of explicit instantiation
that causes the line number to be tied to the declaration line:
ptrdiff_t Test1(string name, string file = __FILE__, ptrdiff_t line =
__LINE__)(){
pragma(msg, line.stringof);
return line ;
}
void main(){
auto test1 = Test1!(test)();
}
prints 1.
This workaround does work:
Test2!(file, line) createTest2(string file = __FILE__, ptrdiff_t line =
__LINE__)()
{
return new Test2!(file line);
}
I agree with the request that the line number and file should be tied to the
instantiation line, not the declaration line.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5688] Poor optimization of (long 1)
http://d.puremagic.com/issues/show_bug.cgi?id=5688
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-03-03
11:49:26 PST ---
Interestingly, if the code is written as:
bool foo(long v)
{
return (v 1) == 1;
}
the code generated is:
mov EAX,4[ESP]
mov EDX,8[ESP]
and EAX,1
xor EDX,EDX
ret 8
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5687] std.string.format() error with %a
http://d.puremagic.com/issues/show_bug.cgi?id=5687 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-03-03 11:55:36 PST --- %a and %A formatting is done in Phobos using snprintf, which (sadly) produces different results on Windows than Linux. In order to properly fix this, we just need to write our own %a formatter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5691] New: walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691
Summary: walkLength() compatible with opApply()
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-03-03 12:42:36 PST ---
std.range.walkLength() has to return the length of any collection or lazy
iterable that has a length property or is iterable, like a struct with
opApply():
import std.range: walkLength;
struct Iter {
int stop;
int opApply(int delegate(ref int) dg) {
int result;
foreach (i; 0 .. stop) {
result = dg(i);
if (result) break;
}
return result;
}
}
void main() {
assert(walkLength(Iter(10)) == 10);
}
But DMD 2.052 gives:
test.d(14): Error: template std.range.walkLength(Range) if
(isInputRange!(Range)) does not match any function template declaration
test.d(14): Error: template std.range.walkLength(Range) if
(isInputRange!(Range)) cannot deduce template function from argument types
!()(Iter)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Keywords|rejects-valid | CC||jmdavisp...@gmx.com OS/Version|Windows |All Severity|normal |enhancement --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-03-03 13:34:19 PST --- Why? walkLength specifically works on _ranges_. A struct with opApply is _not_ a range. I see no reason for it to work with opApply. Not only is it in std.range, but it _specifically_ says that it works on ranges. And since when do the functions in std.range or std.algorithm work on structs with opApply? They all have template constraints like isForwardRange, which sure isn't going to work on a struct with opApply. walkLength isn't even design to work on a container or collection. It works on _ranges_. That's it. I see no reason to contort it to work with opApply. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 --- Comment #3 from bearophile_h...@eml.cc 2011-03-03 14:38:46 PST --- (In reply to comment #2) to count the items of a lazy range I meant lazy iterable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5692] New: Printing complex numbers with negative imaginary part
http://d.puremagic.com/issues/show_bug.cgi?id=5692
Summary: Printing complex numbers with negative imaginary part
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: minor
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-03-03 14:41:40 PST ---
A D2 program:
import std.stdio;
void main() {
auto c = 0-1i;
writeln(c);
}
It prints (dmd 2.052):
0+-1i
But I think the + sign is not needed, so I expect this output:
0-1i
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2011-03-03 14:47:19 PST --- And since when is a range created by opApply? It's not a range until it's a type with the appropriate functions on it. Sure, you could feed a struct with opApply to std.array.array and get an array, which is then a range. But something that uses opApply is _not_ a range. opApply is designed specifically for use with foreach. It is not a range and is similar to a range only in that it is related to iterating over a list of items. If you want to treat something with opApply as a range, then make it a range or wrap it in one. It's going to rightfully fail for isInputRange, isForwardRange, etc. It is _not_ a range and should not be treated as one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2011-03-03 15:26:56 PST --- We could define some algorithms to work with opApply, but that would blow up the size of std.algorithm and we'd hit http://d.puremagic.com/issues/show_bug.cgi?id=3923. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5621] speller.c: enhancement request
http://d.puremagic.com/issues/show_bug.cgi?id=5621 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-03-03 16:08:00 PST --- Implementing this would be difficult as it requires top-down type inference, whereas the semantic analysis is all done bottom-up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 --- Comment #6 from bearophile_h...@eml.cc 2011-03-03 16:15:35 PST --- (In reply to comment #5) We could define some algorithms to work with opApply, but that would blow up the size of std.algorithm I agree that std.algorithm already contains many functions (as in future std.container if it doesn't split). But I don't think this can justify keeping walkLength() semantic as an amputee. A possible solution is then to keep walkLength() inside std.range, despite it working with opApply() too. One of the purposes of a good standard library is to reduce the useful functions I have to write and maintain. I will need to keep a walkLength-like function to perform this complete semantics. and we'd hit http://d.puremagic.com/issues/show_bug.cgi?id=3923. walkLength() returns an integral value that represents the walking length of the iterable, regardless the way the iterable is implemented. This doesn't make the function harder to understand (but a struct/class is free to have more than one opApply(), that yield a different number of items. walkLength() has to walk the single-item-yield opApply()). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 --- Comment #8 from Jonathan M Davis jmdavisp...@gmx.com 2011-03-03 16:38:57 PST --- Honestly, whenever I see anyone discussing opApply, my first reaction is to question why they're using it in the first place. In almost all cases, ranges do what opApply can do, and they do it better. There _are_ a few cases where opApply is still better (e.g. you can get indices out of opApply with foreach but not ranges), but in most cases, opApply is unnecessary. And a lazily iteraterable struct sounds _very_ much like it should be range. std.range and std.algorithm are designed around ranges, not opApply. If anything, the fact that someone needs to use opApply for something rather than a range indicates that ranges need to be improved, not that we need to take our range-based functions are make them work with opApply. As Andrei point out, the added complexity would be quite large, and we definitely don't want that. Really, if you want to use range-based stuff, you should be using ranges. And from the little you've said about your use case, it seems like a _prime_ example of something that should be a range rather than use opApply. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5691] walkLength() compatible with opApply()
http://d.puremagic.com/issues/show_bug.cgi?id=5691 --- Comment #9 from bearophile_h...@eml.cc 2011-03-03 16:54:17 PST --- (In reply to comment #7) Instead you may want to use the range interface and benefit of walkLength and others. The semantics of opApply() is inverted compared to the range interface (the opApply() is similar to the Python yield, with a worse syntax). There are situations where for my mind the semantics of opApply()/yield turns out to be more natural. Example: I'm able to write a tree visit in moments using yield, but it takes me some reflection to perform it with the range interface. Maybe it's just a limit/problem of my mind. In bug 5660 I have also tried to explain that sometimes it's also a compact way to write iterable things. The worse problem is that it creates a precedent - then why not do the same for other algorithms (including find itself of which you complain already)? I see. For me there's a difference between things like map/filter and array/walkLength because a map over a opApply() can't produce a range (efficiently), so I have not seriously asked map() to accept an Iter struct like that. On the other hand array/walkLength don't need to spit out an iterable, they just scan it, so in my mind they are allowed to be able to digest any kind of iterable. So is it right for find() to work on opApply()? I'd like the answer to be positive, but I am willing to accept a negative answer. I'm trying to help, but I leave you the final word on Phobos, and you often know better. Feel free to close this bug report when you have decided. Sorry for my philosophic dilemmas :) Please abide to your own standards. My standards are complex, because reality is complex. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5693] New: Problem with address of template struct opCall
http://d.puremagic.com/issues/show_bug.cgi?id=5693
Summary: Problem with address of template struct opCall
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: ice-on-invalid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-03-03 17:40:53 PST ---
struct Foo {
void opCall(T)() {}
}
void main() {
auto x = Foo();
}
DMD 2.052 shows:
test.d(5): Error: template test.Foo.opCall(T) does not match any function
template declaration
test.d(5): Error: template test.Foo.opCall(T) cannot deduce template function
from argument types !()()
And then dmd crashes.
(I am not sure the keyword below is correct.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5688] Poor optimization of (long 1)
http://d.puremagic.com/issues/show_bug.cgi?id=5688
--- Comment #2 from Don clugd...@yahoo.com.au 2011-03-03 17:52:46 PST ---
(In reply to comment #1)
Interestingly, if the code is written as:
bool foo(long v)
{
return (v 1) == 1;
}
the code generated is:
mov EAX,4[ESP]
mov EDX,8[ESP]
and EAX,1
xor EDX,EDX
ret 8
I noticed that. And even though that's better, both uses of EDX are completely
unnecessary.
Changing cgelem.c, elcmp(), around line 3350 to this:
case 8:
-e = el_una(OP64_32,TYlong,e);
+e-E1 = el_una(OP64_32,TYint,e-E1);
+e-E2 = el_una(OP64_32,TYint,e-E2);
break;
makes it create optimal code, although that's probably incorrect for 64 bits.
The way elcmp() works looks pretty bizarre to me.
But it's the return ( v 1); case that is the primary problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5647] [64-bit] Valgrind complains about illegal instruction
http://d.puremagic.com/issues/show_bug.cgi?id=5647 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-03-03 19:21:50 PST --- https://github.com/D-Programming-Language/dmd/commit/afed6b42a39d8b07bce17abf819afec5f9d98b69 https://github.com/D-Programming-Language/dmd/commit/03abec0f1460bd0047eeeffce905baf978cc6e29 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5517] SEGV: assert(false) in release mode
http://d.puremagic.com/issues/show_bug.cgi?id=5517 --- Comment #2 from Don clugd...@yahoo.com.au 2011-03-03 23:46:40 PST --- Some further detail: 0xF4, the HLT opcode, is a privileged instruction; it doesn't actually get executed. Instead, a Privileged Instruction hardware exception is raised. I would expect Linux to turn this into SIGILL. So I would expect an exit code of 132, if nothing is done to process it. There is no way it should give a SEGV. On Windows, druntime checks the offending instruction, and if it is HLT, it is identified as a runtime assert(0). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
