 |
 |
On 11/26/13 2:35 PM, FX wrote: >> I would expect it to halt, but the standard says "Halting is not precise and may occur any time after the exception has occurred." so I don't think this can be guaranteed. > > Yes, I know because of this sentence, halting is not guaranteed. But you’re saying it could happen. > >> In section 14.3 of the standard are the words "Each exception has a flag whose value is either quiet or signaling. The value can be determined by the subroutine IEEE_GET_FLAG. Its initial value is quiet and it signals when the associated exception occurs. Its status can also be changed by the subroutine IEEE_SET_FLAG or the subroutine IEEE_SET_STATUS." >> >> The intention is to allow the programmer to provoke the same effect as when the hardware signals the condition. Mind you, the usual way to use IEEE_SET_FLAG is to set the flag quiet - I think all the examples in the standard are like this. > > My reading was that “[the flag] signals when the associated exception occurs” is an one-sided implication: “exception occurs ==> flag signals”, but nothing specifies that “flags signals ==> exception occurs” (and halting is linked to exceptions occuring, not flags being raised). Thus, halting is not allowed to happen. (Both the Intel and Sun compilers do not halt, as a matter of fact.) > > I can’t speak for the intent, though… but if that was the intent, maybe this should be clarified. Does it seem interp-worthy to you? If so, how should I proceed? > I tried the test with compilers from multiple vendors, all targeting the same hardware (x86_64), and got a mix of results - some trapped and others did not. Perhaps more interesting, I tried compilers from the same vendor targeting two different hardware architectures and had one trap and the other not. In the case that trapped, the compiler had inlined the module procedures and the set flag operation was reduced to a trivial sequence of instructions that moved the contents of the control register to an arithmetic register, OR'ed in the correct bit, and then moved the result back to the control register. Setting the control register caused the trap by the hardware since traps for that exception had been enabled. That result suggests the "processor dependent" answer might be the best we could do. Cheers, Bill > Thanks, > FX > -- Bill Long [log in to unmask] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101