> On Feb 4, 2020, at 10:32, Jonas Hahnfeld <hah...@hahnjo.de> wrote:
>
> Am Mittwoch, den 05.02.2020, 00:24 +0900 schrieb Masamichi Hosoda:
>>>> $ ~gub/gub/target/linux-x86/root/usr/cross/bin/i686-linux-g++ -c -msse2
>>>> -mfpmath=sse -I include -I .. rational.cc
>>
>>>> $ ~gub/gub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd6-g++ -c
>>>> -msse2 -mfpmath=sse -I include -I .. rational.cc
>>
>>>
>>
>>> So this only affects darwin-x86 which confirms my observation that
>>
>>> linux-x86 still works. AFAICS darwin-x86 never had a fpu_control.h, so
>>
>>> I'd propose to drop -msse2 -mfpmath=sse for i686-apple-darwin8.
>>
>>> This unblocks the release and the situation on darwin-x86 remains the
>>
>>> same as before, but we have the fix for linux-x86 and mingw.
>>
>>>
>>
>>> My fear is that not only rational.cc is affected, but also many other
>>
>>> files. Did you test if a full compile works? If no, I'm against adding
>>
>>> workarounds for all files that suffer from the compiler error.
>>
>>
>> I didn't test full compiler works.
>> However, If I understand correctly,
>> it seems that static cast from `unsigned long long` to `double`
>> is only in rational.cc.
>
> What makes you think so? I think you're right it's the only place with
> (double) casting, but I see a few with double (...) and some more with
> Real (...).
> In particular, flower/cpu-timer.cc casts variables of type clock_t -
> I've yet to hunt down which type of integer this actually is.
>
> Jonas
And what about size_t to Real? There's some of that in the queue:
https://codereview.appspot.com/563460043
—
Dan
