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
signature.asc
Description: This is a digitally signed message part
