We have an OSX-only failure, which I think is a compiler bug.
It's failing in std.bigint, which only imports
std.internal.math.biguintCore and std.internal.math.bignumX86.
There's no dependency on anything else in Phobos, so it ought to be
pretty easy to reduce.
I can't reduce it, because I don't have OSX.

The failing test is this one:
    assert(BigInt(0x1234_5678_9ABC_5A5AL).toLong() == 0x1234_5678_9ABC_5A5AL);

This is blocking a release.

Don Clugston wrote:
> We have an OSX-only failure, which I think is a compiler bug.
>
> 

You'll owe me a beer if it turns out to be a bug in the library code !!

Don Clugston wrote:
> We have an OSX-only failure, which I think is a compiler bug.
> It's failing in std.bigint, which only imports
> std.internal.math.biguintCore and std.internal.math.bignumX86.
> There's no dependency on anything else in Phobos, so it ought to be
> pretty easy to reduce.
> I can't reduce it, because I don't have OSX.
>
> The failing test is this one:
>     assert(BigInt(0x1234_5678_9ABC_5A5AL).toLong() == 0x1234_5678_9ABC_5A5AL);
>
> This is blocking a release.
>
> 

Found the problem - you're right, it's a compiler bug. A bad one. Oops!

On 10/25/2010 8:58 PM, Walter Bright wrote:
> 
> 
> Don Clugston wrote:
>> We have an OSX-only failure, which I think is a compiler bug.
>> It's failing in std.bigint, which only imports
>> std.internal.math.biguintCore and std.internal.math.bignumX86.
>> There's no dependency on anything else in Phobos, so it ought to be
>> pretty easy to reduce.
>> I can't reduce it, because I don't have OSX.
>>
>> The failing test is this one:
>>     assert(BigInt(0x1234_5678_9ABC_5A5AL).toLong() == 0x1234_5678_9ABC_5A5AL);
>>
>> This is blocking a release.
>>
>> 
> 
> Found the problem - you're right, it's a compiler bug. A bad one. Oops!

An osx specific problem?

Brad Roberts wrote:
> On 10/25/2010 8:58 PM, Walter Bright wrote:
> 
>> Don Clugston wrote:
>> 
>>> We have an OSX-only failure, which I think is a compiler bug.
>>> It's failing in std.bigint, which only imports
>>> std.internal.math.biguintCore and std.internal.math.bignumX86.
>>> There's no dependency on anything else in Phobos, so it ought to be
>>> pretty easy to reduce.
>>> I can't reduce it, because I don't have OSX.
>>>
>>> The failing test is this one:
>>>     assert(BigInt(0x1234_5678_9ABC_5A5AL).toLong() == 0x1234_5678_9ABC_5A5AL);
>>>
>>> This is blocking a release.
>>>
>>> 
>>> 
>> Found the problem - you're right, it's a compiler bug. A bad one. Oops!
>> 
>
> An osx specific problem?
> 

Doing a signed long compare calls a function in llmath.d. That function is the only one that returns its result in the flags. In OSX, the stack must always be aligned on 16 bytes when a function is called. The alignment is done by adding/subtracting from ESP, which resets the flags. Oops! The solution was to just inline the comparison code.

On 10/25/2010 11:38 PM, Walter Bright wrote:
> 
> 
> Brad Roberts wrote:
>> On 10/25/2010 8:58 PM, Walter Bright wrote:
>> 
>>> Don Clugston wrote:
>>> 
>>>> We have an OSX-only failure, which I think is a compiler bug.
>>>> It's failing in std.bigint, which only imports
>>>> std.internal.math.biguintCore and std.internal.math.bignumX86.
>>>> There's no dependency on anything else in Phobos, so it ought to be
>>>> pretty easy to reduce.
>>>> I can't reduce it, because I don't have OSX.
>>>>
>>>> The failing test is this one:
>>>>     assert(BigInt(0x1234_5678_9ABC_5A5AL).toLong() == 0x1234_5678_9ABC_5A5AL);
>>>>
>>>> This is blocking a release.
>>>>
>>>> 
>>> Found the problem - you're right, it's a compiler bug. A bad one. Oops!
>>> 
>>
>> An osx specific problem?
>> 
> 
> Doing a signed long compare calls a function in llmath.d. That function is the only one that returns its result in the flags. In OSX, the stack must always be aligned on 16 bytes when a function is called. The alignment is done by adding/subtracting from ESP, which resets the flags. Oops! The solution was to just inline the comparison code.

Nice and subtle.  My favorite kind of ick.