www.digitalmars.com         C & C++   DMDScript  

D.gnu - GDC for x86_64!

reply Gregor Richards <Richards codu.org> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

(I'm dual-posting this to both D.gnu and digitalmars.D, since it's at 
least somewhat relevent in both)

I've made a (mostly untested) port of GDC 0.19 to x86_64.

This required numerous patches to the frontend, and a few less patches 
to phobos.  I have another thread in digitalmars.D complaining about the 
phobos patches.

Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
done some very simple "does this work at all" tests.

  - Gregor Richards

PS: I've only tested this on an emulated x86_64 system

PPS: I've only tested this with --disable-multilib, as I was on a Debian 
system
Sep 20 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gregor Richards wrote:

 I've made a (mostly untested) port of GDC 0.19 to x86_64.
 
 This required numerous patches to the frontend, and a few less patches 
 to phobos.  I have another thread in digitalmars.D complaining about the 
 phobos patches.
 
 Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
 done some very simple "does this work at all" tests.

Sounds fun, I'm going to try it on PPC64. Attaching missing platform.
 PS: I've only tested this on an emulated x86_64 system

I am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system. --anders
Sep 21 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 I've made a (mostly untested) port of GDC 0.19 to x86_64.


Also at http://www.algonet.se/~afb/d/gdc-0.19-x86_64-3.patch
 Sounds fun, I'm going to try it on PPC64. Attaching missing platform.

Updated the PPC64 patch with some more Phobos fixes/workarounds. Latest is at http://www.algonet.se/~afb/d/gdc-0.19-ppc64.patch --anders
Sep 21 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Anders F Björklund wrote:
 Gregor Richards wrote:
 
 I've made a (mostly untested) port of GDC 0.19 to x86_64.

 This required numerous patches to the frontend, and a few less patches 
 to phobos.  I have another thread in digitalmars.D complaining about 
 the phobos patches.

 Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
 done some very simple "does this work at all" tests.

Sounds fun, I'm going to try it on PPC64. Attaching missing platform.
 PS: I've only tested this on an emulated x86_64 system

I am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system. --anders

Anders, could you do me a favour? I'd love to know what the following prints on a PowerPC CPU (and on x86-64, for that matter). It would be a great help for math library portability. It's amazingly hard to find documentation on this stuff. - Don. --------- import std.stdio; void show(double x) { writefln("%f %08x", x, *cast(ulong*)&x); } void main() { double x = double.init; double zero = 0.0; show(x); x = real.nan; show(x); ulong *p = cast(ulong *)&x; *p = 0xFFFF_FFFF_FFFF_FFFF; show(x); float f = x*5.2f; show(f); *p = 0xFFFF_ABCD_9876_FFFF; show(x); f = x; show(f); x = 35.61; x /= zero; show(x); x *= zero; show(x); x = 56.37; double y = x % zero; show(y); x = -y; show(x); }
Sep 21 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:

 Anders, could you do me a favour? I'd love to know what the following 
 prints on a PowerPC CPU (and on x86-64, for that matter). It would be a 
 great help for math library portability. It's amazingly hard to find 
 documentation on this stuff. - Don.

Here you go: (PPC) nan 7ff8000000000000 nan 7ff8000000000000 nan ffffffffffffffff nan ffffffffe0000000 nan ffffabcd9876ffff nan ffffabcd80000000 inf 7ff0000000000000 nan 7ff8000000000000 nan 7ff8000000000009 nan fff8000000000009 BTW "real" and "double" are the same size here. --anders
Sep 21 2006
parent Don Clugston <dac nospam.com.au> writes:
Anders F Björklund wrote:
 Don Clugston wrote:
 
 Anders, could you do me a favour? I'd love to know what the following 
 prints on a PowerPC CPU (and on x86-64, for that matter). It would be 
 a great help for math library portability. It's amazingly hard to find 
 documentation on this stuff. - Don.

Here you go: (PPC) nan 7ff8000000000000 nan 7ff8000000000000 nan ffffffffffffffff nan ffffffffe0000000 nan ffffabcd9876ffff nan ffffabcd80000000 inf 7ff0000000000000 nan 7ff8000000000000 nan 7ff8000000000009 nan fff8000000000009

Thanks! That's fascinating, the last two lines is a real surprise (totally different to the x86 behaviour). Where the heck did that '9' come from??
 BTW "real" and "double"
 are the same size here.

