www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - DStress: DMD-0.137 -> DMD-0.138

reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.138

Oops. 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
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 "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.138

Oops. 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? 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
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 Oops. 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?

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. --anders
Nov 08 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"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 alignment

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
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Regressions from DMD-0.137 to DMD-0.138

Uh, 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 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
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am 2005-11-08:
 Thomas Kuehne wrote:
 
 Regressions from DMD-0.137 to DMD-0.138

Uh, 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 digitalmars.D.bugs/4619 and my reply to your reply to it.

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-----
Nov 11 2005
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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.
 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.


Sounds interresting.
 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

 digitalmars.D.bugs/4619

 and my reply to your reply to it.


The issue at hand is if # static byte[3] array = [1:11]; is legal or has to be written as # static byte[3] array = [0, 11, 0]; 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. # typedef byte xByte = 4; # # int main(){ # static xByte array[3] = [1:11]; # # foreach(size_t i, xByte b; array){ # printf("array[%u] %hhi\n", i, b); # } # # return 0; # } output: # array[0] 4 # array[1] 11 # array[2] 4 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-----
Dec 03 2005