https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
john henning <mailboxnotfound at yahoo dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mailboxnotfound at yahoo dot com --- Comment #42 from john henning <mailboxnotfound at yahoo dot com> --- A comment, an invitation, and some questions from one of those "SPEC people". The comment: SPEC CPU starts from real applications (rather than artificial kernels). Therefore, yes, it begins with code that includes practices that are less than perfect - including standards violations and mistakes in numerical methods. SPEC then weeds out benchmark candidates when they are discovered to be inadequate. Many have been weeded out due to numerical malpractice, when they cannot be relied upon to produce correct answers within some predefined tolerance. The remaining candidates get pushed toward the standard, get pushed toward better numerical practices. But all this is driven by testing. If there's nobody pushing hard on compiler X advanced optimization feature Y, and if Y quietly relies on source code to be virtuous as regards Z, it is entirely possible that sins against virtue Z will escape notice until after release of a SPEC benchmark suite. Pre-release, fixes are easy to sponsor and apply. Post-release, it is much harder, because of SPEC's preference for "no moving targets". The invitation: Thus I would invite any of the individuals who commented about "those SPEC people" to consider becoming one, and helping with the testing of benchmark candidates for the next benchmark suite. SPEC has a mechanism to accept free volunteer labor :-) and if you would like to volunteer, please write to info at SPEC dot org. If you like, you could mention my name and this bug when you do. The questions: (q1) Do I correctly gather that the fix described here would have gone into GCC 8? (q2) On aarch64 with GCC 8.2, GCC 9.3, and GCC 10.1 (Red Hat 7.8, glibc 2.17-307.0.2.el7.1) I am seeing the following 628.pop2_s miscompare and abort. Is this the same problem or a different problem as the one described in this bug? Miscompare: 1513: Chlorophyll transmission table computed Could not find range for chlamnt = 1.0000E-03 Abort: Contents of pop2_s.err **************************************** Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG ------------------------------------------------------------------------ POP aborting... set_chl_trans range error for chlamnt (q3) The text mentions that -funsafe-math-optimizations as a workaround. Was this tested? Was it narrowed to any of the components of -funsafe-math-optimizations which apparently are -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math? I am just about to start such testing on my aarch64 system, but if someone has already done such, it would be useful to know. (q4) *Is* there a proposed patch for 628.pop2_s? Although such may be unlikely to be applied to CPU 2017, it is conceivable that there might be an updated version of 628.pop2_s in a future suite. So, it would be good to have the proposed patch on record.