Am Dienstag, den 04.02.2020, 17:03 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > 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". > > 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.
Do we have a guarantee that we never overflow with this cast? Jonas
signature.asc
Description: This is a digitally signed message part