Yes, that's part of the reason for my interest in it. It's BigEndian too, isn't it?
 If you are doing further development, the easiest is
 probably to get a full PowerPC emulator environment ?

 Like this one, for instance: http://pearpc.sf.net/

I know about PearPC, but what I was testing just then is the least likely part of the CPU emulation to be tested properly; I reckon that if they got that wrong, it wouldn't break any code. (I bet it doesn't give those '9's).
Sep 21 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:

 It would be a great help for math library portability.
 It's amazingly hard to find documentation on this stuff.

If you are doing further development, the easiest is probably to get a full PowerPC emulator environment ? Like this one, for instance: http://pearpc.sf.net/ --anders
Sep 21 2006
prev sibling next sibling parent Vincenzo Ampolo <vincenzo.ampolo gmail.com> writes:
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2006-09-20 at 21:43 -0700, Gregor Richards wrote:
 I've made a (mostly untested) port of GDC 0.19 to x86_64.

Good work! thanks Gregor! --=20 Vincenzo Ampolo http://www.nanofreesoft.org http://vincenzoampolo.nanofreesoft.org http://idp.nanofreesoft.org
Sep 21 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregor Richards schrieb am 2006-09-21:
 (I'm dual-posting this to both D.gnu and digitalmars.D, since it's at 
 least somewhat relevent in both)

 I've made a (mostly untested) port of GDC 0.19 to x86_64.

 This required numerous patches to the frontend, and a few less patches 
 to phobos.  I have another thread in digitalmars.D complaining about the 
 phobos patches.

 Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
 done some very simple "does this work at all" tests.

   - Gregor Richards

 PS: I've only tested this on an emulated x86_64 system

tested compiler: gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9) (gdc 0.19, using dmd 0.162) Additional fix:
 d/phobos/internal/mars.h:31: unsigned monitor;

I had to disable some code in the following files due to "internal compiler error: in copy_to_mode_reg, at explow.c:691" "internal compiler error: in emit_move_insn, at expr.c:2830" "internal compiler error: in expand_expr_real, at expr.c:6525" d/phobos/std/file.d d/phobos/std/string.d d/phobos/std/regexp.d d/phobos/std/format.d d/phobos/std/zip.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFElsnLK5blCcjpWoRAvwPAJ4285GvafSzN9Jc7Te+j04MbaoSmwCfVbro xPAsQIq/IokZQsB7QgWGbts= =reBj -----END PGP SIGNATURE-----
Sep 21 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:

 I had to disable some code in the following files due to
 "internal compiler error: in copy_to_mode_reg, at explow.c:691"
 "internal compiler error: in emit_move_insn, at expr.c:2830"
 "internal compiler error: in expand_expr_real, at expr.c:6525"
 
 d/phobos/std/file.d
 d/phobos/std/string.d
 d/phobos/std/regexp.d
 d/phobos/std/format.d
 d/phobos/std/zip.d

Did you have a patch for those ? Think I saw the same on PPC64, for the std.string "abbrev" but didn't encounter the others... I just did a version() and a assert(0), to disable ICE sections: version (PPC64) { assert(0); // "internal compiler error: in copy_to_mode_reg, at explow.c:581" } else Think you could do the same workaround for the five issues above ? (depending on whether it was in a commonly used function or not...) --anders
Sep 21 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am 2006-09-21:
 Thomas Kuehne wrote:

 I had to disable some code in the following files due to
 "internal compiler error: in copy_to_mode_reg, at explow.c:691"
 "internal compiler error: in emit_move_insn, at expr.c:2830"
 "internal compiler error: in expand_expr_real, at expr.c:6525"
 
 d/phobos/std/file.d
 d/phobos/std/string.d
 d/phobos/std/regexp.d
 d/phobos/std/format.d
 d/phobos/std/zip.d

Did you have a patch for those ? Think I saw the same on PPC64, for the std.string "abbrev" but didn't encounter the others... I just did a version() and a assert(0), to disable ICE sections: version (PPC64) { assert(0); // "internal compiler error: in copy_to_mode_reg, at explow.c:581" } else Think you could do the same workaround for the five issues above ? (depending on whether it was in a commonly used function or not...)

