While looking into PR 45272, I noticed it depends on the host double which is wrong, we should not depend on that. The main reason is because different hosts could produce slightly different results depending on the behavior of float. Oh Second mcf_sqrt depends on IEEE FP single precision.
Should use sreal, then?
Well, we don't have sreal_sqrt, and the approximation mcf_sqrt uses is quite tied to the float representation, while it isn't impossible to convert it, I'd say it isn't trivial either. Perhaps we could use mpfr instead.
I also see SIGFPEs recently on FDO SPEC 2000.
Created attachment 23643 [details] Use mpfr in predict.c instead of sreal, and in mcf.c instead of host double This completely untested patch shows what I'd like to do: Use mpfr instead of sreal and host double. Comments on the approach welcome.
Heh, with my patch (with some further changes) I get failures like this one: ../../trunk/gcc/sel-sched-ir.c:6253:1: error: caller edge frequency 38613 does not match BB frequency 38610 Excess precision? :-)
Created attachment 23644 [details] Use mpfr in predict.c instead of sreal, and in mcf.c instead of host double Bootstrapped&tested on x86_64-unknown-linux-gnu. Can be queued for GCC 4.7 if the Powers That Be agree this is the right approach. The mcf.c parts can be posted separately for GCC 4.6 if necessary, but I propose to close this big as WONTFIX for older releases.
OTOH, nowadays all(?) host platforms we support have IEEE enough compliant HW floating-point (well, details like signed zeros and NaNs/Infs are not really relevant for GCC) that a hwfloat.h could provide a mapping to a 32bit / 64bit IEEE float format? Else the patch certainly looks good to me, but lets queue it for 4.8 (I remembered you posted patches to remove sreal.c, did you?)
Is there already a meta bug for patches queued for 4.8?
GCC 4.8.0 is being released, adjusting target milestone.
GCC 4.8.1 has been released.
GCC 4.8.2 has been released.
GCC 4.8.3 is being released, adjusting target milestone.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed
GCC 5 branch is being closed
GCC 6 branch is being closed
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
Note that with the introduction of profile-count.h I chased away most of uses of double for profile calculation. In predict.c we have last occurence when combinindg probabilities from predictors: combined_probability = (((double) combined_probability) * probability * REG_BR_PROB_BASE / d + 0.5); These are still REG_BR_PROB_BASE based (unlike rest of code that uses profile_probability datatype) since that was easier to have in .def file. Cast to double is there only to get type wide enough for REG_BR_PROB_BASE third power in the 32bit x86 era. It is set to 10000 that is roughly 2^14 so 43 bits (with sign bits) is enough that should be good for all reasonable double implementations. However we could easily change it to int64_t.
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.