**Submitter:**Fred Tydeman

**Submission Date:** 2018-12-12

**Document:** WG14 N2319

**Reference Documents:** N2124

Summary

There are (at least) two kinds of round to nearest. For
**FLT_ROUNDS** to reflect the execution-time rounding mode,
each of the round to nearest choices needs to be possible values
of **FLT_ROUNDS**.

Technical Corrigendum:

Change §5.2.4.2.2#9 from

The rounding mode for floating-point addition is characterized by the implementation-defined value ofFLT_ROUNDS:23)-1 indeterminable 0 toward zero 1 to nearest 2 toward positive infinity 3 toward negative infinity

to:

The rounding mode for floating-point addition is characterized by the implementation-defined value ofFLT_ROUNDS:-1 indeterminable 0 toward zero 1 to nearest, ties to even 2 toward positive infinity 3 toward negative infinity 4 to nearest, ties away from zero

and remove:

from the footnote that was added by n2124.~~*) The value 1 is intended for any mode that rounds to nearest, regardless of how it rounds halfway cases.~~

Also, move existing footnote 23

23) Evaluation ofFLT_ROUNDScorrectly reflects any execution-time change of rounding mode through the functionfesetroundin <fenv.h>.

to be part of paragraph 9.

Change §7.6, paragraph 8 from:

Each of the macrosFE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARDis defined if and only if the implementation supports getting and setting the represented rounding direction by means of the

fegetroundandfesetroundfunctions.

to:

Each of the macrosFE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD FE_TONEARESTFROMZEROis defined if and only if the implementation supports getting and setting the represented rounding direction by means of the

fegetroundandfesetroundfunctions.

I need to see Annex F after TS 18661-1 is applied to see if
any references to **FLT_ROUNDS** there need to be changed.