From Newsgroup: comp.compilers

On Mon, 23 Jan 2023 18:50:31 -0800, gah4 wrote:

As far as I can tell, Fortran makes no claims regarding
fixed point overflow, being undefined or system dependent.

It makes claims. F2018 (18-007r1.pdf), p. 148.

The execution of any numeric operation whose result is
not defined by the arithmetic used by the processor is
prohibited.

If you want to go back to F66, one finds in Sec. 6.4,
"Evaluation of Experssions."

No element may be evaluated whose values is not
mathematically defined.

--
steve
[Like I said, IBM didn't promise that SSP would work anywhere else. -John]
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.compilers

On Thursday, January 26, 2023 at 11:00:02 AM UTC-8, gah4 wrote:

(snip)

Now, the original subject of this thread, is the cost vs. benefit of such optimizations. Not so obvious the benefit, but there is a cost when people try to debug programs where things are optimized away.

[Gee, it's been a while since I thought about SSP. I believe that IBM wrote it largely to give people code that would get reasonable numeric answers
with the 360's funky floating point. Then there were a few odds and ends
like RANDU. They never promised the code would work on anything other
than IBM 360 Fortran. -John]

It seems that there is also SSP for the IBM 1130, which is 16 bit binary,
so probably also a 32 bit two's complement integer.

There is a PL/I SSP, but seems not to have RANDU.

When I was in high school, we had CALL/OS, with PL/I, and
I used the RANDU algorithm, as I didn't have any other one.

As you say, it wasn't promised to work with any other Fortran,
but others did try to stay compatible with IBM.
(But often with non-IBM extensions.)

Fortran systems that I know, are good at ignoring fixed point
overflow, though often trap or count floating point overflow.
[I took a look, RANDU on the 1130 repeated after 2^13 items.
Yow. -John]
--- Synchronet 3.21b-Linux NewsLink 1.2