To: J3 J3/26-209 From: Malcolm Cohen Subject: Interp F23/025 on IEEE_GET_HALTING_MODE Date: 2026-October-19 ---------------------------------------------------------------------- NUMBER: F23/025 TITLE: Why is IEEE_GET_HALTING_MODE prohibited from DO CONCURRENT KEYWORDS: IEEE_GET_HALTING_MODE, DO CONCURRENT DEFECT TYPE: Erratum STATUS: J3 consideration in progress REFERENCES: 24-007 QUESTION: It is not obvious why the simple subroutine IEEE_GET_HALTING_MODE is prohibited from appearing in DO CONCURRENT, because (1) the similar IEEE_GET_ROUNDING_MODE and IEEE_GET_UNDERFLOW_MODE are permitted, (2) the prohibition is completely ineffective because halting modes, like all modes, flow down and not up, which means that the following simple subroutine has the same effect that IEEE_GET_HALTING_MODE would have if permitted: SIMPLE ELEMENTAL SUBROUTINE my_get_halting_mode(flag,halting) TYPE(IEEE_FLAG_TYPE),INTENT(IN) :: flag LOGICAL,INTENT(OUT) :: halting CALL ieee_get_halting_mode(flag,halting) END SUBROUTINE (3) and, the procedure IEEE_SET_HALTING_MODE is not permitted in DO CONCURRENT, so there is no possibility of cross-iteration communication if IEEE_GET_HALTING_MODE were allowed. Should this superfluous and ineffective restriction still apply? ANSWER: No, this restriction should not still apply. This was a mistake in Fortran 2008, which added DO CONCURRENT. Edits are supplied to remove the restriction. EDITS to 24-007: [xiv] Introduction, "Intrinsic modules" bullet, after the sentence "The subroutines IEEE_GET_MODES,...", insert new sentence "A reference to the subroutine IEEE_GET_HALTING_MODE can appear within a DO CONCURRENT construct." {Notify programmers and vendors of the change.} [200:35] 11.1.7.5 Additional semantics for DO CONCURRENT constructs, constraint C1145 which begins "A reference to the procedure IEEE_GET_FLAG," delete "IEEE_GET_HALTING_MODE,". {Delete the restriction.} SUBMITTED BY: Malcolm Cohen HISTORY: 26-nnn m241 Submitted ----------------------------------------------------------------------