3

In case of FLT_HAS_SUBNORM == 0 (or any XXX_HAS_SUBNORM == 0 in general) does execution of fpclassify macro with manually constructed subnormal (constructed using type punning via union, using memcpy, reading from file, etc.) lead to undefined behavior (UB) or lead to well-defined behavior (WDB) returning FP_SUBNORMAL (as expected)?

Notes:

  1. The C standard is quite restrained about FLT_HAS_SUBNORM is 0 case. All that is says about FLT_HAS_SUBNORM is 0 is:

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.

    which can be interpreted as:

If FLT_HAS_SUBNORM is 0, then any_normal <op> any_normal never produces subnormal.

  1. The C standard seems to omit explicit definition of behavior for the following case (formulated as a question):

In case if FLT_HAS_SUBNORM is 0: does execution of any FP operation with inputs represented by manually constructed subnormals (constructed using type punning via union, using memcpy, reading from file, etc.) lead to undefined behavior (UB)?

  1. If the explicit definition of behavior is omitted, then according to the C standard:

… Undefined behavior is otherwise indicated in this document… by the omission of any explicit definition of behavior…

UPD20210825: Answer from the committee:

It is FP_ZERO.

Consequences:

  1. In case of FLT_HAS_SUBNORM is 0 shall the implementation have DAZ (Denormals Are Zero) property set to 1? Yes.
  2. Shall DAZ=1 be applied to all the operations involving FP numbers (objects)? In progress...
pmor
  • 5,392
  • 4
  • 17
  • 36
  • Note: `FLT_HAS_SUBNORM` has 3 defined values: -1, 0, 1. The question focus is if it is zero. – chux - Reinstate Monica Feb 03 '21 at 18:08
  • Given `FLT_HAS_SUBNORM == 0`, does the question apply to subset of implementations that do include representations of subnormal numbers and the manually constructed one is a valid one? – chux - Reinstate Monica Feb 03 '21 at 18:16
  • 1
    You could file a defect report with the ISO C standard committee pointing out the lack of clarity and suggesting a fix, or contact Fred Tydeman of Tydeman Consulting, who appears to have [proposed](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1352.htm) these macros. It is best to think of subnormal support as a set of two properties: Are subnormal inputs considered as zero (DAZ = "denormals are zero"); Can *arithmetic* operations produce subnormal results or are these flushed to zero (FTZ = "flush to zero"). In many programming environments DAZ=true implies FTZ=true and vice versa. – njuffa Feb 04 '21 at 00:13
  • I don't see it as UB by omission; "all frobs are grue" and "joe produces no frobs" implies that frobs produced by other sources are still grue. I'd agree with filing a defect report though as the intent is unclear. – M.M Feb 04 '21 at 22:48
  • 1
    The wording of (1) does seem to suggest that they thought of this case and are saying that subnormal inputs can produce subnormal outputs even when FLT_HAS_SUBNORM == 0. – M.M Feb 04 '21 at 22:49
  • @M.M Have a look: https://stackoverflow.com/questions/65297177/flt-has-subnorm-is-0-subnormal-op-normal-can-produce-subnormal. – pmor Feb 08 '21 at 14:14
  • @chux-ReinstateMonica Yes, the question applies to subset of implementations that do include representations of subnormal numbers and the manually constructed one is a valid one. Then shall the `fpclassify` macro called with this `valid one` as input lead to WDB (returning `FP_SUBNORMAL` as expected) or lead to UB? In other words: if `FLT_HAS_SUBNORM == 0` and if implementations does include representations of subnormal numbers, then how many FP standard functions called with manually constructed subnormal numbers lead to UB? All or some? Which ones exactly shall lead to UB / WDB? – pmor Feb 08 '21 at 14:20
  • @M.M See also: https://stackoverflow.com/a/65296492/1778275. Citation: `If subnormal numbers are not supported, then they are not supported regardless of how they are obtained, whether by literals in source code, arithmetic, or manipulation of the bits that represent floating-point objects.`. – pmor Feb 08 '21 at 14:27
  • Hmm, "0 absent: 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." Footnote #26 implies to me the behavior is implementation defined. Without some definition of behavior, then there is no way to have a subnormal. I do not the C standard detailing more. – chux - Reinstate Monica Feb 08 '21 at 14:43
  • @pmor that's just someone's opinion (which I disagree with) – M.M Feb 10 '21 at 04:14
  • 2
    The fact that an implementation's floating-point format represents zero and normalized floating-point values in a manner consistent with IEEE-754 does not compel it to treat other bit patterns in a fashion consistent with IEEE-754. If an implementation doesn't specify any particular meaning for a floating-point bit pattern, it would be free to treat it as a trap representation and process it in any arbitrary fashion. – supercat Feb 17 '21 at 19:44
  • @M.M: The Standard uses the term "Undefined Behavior", among other things, to describe actions which should have defined behavior on some implementations but not necessarily all, generally leaving the question of whether to define the behaviors as a "quality of implementation" issue outside its jurisdiction. The Standard makes no attempt to avoid characterizing as UB actions which should be processed usefully by many implementations, and should be viewed as correct in code intended only for such implementations. – supercat Feb 17 '21 at 19:52
  • @njuffa However, in C the `FLT_HAS_SUBNORM is 0` case leads to FTZ and _not_ to DAZ, right? – pmor Mar 08 '21 at 15:43
  • @M.M (1) About _subnormal inputs can produce subnormal outputs even when FLT_HAS_SUBNORM == 0_. The consequence is correct, however, what is practical application of this case / scenario? (2) Or maybe (hypothesis) the footnote 26 (C11) indirectly _tries to say_ that if `FLT_HAS_SUBNORM == 0`, then passing subnormal inputs to floating-point operations is invalid ? If so, does it mean that if `FLT_HAS_SUBNORM == 0`, then passing subnormal input to `fpclassify()` is invalid as well? – pmor Mar 08 '21 at 16:00
  • @M.M See UPD20210825. – pmor Aug 25 '21 at 08:33
  • @supercat See UPD20210825. – pmor Aug 25 '21 at 08:33
  • @chux-ReinstateMonica See UPD20210825. – pmor Aug 25 '21 at 08:33
  • @pmor: See what? – supercat Aug 25 '21 at 14:54
  • @supercat See UPD20210825, which has answer from the committee: "It is FP_ZERO". – pmor Aug 25 '21 at 17:15
  • @pmor: Where is that document? – supercat Aug 25 '21 at 17:43
  • @supercat What document? The CFP (C Floating Point) sub-group asked the committee. The answer: "It is FP_ZERO". – pmor Aug 25 '21 at 17:53
  • @pmor: Allowing implementations to treat subnormal numbers at their leisure as either equal to zero or their subnormal value, choosing in Unspecified fashion for each individual operation, but with each operation behaving as though it did one or the other, would seem to allow more efficient code generation in many places than requiring subnormal values to behave as though equal to zero. I wonder in how many non-contrived applications would fail to meet requirements on implementations that were to use the cheaper behavior? – supercat Aug 25 '21 at 18:38
  • @pmor: Unfortunately, the Committee seems to want to minimize the number of cases where it would allow implementations to choose in Unspecified fashion from multiple behaviors that would in many cases all meet requirements. Treating programs as fully deterministic in all cases where their behavior is defined at all makes some kinds of analysis easier, at the expense of limiting the range of tasks that can be accomplished in ways that can be analyzed. – supercat Aug 25 '21 at 19:26

0 Answers0