Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #2038 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

dmds new release: runtime interface + 64 bit

Reported by: Marenz Assigned to: community
Priority: major Milestone: 1.0
Component: Tango Version: trunk
Keywords: Cc:

Description (Last modified by Marenz)

The new release of dmd changed the interface for the runtime, thus many of tangos code doesn't work anymore.

Originally I only wanted to make 64 bit mode work, but those fixes need to be done for the 32 bit parts, too.

Currently 3(actually just two) unittests fail in both 64 and 32 bit mode, as well as the stacktrace function itself, which only displays a local stack (the first line of the error).

Attachments

tango-dmd64.patch (27.2 kB) - added by Marenz on 02/11/11 19:55:40.
more work on 64bit dmd
Thread.d.64bit.patch (3.5 kB) - added by Marenz on 02/15/11 17:46:17.
replaced inout with ref
64Bit.patch (75.2 kB) - added by Marenz on 02/17/11 18:26:40.
added talign to TypeInfo? and in the compiler dependent files
64Bit.2.patch (75.3 kB) - added by Marenz on 02/17/11 18:53:45.
synced with newest rev
64Bit.3.patch (126.3 kB) - added by Marenz on 02/17/11 19:53:42.
all but a few things patched
64Bit.4.patch (144.8 kB) - added by Marenz on 02/18/11 13:39:19.
Fixed compilation errors in deh.d
64Bit.5.patch (87.8 kB) - added by Marenz on 02/18/11 14:13:18.
removed whitespace diffs, implemented the _aa* functions (not tested yet)
64Bit.6.patch (104.1 kB) - added by Marenz on 02/18/11 20:45:54.
successfully compiles and links now, unittest does no longer segfault, but simply outputs nothing and exits with code 1. A simple test program does segfault.
64Bit.7.patch (104.2 kB) - added by Marenz on 02/18/11 20:53:31.
forgot a change
64Bit.8.patch (109.0 kB) - added by Marenz on 02/19/11 11:02:57.
further changes. can't recall what.
64Bit.9.patch (112.4 kB) - added by Marenz on 02/21/11 16:56:06.
and more changes.
64Bit.10.patch (114.7 kB) - added by Marenz on 02/21/11 18:25:56.
some debugging output, and forgot a complation error
64Bit.11.patch (124.9 kB) - added by Marenz on 02/23/11 15:31:24.
arraycatnT had some more version(X86) else which I missed because he didn't use X86_64 but just "else". Took me 2 days to find this one. and I fixed a strange bug in the GC. I don't understand how 64bit worked with other compilers if my if is really correct. check it out.
64Bit.12.patch (127.4 kB) - added by Marenz on 02/23/11 19:20:19.
added argTypes where it was missing, only for dmd so far
64Bit.13.patch (141.1 kB) - added by Marenz on 03/02/11 15:07:06.
found some more missing version()s. Fixed tango layout class. unittests run up to a certain point.
64Bit.14.patch (145.3 kB) - added by Marenz on 03/02/11 17:45:05.
fixed all segfaults that happened when running the unittests
64Bit.15.patch (159.0 kB) - added by Marenz on 03/04/11 19:41:44.
Fixed unittest for Layout.d
64Bit.16.patch (158.4 kB) - added by Marenz on 03/07/11 10:15:15.
assimilated patch to phobos, reenabled asserts/unittests for layout.d
64Bit.17.patch (164.2 kB) - added by Marenz on 03/14/11 12:55:46.
Fixed Process unittest .. but no idea how.
64Bit.18.patch (169.5 kB) - added by Marenz on 03/30/11 15:22:29.
Fixed the failing unittest for sys.HomeFolder? and an internal one of the runtime. The last three failing tests are actually just two because one is dependent on the other. The first is in math.Probability and I have no idea about that stuff, so someone who does might want to check that. The the other one is in regex, I didn't look to closely at that one yet.
64Bit.19.patch (171.4 kB) - added by Marenz on 04/12/11 21:57:24.
took care of the last remaining things. should be ready to commit now

Change History

02/11/11 15:44:29 changed by fawzi

Well the first thing is avoiding passing -m32 to the C compiler in bob. I used a script in the meantime. I just began making the first changes, but it is still quite a bit to do and to check. One should be sure not to miss changes to phobos/dmd that should be transferred to tango, some changes began quite some time ago, and were not done to tango because nobody tracks dmd releases yet. I attach my actual changes, if someone wants to use them as base to build a complete patch.

