D.gnu - GDC for x86

D.gnu - GDC for x86_64!

Gregor Richards (12/12) Sep 20 2006 (I'm dual-posting this to both D.gnu and digitalmars.D, since it's at

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (4/13) Sep 21 2006 I am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (4/6) Sep 21 2006 Updated the PPC64 patch with some more Phobos fixes/workarounds.
Don Clugston (38/56) Sep 21 2006 Anders, could you do me a favour? I'd love to know what the following

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (15/19) Sep 21 2006 Here you go: (PPC)

Don Clugston (10/33) Sep 21 2006 Thanks! That's fascinating, the last two lines is a real surprise

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (5/7) Sep 21 2006 If you are doing further development, the easiest is

Vincenzo Ampolo (8/9) Sep 21 2006 Good work!
Thomas Kuehne (23/34) Sep 21 2006 -----BEGIN PGP SIGNED MESSAGE-----

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (13/23) Sep 21 2006 Did you have a patch for those ? Think I saw the same on PPC64,

Thomas Kuehne (34/56) Sep 22 2006 -----BEGIN PGP SIGNED MESSAGE-----

=?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= (61/61) Sep 23 2006 boundary="------------070807010503030604040807"

Gregor Richards (3/3) Sep 25 2006 FYI, I am planning on getting back to this (getting it stable and

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (9/11) Sep 25 2006 I am revising the GDC spec so that it works for PPC64 too, based on

Gregor Richards <Richards codu.org> writes:

(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

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

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

=?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

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

=?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

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

=?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

Vincenzo Ampolo <vincenzo.ampolo gmail.com> writes:

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

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;

< d/phobos/internal/mars.h:31: size_t 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

=?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

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










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
 





Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFFIzeLK5blCcjpWoRAtFUAJsGNp701A5NT44iWL98YFYxIFRBlgCgq2Ac
p7lWA/l0xH5EMkkteaCgXHo=
=Gm1V
-----END PGP SIGNATURE-----

Sep 22 2006

=?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:

 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

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

=?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

D Programming

C/C++ Programming

Other

D.gnu - GDC for x86_64!