I hesitate to simultaneously disagree with both Bill and Craig, but I
think you should file a bug report. The purpose of the IEEE modules
is to allow people to do useful work on machines that have a variety
of floating point interrupt models. The "imprecise" statement was
designed to cover cases like
DO I = 1,1000000000000
a(i) = b(i)/c(i)
ENDDO
where, on some machines, providing precise interrupts would require
draining the pipeline on every iteration.
Maybe the interrupt would come during loop execution, maybe a few
dozen cycles afterward; that's imprecise. The intent wasn't to allow
the interrupt to coast through a few print statements and trigger a
postmortem message. That would be pointless. So, if the bad compiler
is from a reputable vendor, it's a compiler bug. Tell them to fix it!
Dick Hendrickson
On Tue, Feb 28, 2012 at 8:46 PM, Neil Carlson <[log in to unmask]> wrote:
> Assuming your compiler is modern enough to compile the following
> program, what should be its run-time behavior?
>
> program main
> use ieee_exceptions
> call ieee_set_halting_mode (ieee_invalid, .true.)
> call ieee_set_flag (ieee_invalid, .true.)
> print *, 'hello'
> end program
>
> With one compiler the program throws a run-time error (before the print)
> as I expected, but with another the program terminates normally with only
> a warning about an invalid operation having occurred -- the same type of
> warning that non-signalling errors produce.
>
> ieee_set_flag (ieee_invalid, .true.) sets the ieee_invalid flag to
> signalling,
> but the standard seems to be silent about what the system is actually
> supposed to do with that. So is it possible that both compilers are
> standard conforming?
>
> -Neil
>
>
|