Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by address@hidden)

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble:
>> > On Feb 4, 2020, at 10:32, Jonas Hahnfeld <
>> > address@hidden
>> > > 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
>
> Apparently the build goes through. If I see this correctly, both
> clock_t and size_t are "unsigned long".

Wow.  Ok, maybe I'll just apply this patch then (though I'll at least
remove the conditioning on Apple here as the problem is rather likely
platform independent) and Phil may have another round.

-- 
David Kastrup