>> I bet the above workaround in generic code was added for a reason, it would
>> surprise me if _Float128 worked at all without that hack.
>
> OK, I'll have a look at those nan failures soon.
By investigating the exposed NaN failures, I found it's due to that it wants
to convert _Float128 type constant to long double type constant, it goes
through function real_convert which clears the signalling bit in the context
of !HONOR_SNANS (arg).
if (r->cl == rvc_nan)
r->signalling = 0;
The test cases don't have the explicit option -fsignaling-nans, I'm inclined
to believe it's intentional since there is only a sNaN generation. If so,
we don't want this kind of conversion which is useless and can clear signalling
bit unexpectedly, one shortcut is to just copy the corresponding REAL_VALUE_TYPE
and rebuild with the given type if the modes are the same.
-----
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index e80be8049e1..d036b09dc6f 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -2178,6 +2178,14 @@ fold_convert_const_real_from_real (tree type, const_tree
arg1)
REAL_VALUE_TYPE value;
tree t;
+ /* If the underlying modes are the same, just copy the
+ TREE_REAL_CST information and rebuild with the given type. */
+ if (TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (arg1)))
+ {
+ t = build_real (type, TREE_REAL_CST (arg1));
+ return t;
+ }
+
/* Don't perform the operation if flag_signaling_nans is on
and the operand is a signaling NaN. */
if (HONOR_SNANS (arg1)
-----
The above diff can fix all exposed NaN failures.
BR,
Kewen
