[patch, fortran, doc] Explicitly mention undefined overflow

[patch, fortran, doc] Explicitly mention undefined overflow

[Thomas Koenig]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Here's also an update on the docs to explicitly mention behavior
on overflow.

Maybe this will reach another 0.05% of users...

OK for trunk?

Best regards

	Thomas

gcc/fortran/ChangeLog:

	* gfortran.texi: Mention behavior on overflow.

[-- Attachment #2: overflow.diff --]
[-- Type: text/x-patch, Size: 1414 bytes --]

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index c483e13686d..93c66b18938 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -820,6 +820,7 @@ might in some way or another become visible to the programmer.
 * File operations on symbolic links::
 * File format of unformatted sequential files::
 * Asynchronous I/O::
+* Behavior on integer overflow::o
 @end menu
 
 
@@ -1160,6 +1161,23 @@ sytems, such as Linux, it is necessary to specify @option{-pthread},
 @c Maybe this chapter should be merged with the 'Standards' section,
 @c whenever that is written :-)
 
+@node Behavior on integer overflow
+@section Behavior on integer overflow
+@cindex integer overflow
+@cindex overflow handling
+
+Integer overflow is prohibited by the Fortran standard.  The behavior
+of gfortran on integer overflow is undefined by default.  Traditional
+code, like linear congruential pseudo-random number generators in old
+programs that rely on specific, non-standard behavior may generate
+unexpected results.  The @option{-fsanitize=undefined} option can be
+used to detect such code at runtime.
+
+It is recommended to use the intrinsic subroutine @code{RANDOM_NUMBER}
+for random number generators or, if the old behavior is desired, to
+use the @option{-fwrapv} option.  Note that this option can impact
+performance.
+
 @node Extensions
 @chapter Extensions
 @cindex extensions

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hi Thomas,

Yes, that's fine for trunk. I wonder if it is worth being explicit that
linear congruential pseudo-random number generators can and do fail at -O3?

Thanks for the doc patches!

Paul


On Sun, 19 Mar 2023 at 08:32, Thomas Koenig via Fortran <fortran@gcc.gnu.org>
wrote:

> Here's also an update on the docs to explicitly mention behavior
> on overflow.
>
> Maybe this will reach another 0.05% of users...
>
> OK for trunk?
>
> Best regards
>
>         Thomas
>
> gcc/fortran/ChangeLog:
>
>         * gfortran.texi: Mention behavior on overflow.
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Andreas Schwab]

On Mär 19 2023, Thomas Koenig via Gcc-patches wrote:

> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> index c483e13686d..93c66b18938 100644
> --- a/gcc/fortran/gfortran.texi
> +++ b/gcc/fortran/gfortran.texi
> @@ -820,6 +820,7 @@ might in some way or another become visible to the programmer.
>  * File operations on symbolic links::
>  * File format of unformatted sequential files::
>  * Asynchronous I/O::
> +* Behavior on integer overflow::o

s/o$//

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Thomas Koenig]

Hi Paul,

> Yes, that's fine for trunk. I wonder if it is worth being explicit that
> linear congruential pseudo-random number generators can and do fail at -O3?

I don't think we should put this into the docs, because that can change
at any time.  Maybe into porting_to.html, though (where I have only
mentioned this as a general issue with linear congruential generators,
without mentioning specific options. Current text can be seen at
https://gcc.gnu.org/gcc-13/porting_to.html ).

Hm....

Best regards

	Thomas

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Thomas Koenig]

I wrote:

> 
>> Yes, that's fine for trunk. I wonder if it is worth being explicit that
>> linear congruential pseudo-random number generators can and do fail at 
>> -O3?
> 
> I don't think we should put this into the docs, because that can change
> at any time.  Maybe into porting_to.html, though (where I have only
> mentioned this as a general issue with linear congruential generators,
> without mentioning specific options. Current text can be seen at
> https://gcc.gnu.org/gcc-13/porting_to.html ).
> 
> Hm....

Breaking things actually goes back further than I thought.
Taking the random number generator from rnseed and running
it 10 times with my system gfortran 9.4.0 gets me, at
different levels of optimization:

$ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done
-O0
   0.269411892
   0.891386986
   0.444042951
   0.779210865
   0.500058949
   0.666437685
   0.666963458
   0.462416053
   0.376364112
    2.90278494E-02
-O1
   0.269411892
   0.891386986
   0.444042951
   0.779210865
   0.500058949
   0.666437685
   0.666963458
   0.462416053
   0.376364112
    2.90278494E-02
-O2
  -0.730588138
   0.891386986
  -0.555957019
  -0.220789105
  -0.499941051
   0.666437685
  -0.333036542
   0.462416053
   0.376364112
    2.90278494E-02

and for current trunk it is

$ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done
-O0
   0.269411892
   0.891386986
   0.444042951
   0.779210865
   0.500058949
   0.666437685
   0.666963458
   0.462416053
   0.376364112
    2.90278494E-02
-O1
   0.269411892
   0.891386986
   0.444042951
   0.779210865
   0.500058949
   0.666437685
   0.666963458
   0.462416053
   0.376364112
    2.90278494E-02
-O2
   0.211324871
   0.211324871
   0.211324871
   0.211324871
   0.211324871
   0.211324871
   0.211324871
   0.211324871
   0.211324871
   0.211324871

so it the general problem is not restricted to -O3 and not
to current trunk, it depends on the details.

I doubt that the result from 9.4.0 was expected, but rather
nobody noticed.  Or, bringing out the pseudo-RNG into a
different setting changed things.

So... any suggestions on how to improve the current wording?

Best regards

	Thomas

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Harald Anlauf]

Hi Thomas,

Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches:
> so it the general problem is not restricted to -O3 and not
> to current trunk, it depends on the details.
> 
> I doubt that the result from 9.4.0 was expected, but rather
> nobody noticed.  Or, bringing out the pseudo-RNG into a
> different setting changed things.
> 
> So... any suggestions on how to improve the current wording?

how about changing:

"... relying on a specific, non-standard behavior may now generate 
unexpected results."

to

"... relying on a specific, non-standard behavior may generate 
unexpected results depending on optimization level and other compiler 
flags."

We cannot know all the codes used in the wild ...

Cheers,
Harald

> Best regards
> 
>      Thomas
> 
> 

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Harald Anlauf]

Hi Thomas,

Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches:
> so it the general problem is not restricted to -O3 and not
> to current trunk, it depends on the details.
>
> I doubt that the result from 9.4.0 was expected, but rather
> nobody noticed.  Or, bringing out the pseudo-RNG into a
> different setting changed things.
>
> So... any suggestions on how to improve the current wording?

how about changing:

"... relying on a specific, non-standard behavior may now generate
unexpected results."

to

"... relying on a specific, non-standard behavior may generate
unexpected results depending on optimization level and other compiler
flags."

We cannot know all the codes used in the wild ...

Cheers,
Harald

> Best regards
>
>      Thomas
>
>