J3/02-138 Date: February 22, 2002 To: J3 From: Dick Hendrickson Subject: Chapter 14 comments 1) 271:8-10 (really in chapter 12) Can we really control code generation enough to prevent a compiler from generating setjmp or longjump? Either for inline code or in a library function like COS? 2) CH 14. I don't think the description of what IEEE_FEATURES does, nor how it does it, is complete enough. 3) 345:17 says "if IEEE INEXACT FLAG or IEEE INVALID FLAG is accessible, the scoping unit shall support the exception and return true from the corresponding inquiry for at least one kind of real" This is poorly worded, the "scoping unit" doesn't support IEEE arithmetic: it's a bunch of user code. Something like subroutine empty USE IEEE_FEATURES end should be legal even though it doesn't return true from any inquiry function. This happens in many places in 14. 4) 345:25. Delete "For processors with IEEE arithmetic". It appears to be aimed at processors with built-in IEEE arithmetic, but the next sentence says they don't have to have it all. 5) 345:21. But what if it only accesses IEEE_FEATURES? Lines 14 and 15 require underflow support for at least one real type if IEEE_UNDERFLOW_FLAG is accessible, and this does not appear to depend on the other modules being accessible. 6) 345:22 says if a flag is signaling on entry it will signal on exit, but says nothing about what happens inbetween. 347:19 says it will be set to quiet during execution. The first deals with a subroutien that doesn't USE IEEE*, but does require the flag to signal on exit which implies some knowledge in the compiler code of the flag register--it must be saved and restored since a routine which doesn't USE IEEE* could easily clear the flags by calling an assembly language routine. I think we should add language to 345 to say the flags are cleared on entry. 7) 345:36. The last sentence isn't necessarily true, and even if we think it is, it is beyond the scope of the standard. Lines 31-33 require all 4 rounding modes if IEEE_ROUNDING is accessible. So a processor that doesn't support round-up won't have IEEE_ROUNDING in IEEE_FEATURES. It seems arguable top me that there is "fuller" support by not using IEEE_FEATURES and letting the processor by default support all of IEEE except round-up. But this might be a perverse reading of the words. 8) 345 Note 14.1 Move this to 345:7+ since it doesn't particularily apply to the preceding paragraph or two. 9) 345:40+ I'd prefer to see a note something like NOTE 14.2 A programmer can require that certain features be at least partially supported by explicitly using certain constants from IEEE_FEATURES. A sequence such as USE, INTRINSIC :: IEEE ARITHMETIC USE, INTRINSIC :: IEEE FEATURES ! brings in full support USE, INTRINSIC :: IEEE FEATURES, ONLY: IEEE_ROUNDING Will use the processors fullest IEEE support and will also fail at compile time if IEEE_ROUNDING support is not available. Aside: looks strange with the third colon 10) 346:25-28 Why do some of the terms have _FLAG and not all of them? 11) 346:42 What about overflow within the calculation.. Something like print *, ABS(CMPLX(big,big)) where big**2 + big**2 overflows.? I wouldn't call ABS an intrinsic real operation and neither the real or imaginary parts are too big. This is just a wording issue; does anybody know what IEEE says? 347:22 may cover this. 12) 347:6 What about, e.g., IEEE_RINT? It's not an intrinsic function, should it trigger invalid for large values of x? I think this is another problem with saying the intrinsic module functions aren't intrinsic: we actually think they are. See 1) in my paper "Chapter 13, questions about intent and meaning" for more comments. see also 347:17 for another use of "intrinsic". Or 347:25 and IEEE_NEXT_AFTER. I really think the (local) solution is to call them intrinsics; but I'm not sure what that does to chapter 13, and 1, and 11/12, etc. But 350:17 also gives better wording 13) 347:8 same questions as for 346:42, except replace big with small. 14) 347:17. The next sentence gives another instance where it gets set quiet. 15) 347:19-20. Does this also hold for recurrsive and internal procedures? I think it should, at least for recurrsive. 16) 347:20. Add a note. "NOTE 14.xxx If a flag signals during execution of a procedure, the processor must not automatically set it to quiet on return." 17) 347:21 Note that this allows specification functions to talk to each other through the flags and to me means they are not PURE. 18) 347:28. All calculations in the intrinsic affect the result (otherwise why would they be there?) We mean intermediate calculations that are later ignored because of an IF that detects something odd about them; we need to find a way to say that. 19) 347:30+ I'm not sure this goes far enough for modern optimizers. Dead code is common in old codes that have been extensively maintained. Things like subroutine xxx(a,b) … x = sqrt(y) !originally, this was useful but later on all subsequent references to X have been removed end A good dead code eliminator is likely to effectively eliminate the entire line. What is the processor required do? 20) 348:13, after "permitted" add ", but not rerquired," 21) 348:14. I'm not sure this is true. I think we are mixing "local" support and hardware support. I think we can "disable" e.g., IEEE_INVALID locally by doing something like USE, INTRINSIC :: IEEE_FEATURES, ONLY: IEEE_ROUND in this case the scoping unit has no access to the IEEE_INVALID flag. But a call to another routine can set the flag to signaling, so it's not always quiet. I think we need to reword something. 22) 348:16-18 This sentence does not belong here; it's said in 347:4-6. 23) 348:30-32. Is there a problem with DTIO? Since the user is doing it himself, how can the function guarantee that rounding will be IEEEish? 24) 348:33+ can we really expect this to be true for calls to routines that don't directly USE IEEE*? How about to C routines or assembly routines? Is this intended to be a code generation restriction (effectively requiring save/restore on the caller side?) or a boy-scout restriction on the writer of a called procedure? NOTE 14.5 may answer this. 25) 349:6-8 same question for IEEE_HALTING 26) 350:17. Do we meant "this intrinsic module" instead of "intrinsic modules". As worded this requires the C interop moudule to also support NaNs, etc. Suppose a processor has it's own special arithmetic mode and defines modules similar IEEE_*; we can't expect VENDOR_SQRT(X) to mimic the IEEE behaviour if X is an IEEE NaN. Same comment for lines 21 and 24. 27) 350:24. I think the first sentence is true, but incomplete. Doesn't IEEE also require accuracy conditions? The first sentence implies that -0.0 is the only special case. (If the dog doesn't bark, it isn't there!) 28) 350:26 Is this function ever true for any current computers? 29) 351:issue 353. I agree with Richard's comments. Also, if the functions are not "intrinsic" I don't see how we can give them magic ch13 properties. 30) 355:note 14.8 The values can also be used with == and /= See 346:20+ 31) 361:16. "ARITHMETIC" => "EXCEPTIONS" the STATUS_VALUE type is actually defined in IEEE_EXCEPTIONS, true the existing USE brings it in; but why confuse people. 32) 361:note 14.11. Delete the last sentence as unnecessary. Reword the first to "On some processors this may be a very time consuming process." 33) 362:note 14.12. Middle part. I thought underflow signaled whenever a denorm was produced, even if it is exact. 34) 362:3 Does this restriction need [X] instead of X as the argument? That is, am I allowed to invoke IEEE_SUPPORT_DENORMAL() if IEEE_SUPPORT_DATATYPE() is false? This applies to most of the functions. 35) 362:28-29. These are the only possible values for the argument. There is no need to list them. If we make this change we should scan all of the other arguments sections. e.g. 363:14+ 36) 363:10. Does SUPPORT_HALTING take an array as an argument? It seems like a natural thing to want tuo use IEEE_USUAL or IEEE_ALL as an argument. The "Argument" section doesn't say that FLAG is a scalar; whereas it does for e.g. IEEE_SUPPORT_FLAG 362:28-29 37) 363:14 compare to 362 28-29. Why is one FLAG explicitly INTENT(IN) and the other not? IN general, I think we need to look at all of the argument definitions for consistency. 38) 365:16, see previous comment about SQRT(-0.0) 39) 14.8.4 We need to do/say something about things like IEEE_SET_FLAG being elemental. Chapter 13, note 13.1 talks about elemental subroutines being PURE and non-elemental being impure because the have system side effects. See also comments about first part of CH13 and use of IEEE_SET... and IEEE_GET... in "pure" routines. ############## Typo's and grammar/usage questions. G1) 350:29 "whenh" => "when" G2) 351:23 extray blank line to right of function definition G3) 360:note 14.10 Change "the exception" to "an exception". Because halting is imprecise, you can trigger many of them. G4) 349:21 In about half the cases we use "Not-A-Number" and in the other half "Not-a-Number". I believe we consistently use NaN in text references. Proposal: Replace all "Not-A-Number" with "Not-a-Number" G5) 408:18. The glossary entry for Not-a-Number uses a different kind of dash from all of the other usages; makes it hard to search for! Proposal: 408:18 make "Not-a-Number" the same as instances in the body of the standard. This might be a generic problem with "-", I also had some trouble seareching for "round-" G6) IEEE_RINT this is the first use of hyphens in round-to-nearest and round-up that my search found. Compare with 219:5-7 G7) IEEE overflow in ch 14 is the first occurrence of the term "processor-dependent" with a hyphen. Should it be hyphenated here? I thought we used processor dependent about a million times elsewhere.