From Newsgroup: comp.arch

Fortran has an optional IEEE module. One of its important features
is that flags (IEEE exceptions) are set to quiet on entry of a procedure
and restored to signalling if it was signalling on entry, or keep it
signalling if it was raised on in the procedure. Similarly, rounding
modes are saved and restored for procedures. This is automatically
done if the right IEEE modules are used. A user can set rounding
modes or set and clear exceptions using the right modes.

Conceptually, this is the right thing to do. A library routine should
not produce different results depending on what a user did for his
own calculations.

Computationally, this can be quite expensive - having the meaning
of a calculation changed by changing FP state should (I hope so,
for corecntess's sake) flush any calculations done with the wrong
FP mode. Just calling a small library routine which does so could
be enough.

An example of the high cost is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121570 where, depending
on the library implementation, gfortran may be over-cautious
for the ieee_next_after function by saving and restoring fp state,
but I'm not sure that the overhead is actually from the FP state or
from calling extra functions.

So... What is the best way to do allow this to be more efficient?
The CPU could speculate on the FP mode (not sure if that is actually
done). Other suggestions? How do current CPUs do so?
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?
2. Does above said mean that caller has no way of modifying rounding
mode used by callee? If true, it defeats one of original reasons for
which Kahan invented rounding modes in the first place.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

Fortran has an optional IEEE module. One of its important features
is that flags (IEEE exceptions) are set to quiet on entry of a procedure
and restored to signalling if it was signalling on entry, or keep it signalling if it was raised on in the procedure. Similarly, rounding
modes are saved and restored for procedures. This is automatically
done if the right IEEE modules are used. A user can set rounding
modes or set and clear exceptions using the right modes.

How does a user set up his environment such that if TAN()* overflows
to infinity it returns with the OVERFLOW flag set ?!?

(*) EXP(), POW(,)

Conversely, how does one write a TAN()* subroutine with the above property ?

Conceptually, this is the right thing to do. A library routine should
not produce different results depending on what a user did for his
own calculations.

I would think that a user setting RM=ToZero would WANT a different
result from SIN() than the same call with RM=RNE ?!?

Computationally, this can be quite expensive

And contrary to how IEEE 754 has been used for 40 years.

- having the meaning
of a calculation changed by changing FP state should (I hope so,
for corecntess's sake) flush any calculations done with the wrong
FP mode. Just calling a small library routine which does so could
be enough.

Oh, and BTW, how does a user CALL a subroutine to set his RM when
the RETURN undoes the very nature of his request ?!?

An example of the high cost is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121570 where, depending
on the library implementation, gfortran may be over-cautious
for the ieee_next_after function by saving and restoring fp state,
but I'm not sure that the overhead is actually from the FP state or
from calling extra functions.

So... What is the best way to do allow this to be more efficient?

UN DO this change to IEEE 754.

The CPU could speculate on the FP mode (not sure if that is actually
done). Other suggestions? How do current CPUs do so?

Multi-threaded cores already have to ship different RMs to FUs on
each FP instruction. The HW is all there--its the ISAs that are screwed
up.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

2. Does above said mean that caller has no way of modifying rounding
mode used by callee? If true, it defeats one of original reasons for
which Kahan invented rounding modes in the first place.

The caller cannot change the callee's rounding mode without the
callee having been designed for this (by taking the rounding mode
as an extra argument and using IEEE_SET_ROUNDING_MODE itself).

I think that's a good idea. If a library routine is written
and debugged for a particular rounding mode, results should
not change because somebody up the call tree changed it.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

It will answer the question if you also say that the rule stated above (rounding mode saved on entry and restored on exit) does not apply
to procedures from intrinsic modules. Or may be does apply to the
rest of procedures in intrinsic modules and IEEE_SET_ROUNDING_MODE is
an exception?

2. Does above said mean that caller has no way of modifying rounding
mode used by callee? If true, it defeats one of original reasons for
which Kahan invented rounding modes in the first place.

The caller cannot change the callee's rounding mode without the
callee having been designed for this (by taking the rounding mode
as an extra argument and using IEEE_SET_ROUNDING_MODE itself).

I think that's a good idea. If a library routine is written
and debugged for a particular rounding mode, results should
not change because somebody up the call tree changed it.

Personally, I never found the whole rounding modes business useful in
my practice. So, can not say with straight face whether Fortran's take
on it is good idea or not. But I can say with good level of certainty
that William Kahan meant something else.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 13 Sep 2025 22:00:28 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

Thomas Koenig <tkoenig@netcologne.de> posted:

Fortran has an optional IEEE module. One of its important features
is that flags (IEEE exceptions) are set to quiet on entry of a
procedure and restored to signalling if it was signalling on entry,
or keep it signalling if it was raised on in the procedure.
Similarly, rounding modes are saved and restored for procedures.
This is automatically done if the right IEEE modules are used. A
user can set rounding modes or set and clear exceptions using the
right modes.

How does a user set up his environment such that if TAN()* overflows
to infinity it returns with the OVERFLOW flag set ?!?

(*) EXP(), POW(,)

Conversely, how does one write a TAN()* subroutine with the above
property ?

I think that in above paragraph Thomas Koenig uses the word
'signalling' in a sense that differs from it's use in IEEE-754 standard.
He uses to mean, using 754 language, "Immediate alternative exception
handling block associated with a block". Ugh.

In more simple terms, Thomas probably meant to say that Fortran behaves
as if [under Windows] at the entry of the procedure we did
int old = _controlfp(_MCW_EM , _MCW_EM );

and at the exit from procedure we did
int old = _controlfp(_MCW_EM , old);

I'd guess that there exists POSIX equivalent for that, but I don't know
what it is.

Conceptually, this is the right thing to do. A library routine
should not produce different results depending on what a user did
for his own calculations.

I would think that a user setting RM=ToZero would WANT a different
result from SIN() than the same call with RM=RNE ?!?

I am not sure at all in specific case of sin() or in cases of other
standard functions from <math.h>.
But for user's own or 3rd party procedures you are probably right.

Computationally, this can be quite expensive

And contrary to how IEEE 754 has been used for 40 years.

I would not be so categorical.

Contrary to intentions of IEEE-754 committee?
Sure.

Contrary to real-world use of IEEE-754 compliant hardware?
That assumes that actual use (of non-default RMs) is somewhat
wide-spread, which I do not believe.

- having the meaning
of a calculation changed by changing FP state should (I hope so,
for corecntess's sake) flush any calculations done with the wrong
FP mode. Just calling a small library routine which does so could
be enough.

Oh, and BTW, how does a user CALL a subroutine to set his RM when
the RETURN undoes the very nature of his request ?!?

An example of the high cost is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121570 where, depending
on the library implementation, gfortran may be over-cautious
for the ieee_next_after function by saving and restoring fp state,
but I'm not sure that the overhead is actually from the FP state or
from calling extra functions.

So... What is the best way to do allow this to be more efficient?

UN DO this change to IEEE 754.

The CPU could speculate on the FP mode (not sure if that is actually
done). Other suggestions? How do current CPUs do so?

Multi-threaded cores already have to ship different RMs to FUs on
each FP instruction. The HW is all there--its the ISAs that are
screwed up.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

Fortran has an optional IEEE module. One of its important features
is that flags (IEEE exceptions) are set to quiet on entry of a procedure
and restored to signalling if it was signalling on entry, or keep it
signalling if it was raised on in the procedure. Similarly, rounding
modes are saved and restored for procedures. This is automatically
done if the right IEEE modules are used. A user can set rounding
modes or set and clear exceptions using the right modes.

How does a user set up his environment such that if TAN()* overflows
to infinity it returns with the OVERFLOW flag set ?!?

(*) EXP(), POW(,)

TAN and other numeric intrinsics are defined very loosely in the
standard: "The result has a value equal to a processor-dependent
approximation to tan(X)". Unfortunately, the language standard does
not define this, but allows IEEE_OVERFLOW to signal in that case.
In practice, all implementations I have tested do so.

Conversely, how does one write a TAN()* subroutine with the above property ?

IEEE_OVERFLOW on exit is IEEE_OVERFLOW on entry || IEEE_OVERFLOW
when it is raised in the procedure.

Conceptually, this is the right thing to do. A library routine should
not produce different results depending on what a user did for his
own calculations.

I would think that a user setting RM=ToZero would WANT a different
result from SIN() than the same call with RM=RNE ?!?

You have to explicitly use the IEEE modules for this behavior,
which the intrinsic procedures do not do.

An example for dot product:

module mymod
implicit none
contains
subroutine my_dot(a, b, r_down, r_up, error)
use, intrinsic :: iso_fortran_env, only : real64
use, intrinsic:: ieee_arithmetic
integer :: i
real(real64), dimension(:), intent(in) :: a, b
real(real64), intent(out) :: r_down,r_up
logical, intent(out) :: error
if (size(a) /= size(b)) then
error = .true.
return
end if
r_down = 0
call ieee_set_rounding_mode(IEEE_DOWN)
do i=1,size(a,1)
r_down = ieee_fma(a(i),b(i),r_down)
end do
call ieee_set_rounding_mode(IEEE_UP)
do i=1,size(a,1)
r_up = ieee_fma(a(i),b(i),r_up)
end do
call ieee_get_flag(IEEE_OVERFLOW, error)
call ieee_set_flag(IEEE_OVERFLOW,.false.)
end subroutine my_dot
end module mymod

program main
use, intrinsic :: iso_fortran_env, only : real64
use mymod
integer, parameter :: n = 1000
real(real64), dimension(n) :: a, b
real(real64) :: r_down, r_up, r_mid
logical :: error
call random_number(a)
call random_number(b)
a = a - 0.5
b = b - 0.5
call my_dot (a, b, r_down, r_up, error)
if (error) stop "Oh no!"
r_mid = dot_product(a,b)
print '(1P,E22.15)',r_down,r_mid,r_up
end program main

[...]

Oh, and BTW, how does a user CALL a subroutine to set his RM when
the RETURN undoes the very nature of his request ?!?

That's a no-op :-)

But the way to do it is just to call the IEEE routines directly.

An example of the high cost is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121570 where, depending
on the library implementation, gfortran may be over-cautious
for the ieee_next_after function by saving and restoring fp state,
but I'm not sure that the overhead is actually from the FP state or
from calling extra functions.

So... What is the best way to do allow this to be more efficient?

UN DO this change to IEEE 754.

Does IEEE 754 concern itself with how it is implemented in
programming languages? Terje?

The CPU could speculate on the FP mode (not sure if that is actually
done). Other suggestions? How do current CPUs do so?

Multi-threaded cores already have to ship different RMs to FUs on
each FP instruction. The HW is all there--its the ISAs that are screwed
up.

And that would be an interesting part - how to specify this
efficiently, and allow the microarchiteture not to flush when
rounding modes are changed.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Michael S <already5chosen@yahoo.com> schrieb:

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

OOOPS.

Seems I misread the standard, missing out on clause 17.4 paragraph 5,
which states

In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS,
the processor shall not change the rounding modes on entry, and
on return shall ensure that the rounding modes are the same as
they were on entry.

So, that part of my premise was wrong. Sorry.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 14 Sep 2025 10:19:08 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for
procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

OOOPS.

Seems I misread the standard, missing out on clause 17.4 paragraph 5,
which states

In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS,
the processor shall not change the rounding modes on entry, and
on return shall ensure that the rounding modes are the same as
they were on entry.

So, that part of my premise was wrong. Sorry.

Now it sounds like matching Kahan's intentions.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig wrote:

MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:

Thomas Koenig <tkoenig@netcologne.de> posted:

The CPU could speculate on the FP mode (not sure if that is actually
done). Other suggestions? How do current CPUs do so?

Multi-threaded cores already have to ship different RMs to FUs on
each FP instruction. The HW is all there--its the ISAs that are screwed
up.

And that would be an interesting part - how to specify this
efficiently, and allow the microarchiteture not to flush when
rounding modes are changed.

It has to sync-wait for all older FP instructions to finish executing.

The x87 had separate control and status registers but
SSE merged this into a single Control Status Register MXCSR.
In order to read the current control bits it must also read the status bits, and to read the status bits it must wait until all outstanding SSE FP instructions have executed because the status register flags are defined
as the OR of all the older FP instruction flags. But the FP status bits
are not usually updated with control so reading them was unnecessary.

On way is to have separate control registers for FP control
(round mode RM, exception enables XE, etc) and FP status,
and separate instructions to read and write them.
Additionally one could have RM and other controls on each FP instruction
which would allow one to change the RM without having to save, set and
restore the control register.

Additionally the x64's LDMXCSR and STMXCSR instructions load and store
the current MXCSR value but *only with memory*, not to an integer register.
Not only should these be separate CR and SR registers,
the should allow the old CR to be saved/restored with an integer register.

What it looks like most users want is a combined "copy current FP CR to
integer register and set masked CR field to immediate or int register".
That allows users to save & set just the RM without a sync-wait or
touching memory with 1 instruction, and restore later.

However it is not clear if this would be suitable for Fortran as you say:

Thomas Koenig wrote:

Fortran has an optional IEEE module. One of its important features
is that flags (IEEE exceptions) are set to quiet on entry of a procedure
and restored to signalling if it was signalling on entry, or keep it signalling if it was raised on in the procedure. Similarly, rounding
modes are saved and restored for procedures. This is automatically
done if the right IEEE modules are used. A user can set rounding
modes or set and clear exceptions using the right modes.

This sounds like Fortran's defined FP status algorithm requires it
read the both current control and status,
then set the RM and mask exceptions and clear the status bits,
and later restore the old control flags, and optionally OR with old status. Unfortunately reading the current status register forces the sync-wait.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Michael S <already5chosen@yahoo.com> wrote:

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)

2. Does above said mean that caller has no way of modifying rounding
mode used by callee? If true, it defeats one of original reasons for
which Kahan invented rounding modes in the first place.

The caller cannot change the callee's rounding mode without the
callee having been designed for this (by taking the rounding mode
as an extra argument and using IEEE_SET_ROUNDING_MODE itself).

I think that's a good idea. If a library routine is written
and debugged for a particular rounding mode, results should
not change because somebody up the call tree changed it.

Personally, I never found the whole rounding modes business useful in
my practice. So, can not say with straight face whether Fortran's take
on it is good idea or not. But I can say with good level of certainty
that William Kahan meant something else.

Kahan wrote a paper claiming that seting rounding mode to different
value is great debugging help, especially when no source is available.
So probably he really meant this. But first thing that authors of
numerical packages learn is to set rounding mode to desired value.
There are some codes which should work reasonably for all rounding
modes, but a lot of code critically depends on rounding and will
not work with different rounding mode. So, clearly this idea about
standard was wrong (as several other things in the standard).
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

OOOPS.

Seems I misread the standard, missing out on clause 17.4 paragraph 5,
which states

In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS,
the processor shall not change the rounding modes on entry, and
on return shall ensure that the rounding modes are the same as
they were on entry.

IIUC this means that user can not define routine like 'MY_SET_ROUNDING_MODE' and get desired effect (this probably can be worked around using
foreign function interface).
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 14 Sep 2025 10:52:10 +0300, Michael S wrote:

Personally, I never found the whole rounding modes business useful in my practice.

I remember one of Kahan’s writings suggesting it is useful for testing numeric stability: if your code gives results that differ only slightly in
the four different rounding modes, then your calculations are *probably* stable; if the results vary a lot, then your calculations are *probably* unstable.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Lawrence D’Oliveiro [2025-09-15 02:31:04] wrote:

On Sun, 14 Sep 2025 10:52:10 +0300, Michael S wrote:

Personally, I never found the whole rounding modes business useful in my
practice.

I remember one of Kahan’s writings suggesting it is useful for testing numeric stability: if your code gives results that differ only slightly in the four different rounding modes, then your calculations are *probably* stable; if the results vary a lot, then your calculations are *probably* unstable.

IIUC you can get the same result by adding a bit a noise to your inputs
and compare the output. Maybe it's easier to change rounding modes than
to add noise to your inputs?


Stefan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

Lawrence D’Oliveiro [2025-09-15 02:31:04] wrote:

On Sun, 14 Sep 2025 10:52:10 +0300, Michael S wrote:

Personally, I never found the whole rounding modes business useful in my >>> practice.

I remember one of Kahan’s writings suggesting it is useful for testing
numeric stability: if your code gives results that differ only slightly in >> the four different rounding modes, then your calculations are *probably*
stable; if the results vary a lot, then your calculations are *probably*
unstable.

IIUC you can get the same result by adding a bit a noise to your inputs
and compare the output.

No, because the result of changing rounding mode is highly correlated
with the inputs, whereas noise is uncorrelated.

Andrew.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 14 Sep 2025 16:22:33 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:

Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for
procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

OOOPS.

Seems I misread the standard, missing out on clause 17.4 paragraph
5, which states

In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS,
the processor shall not change the rounding modes on entry, and
on return shall ensure that the rounding modes are the same as
they were on entry.

IIUC this means that user can not define routine like
'MY_SET_ROUNDING_MODE' and get desired effect (this probably can be
worked around using foreign function interface).

I am not sure that I understood.
Do you want to say that user can not write routines that call IEEE_SET_ROUNDING_MODE ? I don't see anything in citation above that
suggests that.
Or do you mean something else?


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Michael S <already5chosen@yahoo.com> wrote:

On Sun, 14 Sep 2025 16:22:33 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:

Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sun, 14 Sep 2025 07:18:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 13 Sep 2025 14:55:58 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Similarly, rounding modes are saved and restored for
procedures.

I am not sure that I understand.
1. Is Fortran's equivalent of C's fesetround() is considered a
languge primitive rather than procedure?

Fortran has intrinsic procedures (like SIN, MATMUL or CPU_TIME),
procedures from intrinsic modules, like COMPILER_OPTIONS
from ISO_FORTRAN_ENV, and user-defined procedures.
IEEE_SET_ROUNDING_MODE is a procedure from an intrinsic module
(but an optional one). It need not be an external function;
the compiler is free to do other things to implement it.

(Hope this answers your question)

OOOPS.

Seems I misread the standard, missing out on clause 17.4 paragraph
5, which states

In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS,
the processor shall not change the rounding modes on entry, and
on return shall ensure that the rounding modes are the same as
they were on entry.

IIUC this means that user can not define routine like
'MY_SET_ROUNDING_MODE' and get desired effect (this probably can be
worked around using foreign function interface).

I am not sure that I understood.
Do you want to say that user can not write routines that call IEEE_SET_ROUNDING_MODE ? I don't see anything in citation above that
suggests that.

Of course thet can.

Or do you mean something else?

The citation above clearly requires that all changes to rounding
mode done during execution of user routine are undone at exit
from that routine. Consequenty _user_ routine can not change
rounding mode of the caller. In other words, user routine can
not offer alternative implementation of IEEE_SET_ROUNDING_MODE.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2