Joern Rennecke wrote:
Quoting Christian Bruel <christian.br...@st.com>:
Edited to apply on top of latest Joern's patch. Certainly not optimal
but it fixes the QNaNs checks for builtins and inlined unordered
comparisons for -mieee or -fno-inite-math-only.
You are still on the wrong track; as I said in my earlier message, we
should not emit the library call for SH4 in the first place.
>
Please try the attached patch instead.
Hello, Sorry for the mails that crossed.
I think we are dealing with 2 different problems here, that have the
same root. Original one was about undefined __unorddf2/__unordsf2
regression, for which you said that the library functions should not be
called. I agree, and my patch is not exclusive with yours in this regard.
I was dealing with functional issues in the SNanS bit checking in the
cmpun_ patterns (in addition to the floating point comparisons
functions). Which is exposed by the regression test that I provided (for
-m4-nofpu -mieee).
About the other part of your answer, non supporting SNaNs in the
fp-bit.c, it is a possibility that I didn't consider in my fix. This
restriction is quite a surprise to me because, related to NaNs, it is
not what I guess from the implementation of the fp-bit.c's isnan
function that does check for CLASS_SNAN, and CLASS_QNAN.
See for example the result of
static int misnanf(float v)
{
return (v != v);
}
called with either a QNaN or a SNaN. IMO The assembly model should have
the same semantic that the C model, which is not the case today.
Using -fsignaling-nans and eventually putting #ifdef __SUPPORT_SNAN__
around the checking doesn't change anything since the same call is done
to the floating point comparison function, that really needs to check
for both formats. If your are concerned about the extra cycles needed in
the nesf2f implementation (wich is nothing anyway compared to the C
model), we could certainly provide a specialized one just for
-fsignaling-nans.
Best Regards
Christian