02/11/11 15:52:24 changed by doob

If you remove -m32 from the C compiler what happens then when someone with a 64bit G compiler tries to build Tango with a 32bit DMD. It won't work. Maybe there should be a switch to build 32bit Tango on a 64bit system (would that be cross compiling?). BTW what's the reason for "alias size_t wordtype;"?

02/11/11 17:15:09 changed by Marenz

the binary bob version doesn't seem to pass -m32 to the compiler. I just used -o"-m64"

(follow-up: ↓ 5 ) 02/11/11 17:41:52 changed by Marenz

I am not that confident in my patch, someone might check over it

02/11/11 19:55:40 changed by Marenz

  • attachment tango-dmd64.patch added.

more work on 64bit dmd

(in reply to: ↑ 4 ) 02/12/11 13:23:13 changed by doob

Replying to Marenz:

I am not that confident in my patch, someone might check over it

I think you should use "ref" instead of "inout".

02/12/11 14:25:55 changed by Marenz

Uh. I guess the copied code had inout, because I never use it. Will check over it on Monday.

Main problem right now is the fact, that the druntime code uses object.talign which tango doesn't have. Should we implement it or can the druntime code be rewritten to not use it?

02/15/11 17:46:17 changed by Marenz

  • attachment Thread.d.64bit.patch added.

replaced inout with ref

02/15/11 18:09:42 changed by fawzi

the talign changes are not compiler specific they can be easily ported one should "correct" the typeinfo of the various compilers, and their object.d basically typeinfo has a field more with the aligment info

at compile time the aligment is known, so one can easily put size_t.sizeof as default and then in specifice typeinfo override it with the alignof of that type I haven't looked at the details but it shoudl be rather straightforward to do for all compilers, so that one has a single object.di without version(xxx) in it

02/17/11 18:26:40 changed by Marenz

  • attachment 64Bit.patch added.

added talign to TypeInfo? and in the compiler dependent files

02/17/11 18:53:45 changed by Marenz

  • attachment 64Bit.2.patch added.

synced with newest rev

02/17/11 19:53:42 changed by Marenz

  • attachment 64Bit.3.patch added.

all but a few things patched

02/17/11 19:56:54 changed by Marenz

I fixed all but two errors. Anyone an idea how to fix those?

dmd -c -I./tango/core -I. -I./tango/core/vendor -m64 -version=WithDateTime? -oftango-core-rt-compiler-dmd-rt-lifetime-m64--version-WithDateTime?.o ./tango/core/rt/compiler/dmd/rt/lifetime.d ./tango/core/rt/compiler/dmd/rt/lifetime.d(339): Error: e2ir: cannot cast foo(ti,pdim,ndims) of type void[] to type ulong ./tango/core/rt/compiler/dmd/rt/lifetime.d(398): Error: e2ir: cannot cast foo(ti,pdim,ndims) of type void[] to type ulong

02/18/11 02:14:33 changed by sleets

also need fix the _d_arrayliteralTX issue .

I build bob catch this:

/home/opt/dmd1/bin/../lib/libtango.a(tango-sys-Process-release.o): In function `_D5tango3sys7Process7Process4argsMFAaAAaXAAa':
../tango/sys/Process.d:(.text._D5tango3sys7Process7Process4argsMFAaAAaXAAa+0x1b): undefined reference to `_d_arrayliteralTX'
/home/opt/dmd1/bin/../lib/libtango.a(tango-sys-Process-release.o): In function `_D5tango3sys7Process7Process7executeMFAaAAaXv':
../tango/sys/Process.d:(.text._D5tango3sys7Process7Process7executeMFAaAAaXv+0x1b): undefined reference to `_d_arrayliteralTX'
/home/opt/dmd1/bin/../lib/libtango.a(tango-time-chrono-Gregorian-release.o): In function `_D5tango4time6chrono9Gregorian9Gregorian4erasMFZAk':
../tango/time/chrono/Gregorian.d:(.text._D5tango4time6chrono9Gregorian9Gregorian4erasMFZAk+0x10): undefined reference to `_d_arrayliteralTX'
/home/opt/dmd1/bin/../lib/libtango.a(tango-time-chrono-Hebrew-release.o): In function `_D5tango4time6chrono6Hebrew6Hebrew4erasMFZAk':
../tango/time/chrono/Hebrew.d:(.text._D5tango4time6chrono6Hebrew6Hebrew4erasMFZAk+0x12): undefined reference to `_d_arrayliteralTX'
/home/opt/dmd1/bin/../lib/libtango.a(tango-time-chrono-Hijri-release.o): In function `_D5tango4time6chrono5Hijri5Hijri4erasMFZAk':
../tango/time/chrono/Hijri.d:(.text._D5tango4time6chrono5Hijri5Hijri4erasMFZAk+0x12): undefined reference to `_d_arrayliteralTX'
collect2: ld returned 1 exit status
--- errorlevel 1

