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.
