digitalmars.D.bugs - DStress: DMD-0.137 -> DMD-0.138
- Thomas Kuehne (18/18) Nov 06 2005 -----BEGIN PGP SIGNED MESSAGE-----
- Walter Bright (6/9) Nov 06 2005 Oops. It works fine on windows, but fails on linux. I do most of the
- Stewart Gordon (13/24) Nov 08 2005 Seems strange. Does this mean that Intel processors have both 10-byte
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (22/31) Nov 08 2005 It's padded. It's also possible to pad out to a full 16-byte boundary,
- Walter Bright (10/14) Nov 08 2005 No. Only 10 byte reals.
- Stewart Gordon (22/26) Nov 08 2005 Uh, dstress.html still only goes up to 0.136, and results.html to 0.130....
- Thomas Kuehne (13/28) Nov 11 2005 -----BEGIN PGP SIGNED MESSAGE-----
- Thomas Kuehne (63/77) Dec 03 2005 -----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regressions from DMD-0.137 to DMD-0.138 PASS -> FAIL http://dstress.kuehne.cn/run/bug_cg87_279_C.d http://dstress.kuehne.cn/run/bug_cg87_279_F.d http://dstress.kuehne.cn/run/bug_cgcs_353_Q.d http://dstress.kuehne.cn/run/bug_cod2_4211_Q.d http://dstress.kuehne.cn/run/creal_13.d http://dstress.kuehne.cn/run/creal_14.d http://dstress.kuehne.cn/run/creal_15.d http://dstress.kuehne.cn/run/o/opCat_15_R.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDbruF3w+/yD4P9tIRAvxQAKCS1SQxoWXHLV53cHBf9hkRCCFq4QCcD+l+ x/ILQl/wh+gs19L5pj64gFo= =aXK4 -----END PGP SIGNATURE-----
Nov 06 2005
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message news:5lq243-rae.ln1 birke.kuehne.cn...-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regressions from DMD-0.137 to DMD-0.138Oops. It works fine on windows, but fails on linux. I do most of the floating point testing on windows. The trouble is that, to conform to the C ABI on linux, long doubles are 12 bytes rather than 10, and I didn't find all the 10 byte dependencies.
Nov 06 2005
Walter Bright wrote:"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message news:5lq243-rae.ln1 birke.kuehne.cn...Seems strange. Does this mean that Intel processors have both 10-byte and 12-byte reals, but each OS provides access to only one of them? Or that they have two bytes of padding regardless of any alignment setting? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regressions from DMD-0.137 to DMD-0.138Oops. It works fine on windows, but fails on linux. I do most of the floating point testing on windows. The trouble is that, to conform to the C ABI on linux, long doubles are 12 bytes rather than 10, and I didn't find all the 10 byte dependencies.
Nov 08 2005
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Stewart Gordon wrote:It's padded. It's also possible to pad out to a full 16-byte boundary, since that is the preferred alignment of the Pentium (and later) CPUs. I believe the x86 ABI calls for 96-bit, and the x64 ABI uses 128-bit. (alignment, that is, they both use the same 80-bit x87 format inside) http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/i386-and-x86_002d64-Options.html: " -m96bit-long-double -m128bit-long-double These switches control the size of long double type. The i386 application binary interface specifies the size to be 96 bits, so -m96bit-long-double is the default in 32 bit mode. [...] In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that long double is to be aligned on 16 byte boundary. [...] Notice that neither of these options enable any extra precision over the x87 standard of 80 bits for a long double. " On the PowerPC, "long double" is either 8 or 16 bytes (doubled up) Other processors might support a full quad for doing long doubles. --andersOops. It works fine on windows, but fails on linux. I do most of the floating point testing on windows. The trouble is that, to conform to the C ABI on linux, long doubles are 12 bytes rather than 10, and I didn't find all the 10 byte dependencies.Seems strange. Does this mean that Intel processors have both 10-byte and 12-byte reals, but each OS provides access to only one of them? Or that they have two bytes of padding regardless of any alignment setting?
Nov 08 2005
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message news:dkq2ta$22hu$2 digitaldaemon.com...Seems strange. Does this mean that Intel processors have both 10-byte and 12-byte reals,No. Only 10 byte reals.but each OS provides access to only one of them?The OS doesn't have anything to say about access to FPU registers.Or that they have two bytes of padding regardless of any alignmentsetting? gcc puts 2 bytes of pad in to fill it out to 12 bytes. This creates problems, because when you intialize a real, 2 bytes remain garbage, and that garbage gets propagated into other data structures. I think I've resolved the issue by adding an extra store of 0 at the end for any assignments to reals. But this costs extra code and time.
Nov 08 2005
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regressions from DMD-0.137 to DMD-0.138Uh, dstress.html still only goes up to 0.136, and results.html to 0.130. But at least it looks like the success rates are getting more realistic. (Memo to self: Get round to doing this stuff with the raw results and then updating my statistics file!) I've noticed in my time that several bugs that seem to slip past getting added. I might get together a bulk donation of testcases in the not-too-distant future. BTW you still haven't moved array_initialization_02 to undefined, nor given me any consistent interpretation of the spec that renders it otherwise. I refer you back to http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4619 and my reply to your reply to it. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 08 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stewart Gordon schrieb am 2005-11-08:Thomas Kuehne wrote:P lease hold your horses for 2 more days. I'm currently preparing the second generation of DStress. Codenamed "Torture" it'll provide some nasty surprises ... *g* Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDdSw+3w+/yD4P9tIRAiKrAKCwqSLolVpSqgxTQ0gUk+vrzwKMLwCgrw8r GDEE4smCM+kckmBdbQnGMYw= =wUGr -----END PGP SIGNATURE-----Regressions from DMD-0.137 to DMD-0.138Uh, dstress.html still only goes up to 0.136, and results.html to 0.130. But at least it looks like the success rates are getting more realistic. (Memo to self: Get round to doing this stuff with the raw results and then updating my statistics file!) I've noticed in my time that several bugs that seem to slip past getting added. I might get together a bulk donation of testcases in the not-too-distant future. BTW you still haven't moved array_initialization_02 to undefined, nor given me any consistent interpretation of the spec that renders it otherwise. I refer you back to http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4619 and my reply to your reply to it.
Nov 11 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Kuehne schrieb:Stewart Gordon schrieb am 2005-11-08:[snip]Please hold your horses for 2 more days. I'm currently preparing the second generation of DStress. Codenamed "Torture" it'll provide some nasty surprises ... *g*Weeding out Torture related issues like the "assert" and "-release" interactions took more time than expected.Sounds interresting.I've noticed in my time that several bugs that seem to slip past getting added. I might get together a bulk donation of testcases in the not-too-distant future.The issue at hand is if is legal or has to be written as Let's extend the code a bit to see if array[0] and array[2] have been set by the compiler or are an calloc-like artefact. output: Seems like array[0] and array[2] were explicitly set. So what does the documentation say? doc> Static Initialization of Static Arrays doc> doc> int[3] a = [ 1:2, 3 ]; // a[0] = 0, a[1] = 2, a[2] = 3 doc> doc> This is most handy when the array indices are given by enums: doc> doc> enum Color { red, blue, green }; doc> doc> int value[Color.max + 1] = [ blue:6, green:2, red:5 ]; doc> doc> If any members of an array are initialized, they all must be. This is to doc> catch common errors where another element is added to an enum, but one of doc> the static instances of arrays of that enum was overlooked in updating the doc> initializer list. doc> If any members of an array are initialized, they all must be. Interresting, but who is responsible - the source code or the compiler? doc> int[3] a = [ 1:2, 3 ]; // a[0] = 0, a[1] = 2, a[2] = 3 The sample suggests, it is the compiler. doc> This is to catch common errors where another element is added to an enum, doc> but one of the static instances of arrays of that enum was overlooked in doc> updating the initializer list. Is this supposed to catch at compile time or runtime? Mhhh, so is it the compiler or the source code? Moved to undefined: http://dstress.kuehne.cn/undefined/array_initialization_02.d http://dstress.kuehne.cn/undefined/array_initialization_15.d http://dstress.kuehne.cn/undefined/array_initialization_06.d Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDkiE/3w+/yD4P9tIRAof8AJwKyq2FIyyIuSXEQlPanBxmPQJo0QCfZOUA PnEnVZPosff+18xL3U9g7C4= =evAk -----END PGP SIGNATURE-----BTW you still haven't moved array_initialization_02 to undefined, nor given me any consistent interpretation of the spec that renders it otherwise. I refer you back to http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4619 and my reply to your reply to it.
Dec 03 2005