02/18/11 13:39:19 changed by Marenz

  • attachment 64Bit.4.patch added.

Fixed compilation errors in deh.d

02/18/11 13:50:55 changed by Marenz

newest patch contains some hacks for unittest and bob to build 64 bit. I will do that properly once everything works.

@sleets: it's way more than just _d_arrayliteralTX. In detail, what is missing is:

_aaDelX
_aaGetRvalueX
_aaGetX
_aaInX
_d_arrayappendcTX
_d_arrayliteralTX
_d_assocarrayliteralTX
_memsetDouble
_memsetFloat

I'll see what they did in phobos for that and copy it over.

02/18/11 14:13:18 changed by Marenz

  • attachment 64Bit.5.patch added.

removed whitespace diffs, implemented the _aa* functions (not tested yet)

02/18/11 20:45:54 changed by Marenz

  • attachment 64Bit.6.patch added.

successfully compiles and links now, unittest does no longer segfault, but simply outputs nothing and exits with code 1. A simple test program does segfault.

02/18/11 20:53:31 changed by Marenz

  • attachment 64Bit.7.patch added.

forgot a change

02/19/11 11:02:57 changed by Marenz

  • attachment 64Bit.8.patch added.

further changes. can't recall what.

02/21/11 16:56:06 changed by Marenz

  • attachment 64Bit.9.patch added.

and more changes.

02/21/11 16:57:37 changed by Marenz

Normal Cout("test"); works, throwing and catching an exception works also.

The big unittesting of tangos fails though. I don't know why, because it just outputs nothing but also doesn't segfault.

What does segfault is using Stdout. I try now to locate problematic modules and investigate why they fail.

02/21/11 18:25:56 changed by Marenz

  • attachment 64Bit.10.patch added.

some debugging output, and forgot a complation error

02/21/11 18:30:35 changed by Marenz

The following is a small example program that causes a crash. I think it happens while calling rt_finalize

module main;

import tango.io.Console;

void main ( )
{
    char[] test = new char[2000000];
}

going to check the GC changes

02/23/11 15:31:24 changed by Marenz

  • attachment 64Bit.11.patch added.

arraycatnT had some more version(X86) else which I missed because he didn't use X86_64 but just "else". Took me 2 days to find this one. and I fixed a strange bug in the GC. I don't understand how 64bit worked with other compilers if my if is really correct. check it out.

02/23/11 18:50:39 changed by Marenz

Okay, current problem is something with vararg. I made a simple test program that fails:

module main;

//import tango.io.Console;
//import tango.io.Stdout;

import tango.stdc.stdio : printf;
import tango.core.Vararg;

void vararg ( ... )
{
    printf(" ############# vararg: %llx\n", _argptr);
    printf(" ############# *vararg: %llx\n", *cast(int*)_argptr);
    
}

void normalarg( int t)
{
    printf(" ############# normalarg: %llx\n", &t);
    printf(" ############# *normalarg: %llx\n", t);

}

void main ( )
{
    int test = 524;
    printf(" ############# test: %llx\n", &test);
    printf(" ############# *test: %llx\n", test);

    vararg(test);
    normalarg(test);
}

Output is

 ############# test: 7fff0615f118
 ############# *test: 20c
 ############# vararg: 7fff0615f0d0
 ############# *vararg: 8
 ############# normalarg: 7fff0615f0f8
 ############# *normalarg: 20c

02/23/11 19:20:19 changed by Marenz

  • attachment 64Bit.12.patch added.

added argTypes where it was missing, only for dmd so far

02/25/11 01:42:46 changed by sleets

The d_arrayliteralTX is still missing in win32 .

(follow-up: ↓ 16 ) 02/27/11 01:33:14 changed by ibuclaw

