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

"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.

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.

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

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.

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

"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
setting?

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.

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
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4619
>
> and my reply to your reply to it.
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

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
>>
>> http://www.digitalmars.com/drn-bin/wwwnews?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