Am Dienstag, den 04.02.2020, 10:38 -0500 schrieb Dan Eble: > > 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
Apparently the build goes through. If I see this correctly, both clock_t and size_t are "unsigned long". Jonas
signature.asc
Description: This is a digitally signed message part
