https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #22 from luoxhu at gcc dot gnu.org --- https://gcc.gnu.org/pipermail/gcc/2020-December/234474.html So this issue seems invalid since "fabs(x)*y+z” or "fabs(x)+y+z"(x,y,z are float) could result in -+Inf sometimes, while it won't getting float overflow under double computation. Float value range info is required here. Quoto Richard's reply: I still think that covering all "good" cases in match.pd will require excessive matching and that it is better done in a pass (this would include removing the frontend handling for math functions). Note that for example (float)((double)x + (double)y) with float x and y is also eligible to demotion to float, likewise may some compositions like (float)(sin((double)x)*cos ((double)y)) for float x and y since we can constrain ranges here. Likewise (float)((double)x + fabs ((double)y)) for float x and y. The propagation would need to stop when the range needed increases in unknown ways.