(Posting again as first time went wrong).

I'm just going to note that these runtime functions have changed in GDC:

In gdc/rt/aaA.d
Old:
BB* _d_assocarrayliteralTp(TypeInfo_AssociativeArray ti, size_t length, void* keys, void* values)
New:
BB* _d_assocarrayliteralTp(TypeInfo_AssociativeArray ti, void[] keys, void[] values)

In gdc/rt/lifetime.d
Old:
byte[] _d_arrayappendcTp(TypeInfo ti, ref byte[] x, void *argp)
New:
byte[] _d_arrayappendcTp(TypeInfo ti, inout byte[] x, size_t n)


And newly added runtime function:
void* _d_arrayliteralTp(TypeInfo ti, size_t length)

Implementations same as DMD.

Regards

(in reply to: ↑ 15 ) 02/28/11 17:28:47 changed by Marenz

Replying to ibuclaw:

(Posting again as first time went wrong). I'm just going to note that these runtime functions have changed in GDC: {{{ In gdc/rt/aaA.d Old: BB* _d_assocarrayliteralTp(TypeInfo?_AssociativeArray ti, size_t length, void* keys, void* values) New: BB* _d_assocarrayliteralTp(TypeInfo?_AssociativeArray ti, void[] keys, void[] values) In gdc/rt/lifetime.d Old: byte[] _d_arrayappendcTp(TypeInfo? ti, ref byte[] x, void *argp) New: byte[] _d_arrayappendcTp(TypeInfo? ti, inout byte[] x, size_t n) And newly added runtime function: void* _d_arrayliteralTp(TypeInfo? ti, size_t length) }}} Implementations same as DMD. Regards

Are you sure that You got all? What about all the *X functions that were added? Maybe they are only for the 64 bit version...

03/02/11 15:07:06 changed by Marenz

  • attachment 64Bit.13.patch added.

found some more missing version()s. Fixed tango layout class. unittests run up to a certain point.

03/02/11 15:14:29 changed by Marenz

The unittest runs now till it segfaults.. and there is a problem when displaying the stacktrace for each failed unittest..

http://paste.dprogramming.com/dpf2y4pa

I will first fix all the segfaults, then all the asserts. If some one can fix the stacktrace problem, I would appreciate it.

03/02/11 17:45:05 changed by Marenz

  • attachment 64Bit.14.patch added.

fixed all segfaults that happened when running the unittests

03/02/11 18:56:30 changed by Marenz

  • description changed.
  • summary changed from make tango work with 64bit dmd to dmds new release: runtime interface + 64 bit.

03/03/11 17:03:20 changed by Marenz

