The GCC developers are proud to announce a new major GCC release, 13.1.

Apart from many bug fixes and enhancement this release includes
the following Fortran-relevant changes:

Fortran: Finalization is now fully supported.

OpenMP 5.0: Fortran now supports some non-rectangular loop nests;
for C/C++, the support was added in GCC 11.

Behavior on integer overflow

GCC 13 includes new optimizations which may change behavior on
integer overflow. Traditional code, like linear congruential
pseudo-random number generators in old programs and relying on
a specific, non-standard behavior may now generate unexpected
results. The option -fsanitize=undefined can be used to detect
such code at runtime.

It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
random number generators or, if the old behavior is desired, to use
the -fwrapv option. Note that this option can impact performance.

Please find more details at https://gcc.gnu.org/gcc-13/changes.html
and https://gcc.gnu.org/gcc-13/porting_to.html .

Enjoy!

.... should have been that Subject, of course.

I wrote

> Behavior on integer overflow
>
> GCC 13 includes new optimizations which may change behavior on
> integer overflow. Traditional code, like linear congruential
> pseudo-random number generators in old programs and relying on
> a specific, non-standard behavior may now generate unexpected
> results. The option -fsanitize=undefined can be used to detect
> such code at runtime.
>
> It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
> random number generators or, if the old behavior is desired, to use
> the -fwrapv option. Note that this option can impact performance.
>
> Please find more details at https://gcc.gnu.org/gcc-13/changes.html
> and https://gcc.gnu.org/gcc-13/porting_to.html .

.... and would have expected at least some comments on this one.

Did nobody read it, or have all uses outside of the Polyhedron
test suite for linear congruential pseudo-random number generators
vanished?

On Wed, 10 May 2023 16:58:27 +0000, Thomas Koenig wrote:

> I wrote
>
>> Behavior on integer overflow
>>
>> GCC 13 includes new optimizations which may change behavior on
>> integer overflow. Traditional code, like linear congruential
>> pseudo-random number generators in old programs and relying on
>> a specific, non-standard behavior may now generate unexpected
>> results. The option -fsanitize=undefined can be used to detect
>> such code at runtime.
>>
>> It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
>> random number generators or, if the old behavior is desired, to use
>> the -fwrapv option. Note that this option can impact performance.
>>
>> Please find more details at https://gcc.gnu.org/gcc-13/changes.html
>> and https://gcc.gnu.org/gcc-13/porting_to.html .
>
> ... and would have expected at least some comments on this one.
>
> Did nobody read it, or have all uses outside of the Polyhedron
> test suite for linear congruential pseudo-random number generators
> vanished?

Oh, there was much wailing and nashing of teeth in Fortran Discourse.
Comment 83 in https://fortran-lang.discourse.group/t/gfortran-releases/2704/90
starts the discussion, and I've deleted my comments as it was going no
where. In the rnflow.f90 code, the lcg has essentially
'integer, parameter :: jmul ..., jadd'. Giving either the 'volatile'
attribute defeats the new behavior.

--
steve

Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> schrieb:
> On Wed, 10 May 2023 16:58:27 +0000, Thomas Koenig wrote:
>
>> I wrote
>>
>>> Behavior on integer overflow
>>>
>>> GCC 13 includes new optimizations which may change behavior on
>>> integer overflow. Traditional code, like linear congruential
>>> pseudo-random number generators in old programs and relying on
>>> a specific, non-standard behavior may now generate unexpected
>>> results. The option -fsanitize=undefined can be used to detect
>>> such code at runtime.
>>>
>>> It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
>>> random number generators or, if the old behavior is desired, to use
>>> the -fwrapv option. Note that this option can impact performance.
>>>
>>> Please find more details at https://gcc.gnu.org/gcc-13/changes.html
>>> and https://gcc.gnu.org/gcc-13/porting_to.html .
>>
>> ... and would have expected at least some comments on this one.
>>
>> Did nobody read it, or have all uses outside of the Polyhedron
>> test suite for linear congruential pseudo-random number generators
>> vanished?
>
> Oh, there was much wailing and nashing of teeth in Fortran Discourse.
> Comment 83 in https://fortran-lang.discourse.group/t/gfortran-releases/2704/90
> starts the discussion, and I've deleted my comments as it was going no
> where. In the rnflow.f90 code, the lcg has essentially
> 'integer, parameter :: jmul ..., jadd'. Giving either the 'volatile'
> attribute defeats the new behavior.

I just looked through it, and it seems people didn't read the advice
to use -fwrapv.

And as far as linear congruential generates are concerned: I
guess the current advice is to just use C's unsigned numbers,
until the time when unsigned numbers are finally added to Fortran.

