[Issue 5584] New: bad string representation of function types with C/Windows linkage
http://d.puremagic.com/issues/show_bug.cgi?id=5584
Summary: bad string representation of function types with
C/Windows linkage
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2011-02-15 00:06:16
PST ---
This code
extern(C) void fnC() {}
extern(Windows) void fnWindows() {}
pragma(msg,typeof(fnC));
pragma(msg,typeof(fnWindows));
compiled with dmd -c test.d outputs:
voidC ()
voidWindows ()
with bad space placement. This is also the type emitted into the json file.
Here's the simple patch that corrects the spacing:
File: src\mtype.c
4734,4737c4734,4737
case LINKc: p = C ; break;
case LINKwindows: p = Windows ; break;
case LINKpascal:p = Pascal ; break;
case LINKcpp: p = C++ ; break;
---
case LINKc: p = C; break;
case LINKwindows: p = Windows; break;
case LINKpascal:p = Pascal; break;
case LINKcpp: p = C++; break;
Problably, it should better output extern(C) etc. before the return type...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5585] New: bad debug line number info for return statements with enumerator expressions
http://d.puremagic.com/issues/show_bug.cgi?id=5585
Summary: bad debug line number info for return statements with
enumerator expressions
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2011-02-15 00:19:07
PST ---
When compiled by dmd with debug information, stepping through the following
code in a debugger
enum { Success, Failure }
int main()
{
return Success;
}
makes the debugger jump to the enumerator declaration when the instruction
pointer is in fact at the return statement. This can be very annoying because
there is no information of the actual line of execution, you have to guess from
the disassembly.
This is happening because the line info is taken from the first expression of
the return statement, which is the initializer expression of the enum
identifier. I suggest forcing the line number to the statement instead.
*** src\s2ir.c 2011-02-14 19:56:09.0 +-0100
--- src\s2ir.c 2011-02-07 01:49:13.0 +-0100
***
*** 1287,1298
--- 1287,1299
else
{
e = exp-toElem(irs);
assert(e);
}
+ elem_setLoc(e, loc);
block_appendexp(blx-curblock, e);
block_next(blx, BCretexp, NULL);
}
else
block_next(blx, BCret, NULL);
}
This is under Windows, but I guess it also applies to other OS supported by
dmd.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5586] New: length property for RedBlackTree
http://d.puremagic.com/issues/show_bug.cgi?id=5586 Summary: length property for RedBlackTree Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2011-02-15 00:23:12 PST --- For some reason RedBlackTree doesn't have a length property. From what I understand of red black trees, it should be able to easily keep track of its length and have a length property which is O(1). But it doesn't have that right now. Instead, you have to use walkLength, which is O(n). A length property which is O(1) should be added to RedBlackTree. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5589] New: Incorrect definitions in core.stdc.locale (Windows)
http://d.puremagic.com/issues/show_bug.cgi?id=5589
Summary: Incorrect definitions in core.stdc.locale (Windows)
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: johnch_a...@hotmail.com
--- Comment #0 from johnch_a...@hotmail.com 2011-02-15 02:20:46 PST ---
Looks like the Windows version of the locale.h header differs from that on
other platforms, so some changes need to be made to core.stdc.locale.
1) The lconv structure should end immediately after the n_sign_posn member.
2) The category constants should be as follows:
enum {
LC_ALL = 0,
LC_COLLATE = 1,
LC_CTYPE = 2,
LC_MONETARY = 3,
LC_NUMERIC = 4,
LC_TIME = 5
}
Also, LC_PAPER through to LC_IDENTIFICATION don't get defined in the Windows
header.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5590] New: ICE when using .values on enum which is associative array
http://d.puremagic.com/issues/show_bug.cgi?id=5590
Summary: ICE when using .values on enum which is associative
array
Product: D
Version: unspecified
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2011-02-15 02:26:28
PST ---
On dmd 2.051, this code
import std.path;
import std.range;
enum aa = [5 : hello];
void main(string[] args)
{
auto a = aa.values.front;
}
fails to compile, giving this error: Internal error: e2ir.c 4617
With the current beta, it gives: Internal error: e2ir.c 4835
This may or may not be a duplicate of bug# 4460. I don't know enough about the
compiler details to know for sure, but it does seem similar. It's definitely
not quite the same circumstances though, so I'm creating a new bug just in case
it is something separate.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5580] [64-bit] String switch statements broken in 64-bit mode
http://d.puremagic.com/issues/show_bug.cgi?id=5580 --- Comment #2 from David Simcha dsim...@yahoo.com 2011-02-15 02:34:01 PST --- Created an attachment (id=912) Statically linked binary -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5588] Wrong line number
http://d.puremagic.com/issues/show_bug.cgi?id=5588 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2011-02-15 03:53:14 PST --- See bug 4076 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5591] New: EBX register not preserved when calling stdcall function pointer
http://d.puremagic.com/issues/show_bug.cgi?id=5591
Summary: EBX register not preserved when calling stdcall
function pointer
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hypothermia.fr...@gmail.com
--- Comment #0 from hypothermia.fr...@gmail.com 2011-02-15 03:58:17 PST ---
According to D's calling convention EBX register is preserved across function
calls, but when when I call a pointer to an extern(Windows) function, EBX gets
filled with some garbage value. It only happens the first time this function is
called, and the following times it behaves as expected!
The following sample code can be run to show it:
extern(Windows) void foo(int i){
size_t ebx;
asm { mov ebx,EBX; }
std.stdio.writefln( foo (EBX = %s,%s),ebx,i);
asm { mov EBX,10; }
}
alias extern(Windows) void function(int) fooT;
fooT bar;
void main(){
size_t ebx=0;
bar=foo;
asm { mov EBX,1; } //try normal call
foo(2);
asm { mov ebx,EBX; }
std.stdio.writefln(EBX(after foo) = %x,ebx);
asm { mov EBX,3; } // now try pointer call for the 1st time
bar(4);
asm { mov ebx,EBX; }
std.stdio.writefln(EBX(after bar) = %x,ebx);
asm { mov EBX,5; } //2nd time
bar(6);
asm { mov ebx,EBX; }
std.stdio.writefln(EBX(after bar 2nd time round) = %x,ebx);
main2();
}
void main2(){ //and 3rd time!
size_t ebx=0;
asm { mov EBX,7; }
bar(8);
asm { mov ebx,EBX; }
std.stdio.writefln(EBX(after bar 3rd time round in other func) = %x,ebx);
}
output:
foo (EBX = 1,2)
EBX(after foo) = 1
foo (EBX = 5518328,4)
EBX(after bar) = 5433f8
foo (EBX = 5,6)
EBX(after bar 2nd time round) = 5
foo (EBX = 7,8)
EBX(after bar 3rd time round in other func) = 7
What's going on with EBX on the 1st call?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5588] Wrong line number
http://d.puremagic.com/issues/show_bug.cgi?id=5588 Max Samukha samu...@voliacable.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Max Samukha samu...@voliacable.com 2011-02-15 04:03:49 PST --- *** This issue has been marked as a duplicate of issue 4076 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4076] Wrong error line number with enum
http://d.puremagic.com/issues/show_bug.cgi?id=4076 Max Samukha samu...@voliacable.com changed: What|Removed |Added CC||samu...@voliacable.com --- Comment #2 from Max Samukha samu...@voliacable.com 2011-02-15 04:03:49 PST --- *** Issue 5588 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 5580] [64-bit] String switch statements broken in 64-bit mode
http://d.puremagic.com/issues/show_bug.cgi?id=5580 --- Comment #4 from David Simcha dsim...@yahoo.com 2011-02-15 06:30:28 PST --- My gut feeling is that this is related to Bug 5581, as both invoke calls to memcmp() according to my reading of the disassembly and tracking down of the function calls in the runtime. However, 5581 seems to be reproducible everywhere. If you can't reproduce this, I suggest fixing 5581 first. Once 5581 is fixed, I'll retest this bug on a machine that I was able to reproduce it on and hopefully it will be fixed, too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5591] EBX register not preserved when calling stdcall function pointer
http://d.puremagic.com/issues/show_bug.cgi?id=5591 --- Comment #1 from hypothermia.fr...@gmail.com 2011-02-15 09:23:06 PST --- After doing some more tests I found out that if you compile with -O switch, the code behaves as expected and output is: foo (EBX = 1,2) EBX(after foo) = 1 foo (EBX = 3,4) EBX(after bar) = 3 ... Looks like it's a bug in DMD code gen without the -O switch. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5592] New: Previous definition different: __arrayExpSliceMulSliceAddass_d
http://d.puremagic.com/issues/show_bug.cgi?id=5592
Summary: Previous definition different:
__arrayExpSliceMulSliceAddass_d
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2011-02-15 09:29:27 PST ---
From reading the disassembly it looks like every time
__arrayExpSliceMulSliceAddass_d is used, the implementation gets put in the
object file instead of just an exterm reference.
main.d:
import module1;
void main() {
double[] a, b;
doStuff(a, b);
a[0..b.length] += b[0] * b[0..a.length];
}
module1.d:
void doStuff(double[] arr1, double[] arr2) {
arr1[0..arr2.length] += arr2[0] * arr2[0..arr1.length];
}
Command lines:
dmd -c main.d
dmd -c module1.d
dmd main.obj module1.obj
Result:
OPTLINK (R) for Win32 Release 8.00.8
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
module1.obj(module1) Offset 001FDH Record Type 00C3
Error 1: Previous Definition Different : __arrayExpSliceMulSliceAddass_d
--- errorlevel 1
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5401] std.socket updates and boost license
http://d.puremagic.com/issues/show_bug.cgi?id=5401 Johannes Pfau johannesp...@gmail.com changed: What|Removed |Added CC||johannesp...@gmail.com --- Comment #4 from Johannes Pfau johannesp...@gmail.com 2011-02-15 09:41:02 PST --- Another small request: Could we use gethostbyname_r instead of gethostbyname where supported? This seems to be a lot safer regarding multithreading. gethostbyname_r seems to be a gnu extension, but it's a better option for all systems with the gnu c library. Or probably the getaddrinfo(3), getnameinfo(3), gai_strerror(3) functions could be used. Those are standard and also threadsafe. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4332] C files in druntime should be converted to D
http://d.puremagic.com/issues/show_bug.cgi?id=4332 --- Comment #12 from Iain Buclaw ibuc...@ubuntu.com 2011-02-15 10:21:44 PST --- (In reply to comment #11) Strange... Are there any reasonable debuggers for Windows? I must admit I'm rather terrible on the platform, but I could have a bash at seeing what's up, and why it doesn't work (when Linux is just fine and dandy). After a week of learning and painful struggling, I give up on Windows. Anyone else with better know-how willing to fix this? Regards -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581
--- Comment #1 from David Simcha dsim...@yahoo.com 2011-02-15 11:29:13 PST ---
I think this is actually a long-standing, hard to reproduce, non-deterministic
codegen bug that strikes on 32-bit as well, though due to the non-deterministic
nature of it, under different circumstances. Here's some code that segfaults
on 32 with stock DMD 2.051, only with -O -inline -release enabled. This is
slightly less reduced than the 64 version because anytime I try to reduce it
more, the bug goes away.
import std.stdio;
bool comp(long a, long b) { return a b; }
size_t medianOf3(T)(T[] data) {
// Removing this print statement changes the result.
stderr.writeln(data[0], '\t', data[$ / 2], '\t', data[$ - 1]);
immutable size_t mid = data.length / 2;
immutable uint result = ((cast(uint) (comp(data[0], data[mid]))) 2) |
((cast(uint) (comp(data[0], data[$ - 1]))) 1) |
(cast(uint) (comp(data[mid], data[$ - 1])));
assert(result != 2 result != 5 result 8); // Cases 2, 5 can't
happen.
switch(result) {
case 1: // 001
case 6: // 110
return data.length - 1;
case 3: // 011
case 4: // 100
return 0;
case 0: // 000
case 7: // 111
return mid;
default:
assert(0);
}
assert(0);
}
void main() {
long[] stuff = [4602111750194969114, 4591797823464657051,
4579622497201165564];
medianOf3(stuff);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 David Simcha dsim...@yahoo.com changed: What|Removed |Added OS/Version|Windows |Linux --- Comment #2 from David Simcha dsim...@yahoo.com 2011-02-15 11:31:50 PST --- Forgot to mention: The 32-bit version still only segfaults on Linux. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5004] show both resolved symbols and original identifier in error messages involving aliases
http://d.puremagic.com/issues/show_bug.cgi?id=5004
Denis Derman denis.s...@gmail.com changed:
What|Removed |Added
CC||denis.s...@gmail.com
--- Comment #4 from Denis Derman denis.s...@gmail.com 2011-02-15 14:40:59 PST
---
(In reply to comment #0)
The Clang front-end of LLVM tries harder to give good error messages:
http://clang.llvm.org/diagnostics.html
One simple but nice feature of its error messages is the usage of aka, this
is an example:
t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a
structure or union
This is a wrong D2 program:
void main() {
alias int Foo;
Foo f;
f = f.x;
}
DMD 2.049 prints:
test.d(4): Error: no property 'x' for type 'int'
But a more useful error message can be:
test.d(4): Error: no property 'x' for type 'Foo' (aka 'int')
Agreed, would be very nive. Have no idea at which stage in the decoding
sequence name aliases are resoved, which certainly determines the difficulty of
implementing the feature.
Anyway, since D's term is 'alias', this term should be used in error messages
instead of 'aka'. Also, 'aka' can be difficult for non-english speakers (have
learnt it myself only recently, after decades of English practice). 'alias'
does not have this issue due to beeing part of D's terminology. However, it
goes in opposite sense, I guess:
test.d(4): Error: no property 'x' for type 'Foo' (alias for 'int')
Or maybe suppleness of English allows the following to be clear?
test.d(4): Error: no property 'x' for type 'Foo' ('int' alias)
Denis
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5593] New: Add dladdr to druntime for linux/FreeBSD
http://d.puremagic.com/issues/show_bug.cgi?id=5593 Summary: Add dladdr to druntime for linux/FreeBSD Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: ibuc...@ubuntu.com --- Comment #0 from Iain Buclaw ibuc...@ubuntu.com 2011-02-15 14:59:17 PST --- Any reason why it isn't present? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5580] [64-bit] String switch statements broken in 64-bit mode
http://d.puremagic.com/issues/show_bug.cgi?id=5580 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-02-15 15:30:18 PST --- I can't reproduce a problem on Ubuntu, and I examined the assembler generated for druntime/src/rt/switch_.d and nothing obviously wrong jumped out at me. One thing you can try on the failing machines is to copy switch_.d into a local directory, compile it with the test case, and verify the failure. Then add some print statements to switch_.d to try and see where it goes wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 David Simcha dsim...@yahoo.com changed: What|Removed |Added Platform|x86_64 |All --- Comment #3 from David Simcha dsim...@yahoo.com 2011-02-15 15:59:13 PST --- I did a little bisecting. This issue appeared in 2.050. It's possible that it's been around since before that but requires different magic numbers on earlier releases, though I doubt it because I would have probably noticed the bug if it was around for a long time. I do my day to day work on Windows but use Linux for the occasional computationally intensive project. I haven't done much serious (i.e. Linux-based) computation since 2.050 was released, but I was doing a lot of it earlier on. The function I isolated this test case from was around in its current form back then and was definitely getting called a lot in those projects. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 --- Comment #4 from David Simcha dsim...@yahoo.com 2011-02-15 16:16:59 PST --- Created an attachment (id=913) Diff of 2.049 vs. 2.050 ASM output. One more hint: Here's a diff of the ASM output for the function body of medianOf3 between 2.049 (test49.asm) and 2.050 (test50.asm). The most notable difference is that in 2.050 the comparison function gets inlined. In 2.049 it doesn't. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 --- Comment #5 from David Simcha dsim...@yahoo.com 2011-02-15 17:25:48 PST --- Unfortunately this appears to be a Heisenbug. When I put print statements in to figure out what's going on and call the switch statement function manually, it starts working. However, the one hint I did get from mucking around in switch_.d is that replacing the memcmp() call with a manual for loop and recompiling druntime solves the problem. Not sure if this is due to the Heisenbug nature of this thing or if it indicates that the memcmp() call is the culprit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 --- Comment #6 from David Simcha dsim...@yahoo.com 2011-02-15 18:10:30 PST --- Ignore the last comment. It was directed to the wrong bug report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5580] [64-bit] String switch statements broken in 64-bit mode
http://d.puremagic.com/issues/show_bug.cgi?id=5580 --- Comment #6 from David Simcha dsim...@yahoo.com 2011-02-15 18:10:56 PST --- Unfortunately this appears to be a Heisenbug. When I put print statements in to figure out what's going on and call the switch statement function manually, it starts working. However, the one hint I did get from mucking around in switch_.d is that replacing the memcmp() call with a manual for loop and recompiling druntime solves the problem. Not sure if this is due to the Heisenbug nature of this thing or if it indicates that the memcmp() call is the culprit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3187] Nested foreach over opApply doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=3187 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords|ice-on-valid-code |diagnostic, rejects-valid --- Comment #2 from Don clugd...@yahoo.com.au 2011-02-15 18:56:15 PST --- (In reply to comment #1) I'm changing this from wrong-code to ICE, since it never reaches code generation. Actually although the compiler fouls this up badly, it isn't an ICE. It's a rejects-valid with a really bad diagnostic. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2011-02-15 21:48:42 PST --- https://github.com/D-Programming-Language/dmd/commit/175bb7540db3ad16655772fe47e4dcbeab7fa380 https://github.com/D-Programming-Language/dmd/commit/cfc773a5bf99b6e636b03644787b71f4acc1c622 This addresses the 64 bit code gen problems, not the 32 bit issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5581] [64-bit] Wrong code with bitwise operations on bools
http://d.puremagic.com/issues/show_bug.cgi?id=5581 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2011-02-15 22:39:38 PST --- Fix for 32 bit code (completely different from 64 bit bug): https://github.com/D-Programming-Language/dmd/commit/52879f36cb28b05813161002d559fecc11a0cbe6 https://github.com/D-Programming-Language/dmd/commit/525de3d38d8202a810352e6811328afa19166591 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4092] broken memory management for COM objects derived from IUnknown
http://d.puremagic.com/issues/show_bug.cgi?id=4092
--- Comment #5 from Rainer Schuetze r.sagita...@gmx.de 2011-02-15 23:18:19
PST ---
Overloading new seems to do the job without the patch in the runtime, so here
is my current implementation of COM objects:
extern (C) void* gc_malloc( size_t sz, uint ba = 0 );
class ComObject : IUnknown
{
new(uint size)
{
void* p = gc_malloc(size, 1); // BlkAttr.FINALIZE
return p;
}
override HRESULT QueryInterface(in IID* riid, void** ppv) { ... }
override ULONG AddRef()
{
LONG lRef = InterlockedIncrement(count);
if(lRef == 1)
GC.addRoot(cast(void*) this);
return lRef;
}
override ULONG Release()
{
LONG lRef = InterlockedDecrement(count);
if (lRef == 0)
GC.removeRoot(cast(void*) this);
return cast(ULONG)lRef;
}
LONG count = 0;// object reference count
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5592] Previous definition different: __arrayExpSliceMulSliceAddass_d
http://d.puremagic.com/issues/show_bug.cgi?id=5592 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-02-15 23:30:31 PST --- The fix is to emit the array functions as COMDATs. https://github.com/D-Programming-Language/dmd/commit/966bf4029137380294b42a797d93b07712e05dbc https://github.com/D-Programming-Language/dmd/commit/15620d4087006f30cfdf1e1a4563f76924620e30 https://github.com/D-Programming-Language/dmd/commit/51e3528883825cc3ab5380acbf9c642b862a6663 https://github.com/D-Programming-Language/dmd/commit/27ae5cfe270226017929fad791d10e8972508697 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