Current status: I think I got most things working. The failing unittests are still to fix (and sometimes I neither see a stacktrace nor the assert that triggered, so it's not always easy to fix).

One big mess is basically everything that uses varargs. The 64bit api is different from the 32bit api. You can't use _argptr directly anymore but are forced to use the va_* functions. This is particular ugly for all the layoutfunctions because you have to init va_start with a special variable _va_argsave which is only avaliable in the function that had the "..." (But only in 64 bit!). So you have to va_start and va_end in that function. As layout converts everything to a void*[], you have to have several versions for various compilers and architectures.

I have added many functions to the other compiler-runtimes, too, but I couldn't test them, so if someone with ldc/gdb/dmd and windows/linux (64/32bit) feels inclined to contribute: TEST STUFF!

I know that some are still missing for the other compilers than dmd and will take care of those.

Fawzi suggests to use variadic templates instead of varargs here http://dsource.org/projects/tango/ticket/1042 . The call would be the same, the usage a little different. You would define/mixin a template in front of your variable function and your function could simply get an array of Variant[] or another fixed/defined way. That way you could also just forward the Variant-Varargs to other Variant-vararg functions

Oh yes, variants toVarargs function is also broken on x86_64 now. And I don't even know how to fix it, if it is possible at all.

I start liking fawzis suggestion more. Each time I work with varargs, a little more.

I'd love to get some more input from you guys.

03/03/11 17:32:37 changed by Marenz

Some examples of how the template usage could look like:

void func(...) 
{
    mixin Vararg;   
 /* now available:  
varArg.arguments  -> void*[] and   
vararg.types -> TypeInfo[] 
*/ 
}
// or the other suggestion:

 mixin Vararg!(&original_function);   
void original_function(uint something, VarArgs args, VarTypes types) {.. }

The first one is less easy to implement, but looks more elegant to the user and it still uses varargs, just transforms them to something that can be used the same way everywhere. Any compiler dependent stuff would be hidden.

The second one would just remove varargs and replaces them with a template that gets mixed in.

03/04/11 13:19:16 changed by Marenz

The failing testcase of Layout.d is actually dmd/phobos fault, see http://d.puremagic.com/issues/show_bug.cgi?id=5694

03/04/11 18:12:27 changed by Marenz

The still failing testcase of Layout.d (after turning the previously triggering asserts off) is also dmd/phobos fault: http://d.puremagic.com/issues/show_bug.cgi?id=5698

03/04/11 19:41:44 changed by Marenz

  • attachment 64Bit.15.patch added.

Fixed unittest for Layout.d

03/04/11 19:54:27 changed by Marenz

  • description changed.

The unittest for layout now runs successfully (after turning of the asserts concerning the before-mentioned tickets).

The backtrace is always one line because the c-backtrace function that is being used only manages to extract one frame. My guess is that dmd fucks something up here and I bet it's the same as it is for the gdb errors. There is already a ticket for that, but I've seen no progress there so far

03/07/11 10:13:35 changed by Marenz

The first bug in dmd & phobos is fixed, which means that I reenabled the according asserts in Layout.d. See new patch. Glad this is going forward.

03/07/11 10:15:15 changed by Marenz

  • attachment 64Bit.16.patch added.

assimilated patch to phobos, reenabled asserts/unittests for layout.d

03/14/11 12:55:46 changed by Marenz

  • attachment 64Bit.17.patch added.

Fixed Process unittest .. but no idea how.

03/14/11 12:57:07 changed by Marenz

  • description changed.

03/30/11 15:22:29 changed by Marenz

  • attachment 64Bit.18.patch added.

Fixed the failing unittest for sys.HomeFolder? and an internal one of the runtime. The last three failing tests are actually just two because one is dependent on the other. The first is in math.Probability and I have no idea about that stuff, so someone who does might want to check that. The the other one is in regex, I didn't look to closely at that one yet.

03/30/11 15:24:09 changed by Marenz

  • description changed.

04/02/11 22:23:19 changed by mwarning

I have looked into the unittest failure in IEEE.d. Here is a small test case:

import tango.math.IEEE;
void main() {
assert(feqrel(real.min/8,real.min/17)==3);
}

The assert is hit using "dmd -m64 test.d && ./test", but vanishes when used with -O and/or -release. -m32 makes it works as well. Phobos for D2 has the same unittest and feqrel implementation. I have tested dmd.2.052 and it has the same problem with -m64 vs -m32.

There might be a dmd ticket already. So far it's a dmd issue. A hotfix would be to add a dummy function call before "if (pd[F.EXPPOS_SHORT] == 0)".

04/04/11 05:00:41 changed by mwarning

http://d.puremagic.com/issues/show_bug.cgi?id=5809

I couldn't reproduce the failure in tango.math.Probability, but it may be the same bug. No idea about the regex issue.

Funny enough, ldc has the exact same 3 unittest failures. To me, it looks like the patch is ready to commit, as the remaining bugs are likely dmd (frontend) bugs.

04/04/11 16:53:28 changed by Marenz

@mwarning: I am pretty sure it is the same bug in Probability. Thanks for having a look at that :)

04/12/11 21:57:24 changed by Marenz

  • attachment 64Bit.19.patch added.

took care of the last remaining things. should be ready to commit now

04/13/11 07:48:50 changed by Marenz

ah no, I forgot to add the interface changes for the other compilers. Gotta do that this evening

04/15/11 11:27:27 changed by Marenz

gdc is more work than I thought. My vararg changes for the new dmd interface broke gdc at all those parts. I created a new branch dmd-1.067 (okay, unlucky name) and applied all my changes there.

as just mentioned, gdc breaks at several parts. Compile it with

PATH=/home/mathias/gdc-bin/usr/local/bin/:$PATH build/bin/linux32/bob -r=gdc -l=libtango-gdc -c=gdc -o="-fversion=WithDateTime? -m64" .

and see yourself (path being where your gdc is located at). I couldn't test ldc so far as I lack the proper llvm version. But I'll get to that.

