Submitter:CFP group
Submission Date: 2021-??-??
Document: WG14 N27??
Title: N27??: *_HAS_SUBNORM==0 implies what?
Reference Documents:

Summary: A reader has asked some of the CFP group members:

If *_HAS_SUBNORM is 0, what does that imply? For example, what is fpclassify(subnormal)? Is it: FP_SUBNORMAL or FP_ZERO, or undefined behaviour (UB)?

Discussion

5.2.4.2.2, paragraph 14 defines what *_HAS_SUBNORM means in vague terms. In particular:

0 absent (type does not support subnormal numbers)28)
28) Characterization as absent is intended if no floating-point operations produce subnormal results from non-subnormal inputs, even if the type format includes representations of subnormal numbers.

IEC 60559 has in 8.2 Resuming alternate exception handling attributes

-- abruptUnderflow
When underflow is signaled because a tiny non-zero result is detected, replace the default result with a zero of the same sign or a minimum normal rounded result of the same sign, raise the underflow flag, and signal the inexact exception. When roundTiesToEven, roundTiesToAway, or the roundTowardZero attribute is applicable, the rounded result magnitude shall be zero. When the roundTowardPositive attribute is applicable, the rounded result magnitude shall be the minimum normal magnitude for positive tiny results, and zero for negative tiny results. When the roundTowardNegative attribute is applicable, the rounded result magnitude shall be the minimum normal magnitude for negative tiny results, and zero for positive tiny results. This attribute has no effect on the interpretation of subnormal operands.

The above has not been added to C23.

There are architectures, such as ARM (used in many cell phones), that have control bits for two independent actions:

• Treat subnormal operands as zero.
• Flush subnormal results to zero.

ARM standard floating-point arithmetic flushes both operands and results to zero.

The user's program can change those at runtime (by facilities not part of Standard C). So, *_HAS_SUBNORM really should be a dynamic runtime property (not a constant translation time property); so should be like FLT_ROUNDS. But, since it is probably too late to change that, these could have (for this case) the value -1 (meaning indeterminable). But, if we are sticking to just Standard C, these would reflect the state at program startup.

Early versions of ARM let the sign of the zeros from flushed subnormals be implementation defined. Later versions set the sign of the zero to be the sign of the subnormal. Rounding control has no effect.

So, if subnormal operands are treated as zero, that would mean (independent of flushing subnormal results):

• fpclassify(subnormal) is FP_ZERO.
• issubnormal(subnormal) is false (zero).
• iscanonical(subnormal) is false (zero).
• nextup(zero) is minimum normal.
• nextdown(minimum normal) is (canonical) zero.
• signbit(-subnormal) is same as signbit(1.e0 * -subnormal); which could be positive (zero).

However, if subnormal operands are NOT treated as zero, that would mean (independent of flushing subnormal results):

• fpclassify(subnormal) is FP_SUBNORMAL.
• issubnormal(subnormal) is true (non-zero).
• iscanonical(subnormal) is true (non-zero) [Can there be non-canonical subnormals?].
• nextup(zero) is minimum subnormal.
• nextdown(minimum normal) is maximum subnormal.
• signbit(-subnormal) is negative (nonzero).

Optional: We could add new values to *_HAS_SUBNORM:

2 present and subnormal operands (but not results) are treated as zero
4 present and subnormal results (but not operands) are treated as zero

Proposal

Change 5.2.4.2.2, paragraph 14:

The presence or absence of subnormal numbers is characterized by the implementation-defined values of FLT_HAS_SUBNORM, DBL_HAS_SUBNORM, and LDBL_HAS_SUBNORM
-1 indeterminable27)
0 absent (type does not support subnormal numbers)28)
1 present (type does support subnormal numbers)

The presence or absence of subnormal numbers, and the amount of support, is characterized by the implementation-defined values of FLT_HAS_SUBNORM, DBL_HAS_SUBNORM, and LDBL_HAS_SUBNORM
-1 indeterminable27)
0 absent or both subnormal operands and results are treated as zero (type does not support subnormal numbers)28)
1 present and both subnormal operands and results are not treated as zero (type does support subnormal numbers)

Treated as zero (also known as flush to zero or abrupt underflow) may depend upon rounding direction and may produce the smallest normal number (with the same sign).

If subnormal representations are treated as zero values, then they shall be regarded as non-canonical zero representations (and in most cases with the same sign).

Change footnote 28 in 5.2.4.2.2 to:

28) Characterization as absent is intended if either subnormal operands are treated as zero or no floating-point operations produce subnormal results from non-subnormal inputs, even if the type format includes representations of subnormal numbers.

Straw polls

• Should the proposal be added to C23?
• Should the new values of *_HAS_SUBNORM be added to C23?