std.string and std.regexp would be empty shells. internal compiler error: in copy_to_mode_reg, at explow.c:691 # void foo(){ # char[] x = new char[2]; # size_t i = 1; # # char c = x[i]; # x[i+1] = c; # } b.d:5: error: unrecognizable insn: (insn 19 18 22 0 (parallel [ (set (reg:SI 58) (plus:DI (reg:DI 61) (const_int -1 [0xffffffffffffffff]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (expr_list:REG_DEAD (reg:DI 61) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)))) b.d:5: internal compiler error: in extract_insn, at recog.c:2083 # void bar(){ # char* p; # size_t len = std.string.strlen(p); # } Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFFIzeLK5blCcjpWoRAtFUAJsGNp701A5NT44iWL98YFYxIFRBlgCgq2Ac p7lWA/l0xH5EMkkteaCgXHo= =Gm1V -----END PGP SIGNATURE-----
Sep 22 2006
parent =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
Content-Type: multipart/mixed;
 boundary="------------070807010503030604040807"

This is a multi-part message in MIME format.
--------------070807010503030604040807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The attachment contains DStress light[1] results for dgcc-r19 with
Gregor's patch applied.

gcc:
3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9) (gdc 0.19, using dmd
0.166)

configure:
 --enable-languages=3Dc,d
 --enable-checking=3Dmisc,tree,gc,rtl,rtlflag,fold,gcac


Thomas


[1] cc1d -g -c test_case.d 2>&1 | grep "internal compiler error"

--------------070807010503030604040807
Content-Type: application/x-gzip;
 name="log.txt.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="log.txt.gz"