05/03/11 13:18:07 changed by mwarning

unittest regressions in branches/dmd-1.067 r5651:
DC=ldc PLATFORM=linux ARCH=64 build/script/unittest.sh

  • tango.core.Variant
  • tango.text.convert.Layout

05/05/11 20:29:05 changed by ArKay

Is there any reason why the following code shouldn't build? It breaks functionality in mango which compiled and worked with tango in trunk. I'm new to D so I'm not really familiar with inout yet.

import tango.net.http.HttpConst;

class HttpTest {
	this() {
		
	}
	
	void sendError (inout HttpStatus status) {
	}
}

void main(char[][] args) {
	auto test = new HttpTest();
	test.sendError(HttpResponses.NotFound);
}

src/main.d(14): Error: cannot modify final variable 'NotFound?'

05/05/11 20:45:25 changed by ArKay

There's another error in my application I can't explain. If the source as above gets modified like this...

import tango.net.http.HttpConst;

private import	tango.util.container.HashMap;

class HttpTest {
	private static const HashMap!(char[], void*) handlers;

	static this() {
		handlers = new HashMap!(char[], void*)();
	}
	
	void makeError () {
		sendError(HttpResponses.NotFound);
	}
	
	void sendError (inout HttpStatus status) {
	}
}

void main(char[][] args) {
	auto test = new HttpTest();
}

I suddenly get 2 compilation errors:

src/main.d(13): Error: cannot modify final variable 'NotFound'
/opt/dmd/bin/../import/tango/util/container/HashMap.d(155): Error: function tango.util.container.HashMap.HashMap!(char[],void*).HashMap.Iterator.opApply (int delegate(ref char[] key, ref void* value)) does not match parameter types (_error_ delegate(ref char[] k, ref void* v))
/opt/dmd/bin/../import/tango/util/container/HashMap.d(155): Error: cannot implicitly convert expression (__dgliteral1) of type _error_ delegate(ref char[] k, ref void* v) to int delegate(ref char[] key, ref void* value)

Now it also complains about the HashMap?. If I comment out the sendError() call inside makeError() _both_ errors are gone. How could they be related?

05/06/11 06:43:43 changed by doob

I would guess the compiler has become more strict. I would guess it will work if you remove "inout". "inout" is the old keyword for a reference parameter ("ref" is the one you want to use), it behaves just like a reference parameter in C++.

If you declare a parameter as "ref" then it will be possible to change the parameter and it will be visible for the caller. Example:

void foo (ref int i)
{
  i = 4;
}

int a = 3;

foo(a);
assert(a == 4);

The two fields in HttpStatus are declared as final, I don't know if that is still valid.

(follow-up: ↓ 37 ) 05/06/11 08:30:46 changed by ArKay

They are final in HttpStatus?, that's correct. Before I switched from trunk to the 1.067 tango branch that piece of code (which in this form is used in mango) compiled and worked.

To my understanding inout can be used when you have a method which takes a parameter in various mutations(immutable, const, ...) and returns a value of the same kind.

Instead of having to write those two (in C++):

const char* someStringMethod(const char* text); char* someStringMethod(char* text);

you can write in D:

inout(char)* (inout(char)* text);

Maybe that's just a basic use case though... I will have to modify the mango code then. It's not really compatible with tango at the moment.

Thanks, Rainer

(in reply to: ↑ 36 ) 05/08/11 17:23:39 changed by doob

Replying to ArKay:

To my understanding inout can be used when you have a method which takes a parameter in various mutations(immutable, const, ...) and returns a value of the same kind.

Yes, that's how it works in D2.

05/14/11 16:45:16 changed by ArKay

Another DMD update, another incompatibility? Just switched from Linux to Windows so I installed the shiny 1.068 which came out 2 days ago.

C:\D\dmd\windows\bin\..\import\tango\core\sync\Atomic.d(480): opcode expected, not cmpxch8b

Probably related to this little change?

- Fix spelling of cmpxchgb8

05/14/11 17:08:26 changed by ArKay

Of course he also misspelled it in the Changelog, it should be "cmpxchg8b" :)

Both Atomic.ds have to be fixed.

05/20/11 14:45:12 changed by mwarning

  • status changed from new to closed.
  • resolution set to fixed.

I've moved that spelling bug into another ticket, see #2052.

The dmd-1.067 branch was merged in [5652]. I think we can close this one now.