https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:7ed800c9c94b57077ba5911974a63bc06a5e1c35 commit r14-9132-g7ed800c9c94b57077ba5911974a63bc06a5e1c35 Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Feb 22 10:19:15 2024 +0100 call-cdce: Add missing BUILT_IN_*F{32,64}X handling and improve BUILT_IN_*L [PR113993] The following testcase ICEs, because can_test_argument_range returns true for BUILT_IN_{COSH,SINH,EXP{,M1,2}}{F32X,F64X} among many other builtins, but get_no_error_domain doesn't handle those. float32x_type_node when supported in GCC always has DFmode, so that case is easy (and call-cdce assumes that SFmode is IEEE float and DFmode is IEEE double). So *F32X is simply handled by adding those cases next to *F64. float64x_type_node when supported in GCC by definition has a mode with larger precision and exponent range than DFmode, so it can be XFmode, TFmode or KFmode. I went through all the l/f128 suffixed builtins and verified that the float128x_type_node no error domain range is actually identical to the Intel extended long double no error domain range; it isn't that surprising, both IEEE quad and Intel/Motorola extended have the same exponent range [-16381, 16384] (well, Motorola -16382 probably because of different behavior for denormals, but that has nothing to do with get_no_error_domain which is about large inputs overflowing into +-Inf or triggering NaN, denormals could in theory do something solely for sqrt and even that is fine). In theory some target could have different larger type, so for *F64X the code verifies that REAL_MODE_FORMAT (TYPE_MODE (float64x_type_node))->emax == 16384 and if so, uses the *F128 domains, otherwise falls back to the non-suffixed ones (aka *F64), that is certainly the conservative minimum. While at it, the patch also changes the *L suffixed cases to do pretty much the same, the comment said that the function just assumes for *L the *F64 ranges, but that is unnecessarily conservative. All we currently have for long double is: 1) IEEE quad (emax 16384, *F128 ranges) 2) XFmode Intel/Motorola extended (emax 16384, same as *F128 ranges) 3) IBM extended (double double, emax 1024, the extra precision doesn't really help and the domains are the same as for *F64) 4) same as double (*F64 again) So, the patch uses also for *L REAL_MODE_FORMAT (TYPE_MODE (long_double_type_node))->emax == 16384 checks and either tail recurses into the *F128 case for that or to non-suffixed (aka *F64) case otherwise. BUILT_IN_*F128X not handled because no target has those and it doesn't seem something is on the horizon and who knows what would be used for that. Thus, all we get this wrong for are probably VAX floats or something similar, no intent from me to look at that, that is preexisting issue. BTW, I'm surprised we don't have BUILT_IN_EXP10F{16,32,64,128,32X,64X,128X} builtins, seems glibc has those (sure, I think except *16 and *128x). 2024-02-22 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/113993 * tree-call-cdce.cc (get_no_error_domain): Handle BUILT_IN_{COSH,SINH,EXP{,M1,2}}{F32X,F64X}. Handle BUILT_IN_{COSH,SINH,EXP{,M1,2}}L for REAL_MODE_FORMAT (TYPE_MODE (long_double_type_node))->emax == 16384 the as the F128 suffixed cases, otherwise as non-suffixed ones. Handle BUILT_IN_{EXP,POW}10L for REAL_MODE_FORMAT (TYPE_MODE (long_double_type_node))->emax == 16384 as (-inf, 4932). * gcc.dg/tree-ssa/pr113993.c: New test.