H4sICDaaFUUCA2xvZy50eHQA7Z3LkqM2FIYr2zyFd51UzQx3sHvXYHfPJffZZaPCINtUY+QS
YrqdN8guj5NlquaRsskyksAYbLexQVRSg2qma8am9SF+DkfS0ZEI0HoTxVCZK/NsCYJlgEKg
mRMH3OlvwlvNuB1FCYE48eNRkP8qHkGMEWYH6FebLSAIrFEIAYbLVyOfjODzJkZPb4Jbe6J9
HbzEd3vmez3zpz3z7zlfF8UPYQyXPoFAMxh3fIb7ES7XMCE+iVAyWvhZTErKQlkgDP1gBQwV
3FGQrgsAuQykdQA9+Tikl7+AGCYBu0ReN80RiuS1NIUivQ5IpKCN5xOgc8zIpyj1DOlujjCB
4ani0yuKJ+jIYFNgWGYuuH2GQDCEo2AFg8dbZqEwoLhREPtpOrohN69GK/8THN0834y+4QXA
2seP3zIbn2dRHIIN4mRAthsIFuw4NXlu7gxMjd2wDePl6rlN9vCfVI+gIN2u6fOuNz9M9FQh
oDXzE/4P5vBQCV8v44yegJ7BMbRzZ3CbztBagkqtqH378c4LYXrdjmbY52rl/S9rNRV+Nygf
6hEG+mTS7JxOXjMmcXEqfsl/f14sFn/kP+zv4Wftr8/7DyeOv/39n8o3x7/f9PmQ9+dXVdHp
T0rWZK8N+0SF142xWZElUPidBHphCMZ1vvAkaNYJVLaTqnGBDaTRehNHiy1YwgSk2XzXBO++
f43JM3v4Lds+eQ6r/3NoWm/noH+SbA1Mh/mWFk3IvrzXsfysY/mHjuXftypPewVZEjAzBOqY
eYVGxlnTrePcrjjWQ/iYze/SNFomQLusgscXeYRxxWBmYjD3rTCpkka/QbQAmt3yelKmekBv
VFMvv2v7hyHJcFL1wUa98SOQPuPcG42bRgaDaZfIXpV8oNPiDtcZrgCGJ4AxFcCYtWWsohRo
HepQlG99fto5DyF9aLX2t3SPcLsjvA6IKFkgoGrdm406btoWh7NEoR1gyHq6OWyS1y0MUXLw
/a9NoZMv3NEwrfw48lOgOq3GzV+WFPnwS1dVS7Xo480ij6P60Gx/TJOmc6iJd0YvT+p1pNdU
2tclehWxaNt2moN7F4WiT6Ld/tBef+hpf+iZYHQIKBqycb2m6+Nc7ytj7S/CPJGwmUjYvUjY
g0jYO5Gw9yJhH7rBIB2UYn4MmGY+O2QIo7lCaV4nGo/jaqbVPKlwGcZranKaMY5h5zHrHqc4
1pCsqJPiMxxhhGnxeFub4Zhok6N6OUU8Vu2jXkVlNhitEYEp9YhlGD72kyULw2umoVYqxds9
1s7lTZou2/mqJq7U5EgTT2pypMlUalJqQv1R7G9RRoAxzmdxje7R3JD6ujKWzxov7u6K87DP
RZUQfp1/ydzvWM8rlg9nTNqk29x6LWvgd6oqCDNdS5eClIKw1tkypSA8AqDp4+ZEjKEJ0pid
NSRBjCJdTZtIQcp8FlfGzFgCik+CFVCt3IOo14/nKgi3O4Ln00w6IRpHlM0IPvizOiHuuyMe
ul/I2/Z3JETZPIbFXN15V3pxbK+CtZvc0TXQRYx8AlRdbFULqtCa7tK9prJ52sthDT638EAO
V8pRlcMbeIbPgRxTKUdVjpmUYy+HnbtSKcdODlcOjJkcKCFRktF+Vz6H0LJnWqFwXe2ulA4d
bbY4Ymfvwrp8HGqo4np8KEkJzgIWcM1T89Vhm2JYSfHPl5TotlRkrwh/rMaDVyQfJBYDAzFP
dwi5+wA+XmbMpRQDu4FPMxyr4khV2JoUPvbXHYEGyFfTUqsTmJdWImfikfdNY9DrkQ/ia/lW
PPKdeOR78cgP4pHfiUd+Lx75g3jkj+KRP4lH/iwe+YtYZL4zgtY8s/JCr74G8bpDikCa2RHi
iYBMW+wWcQApxjpOR4grAuLJCGUpR96RbGMgO4DTFTBuepCbAJOOAE1tGtxe7kp2yLayRkq0
3iBMLl3u9jImASx1aY7CbbEubPCLnpgohInhCusX11TWZLiuLojetC/E0AQxWiWMf8GCmDKx
R3mE2zR3HqbRMo81LPNYOTGGyZKs8r1Ouu+XxolRAtmlRMkShChtCvS14tL/Z8+9kNd+0As3
SyK2nEdYa8LZBD3CJPedYuL4VSp1QKMesCbrqYjn8o10DNHSaro46u5R09Tmif5W1Gkv1FlT
77QV9UEkFdHnazdVJ+RerZU1XCO8pd4g8ZcwDxhbwgKFFB8907ZNu2CScgCNWkUOV8pRlcOT
84ZVOabSOvZyODKZsC6HTCasyeHJzNuqHFOZcFCVYyatoyrHvbSOUg7daLtr2QHFFUKZtqck
MKW3Cez33dRkzsexKIYU5VgUU4pyLIole1jHothSFKWUJU9HLxaoDX0TimNV5BYux6oYzdke
Q1Jl71jkAP9FYVy59ue0MHIFYaKgMARsA4TmabEXhg1oj2i/iqgGYfZqDtzv1wTxpCB1QVh4
ytSkIKUgLEBlTqQgpSBtN9pAm3dJCJ+LhCJLxPxliTSFITFc+emqSG0Zi0ltwfATxCnkaacX
b+TPCyr5oktD4JRyqqQrlqspdJ46fYpImZg7EaPajum0Ssg7y9TMLq8TO2BWXnpRvKBNTJ7G
/kUWnlzHytXA6Gk3GrEmg5cDb5lt3DXtxjwkMVwpxl4MT4pRfY1OvmXj2VB6temtldxNIOlt
CnvXnDZTivzM4lVv51u+i9uSGtbtB+v1g50Kw37yceSHUVBZe2223FTjBMpqizoFc656+dUZ
zP2VmCeF9pBW5XuMOyfH/gt7O5myOHwAAA==
--------------070807010503030604040807--
Sep 23 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
FYI, I am planning on getting back to this (getting it stable and 
proper), but am swamped right now with other things (some D related :P )

  - Gregor Richards
Sep 25 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:

 FYI, I am planning on getting back to this (getting it stable and 
 proper), but am swamped right now with other things (some D related :P )

I am revising the GDC spec so that it works for PPC64 too, based on the GCC spec for Fedora Core 4 (it needs both of PPC and PPC64, just like it needs both of SPARC and SPARC64 - for Intel those are separate in two versions: "i386" and "x86_64", but not so on the RISC chips...) So it does compile, but needs some love before it can be tested. --anders PS. The regular FC5 GCC uses GCC 4.1.x with some "neat features", so it's better to use the FC4 GCC which is 4.0.x and plainer.
Sep 25 2006