On Wed, 10 May 2023 18:29:56 +0000, Thomas Koenig wrote:

> Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> schrieb:
>> On Wed, 10 May 2023 16:58:27 +0000, Thomas Koenig wrote:
>>
>>> I wrote
>>>
>>>> Behavior on integer overflow
>>>>
>>>> GCC 13 includes new optimizations which may change behavior on
>>>> integer overflow. Traditional code, like linear congruential
>>>> pseudo-random number generators in old programs and relying on
>>>> a specific, non-standard behavior may now generate unexpected
>>>> results. The option -fsanitize=undefined can be used to detect
>>>> such code at runtime.
>>>>
>>>> It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
>>>> random number generators or, if the old behavior is desired, to use
>>>> the -fwrapv option. Note that this option can impact performance.
>>>>
>>>> Please find more details at https://gcc.gnu.org/gcc-13/changes.html
>>>> and https://gcc.gnu.org/gcc-13/porting_to.html .
>>>
>>> ... and would have expected at least some comments on this one.
>>>
>>> Did nobody read it, or have all uses outside of the Polyhedron
>>> test suite for linear congruential pseudo-random number generators
>>> vanished?
>>
>> Oh, there was much wailing and nashing of teeth in Fortran Discourse.
>> Comment 83 in https://fortran-lang.discourse.group/t/gfortran-releases/2704/90
>> starts the discussion, and I've deleted my comments as it was going no
>> where. In the rnflow.f90 code, the lcg has essentially
>> 'integer, parameter :: jmul ..., jadd'. Giving either the 'volatile'
>> attribute defeats the new behavior.
>
> I just looked through it, and it seems people didn't read the advice
> to use -fwrapv.

I re-iterated that advice in one of my comments and also
showed that -fsanitize=undefined gives a runtime warning
that undefined behavior was occurring.

In fact, if the LCG of rnflow.f90 were in another file,
say,lcg.f90 and compiled separately, there is no problem.
As is, gfortran in-lines rnflow's lcg and then the
optimizers can see the initial seed will cause a signed
integer overflow.

> And as far as linear congruential generates are concerned: I
> guess the current advice is to just use C's unsigned numbers,
> until the time when unsigned numbers are finally added to Fortran.

That's what I do for both a prng and hashes.

--
steve

On Wednesday, May 10, 2023 at 11:30:00 AM UTC-7, Thomas Koenig wrote:

(snip)

> And as far as linear congruential generates are concerned: I
> guess the current advice is to just use C's unsigned numbers,
> until the time when unsigned numbers are finally added to Fortran.

More generally, it is sometimes nice to be able to a multiply,
signed or unsigned, and get the double length product.

No high-level languages seem to make that easy.

For C compilers, if you cast 32 bit (long) to (long long) and
multiply, most will do a 32 bit multiply with 64 bit product.
I believe also for (unsigned long long).

It is also sometimes nice to be able to do a divide with double
length dividend, as most hardware allows.

I am not sure by now, which hardware supports a 64x64 multiply
with 128 bit product, or divide with 128 bit dividend. If some do,
it would be nice to be able to use it.

gah4 <gah4@u.washington.edu> schrieb:
> On Wednesday, May 10, 2023 at 11:30:00 AM UTC-7, Thomas Koenig wrote:
>
> (snip)
>
>> And as far as linear congruential generates are concerned: I
>> guess the current advice is to just use C's unsigned numbers,
>> until the time when unsigned numbers are finally added to Fortran.
>
> More generally, it is sometimes nice to be able to a multiply,
> signed or unsigned, and get the double length product.

$ cat a.f90
program memain
use iso_fortran_env
integer(kind=int32) :: a, b
integer(kind=int64) :: c

read (*,*) a, b
c = int(a,kind=int64) * int(b,kind=int64)
print *,a,b,c
end program memain
$ gfortran a.f90
$ echo "12345678 23456789" | ./a.out
12345678 23456789 289589963907942

(And compilers have been smart enough for a few decades to use
widening multiply in such situations).

> No high-level languages seem to make that easy.

I think the cod above is fairly easy.

>
> For C compilers, if you cast 32 bit (long) to (long long) and
> multiply, most will do a 32 bit multiply with 64 bit product.
> I believe also for (unsigned long long).

Yes (also not hard).

> It is also sometimes nice to be able to do a divide with double
> length dividend, as most hardware allows.
>
> I am not sure by now, which hardware supports a 64x64 multiply
> with 128 bit product,

These days, any 64-processor does.

>or divide with 128 bit dividend. If some do,
> it would be nice to be able to use it.

That, I believe, is not so generally implemented in hardware.