# GFortran releases **URL:** \ **Category:** Announcements\ **Created:** [January 31, 2022, 3:25pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704 "2022-01-31T15:25:57Z")\ **Posts on this page:** 19\ **Page:** 5
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [May 3, 2023, 6:04pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/88 "2023-05-03T18:04:06Z")
GCC 13.1 was released on April 26th. The Release Notes mention Fortran just twice: ### OpenMP - OpenMP 5.0: Fortran now supports some non-rectangular loop nests; for C/C++, the support was added in GCC 11 ### Fortran - Finalization is now fully supported. There are also a few dozen [bugs claimed to be fixed](https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&limit=0&order=component%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=FIXED&target_milestone=13.0) The only environment (from quite a few) I use that offers gcc-13.1 as of today is Homebrew. ---
**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\ **Post date:** [May 3, 2023, 6:34pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/89 "2023-05-03T18:34:55Z")
> [@msz59](#): > > The only environment (from quite a few) I use that offers gcc-13.1 as of today is Homebrew. FreeBSD ports as well. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [May 3, 2023, 6:45pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/90 "2023-05-03T18:45:43Z")
> [@msz59](#): > > The only environment (from quite a few) I use that offers gcc-13.1 as of today is Homebrew. Also MSYS2: [Base Package: mingw-w64-gcc - MSYS2 Packages](https://packages.msys2.org/base/mingw-w64-gcc) And Linux Fedora 38: [gcc-13.1.1-1.fc38 | Build Info | koji](https://koji.fedoraproject.org/koji/buildinfo?buildID=2192856) ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [May 3, 2023, 10:01pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/91 "2023-05-03T22:01:16Z")
I’m on Arch Linux and it’s available there. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [May 4, 2023, 7:49am UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/92 "2023-05-04T07:49:54Z")
Thomas Koenig announced GFortran 13.1 on comp.lang.fortran: [https://groups.google.com/g/comp.lang.fortran/c/OTphp3EQFtg](https://groups.google.com/g/comp.lang.fortran/c/OTphp3EQFtg) To the two Fortran novelties already announced he added these notes: > **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 [GCC 13 Release Series — Changes, New Features, and Fixes - GNU Project](https://gcc.gnu.org/gcc-13/changes.html) > and [Porting to GCC 13 - GNU Project](https://gcc.gnu.org/gcc-13/porting_to.html) . ---
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [May 4, 2023, 8:40pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/93 "2023-05-04T20:40:47Z")
Unfortunately, the PDT issues remain. The @han190’s code given [here](https://fortran-lang.discourse.group/t/a-gfortran-issue-with-parameterized-derived-types/) still segfaults at runtime. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 4, 2023, 11:01pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/94 "2023-05-04T23:01:02Z")
> [@vmagnin](#): > > 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. What is the new behavior and what is the workaround? I use linear congruential generators to generate hash values and checksums, and in these cases, I expect the overflows to wrap, mod 2^32. If this is no longer the behavior, then what is the workaround? > [@vmagnin](#): > > 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. The intrinsic RANDOM\_NUMBER() only returns floating point values. For applications like hash codes and checksums, one usually wants integer values. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 5, 2023, 12:21am UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/96 "2023-05-05T00:21:33Z")
From that text, it is not the fortran standard that defines the behavior but rather “the processor”, which in practice means the compiler, operating system, and runtime libraries that they use. So if gfortran (or any other compiler) defined arithmetic so that LCGs work as expected, then those arithmetic operations would not be prohibited, which is a long way of saying they would be allowed (as they have been in fortran processors for some 60+ years). I understand that the fortran standard does not require LCGs to work, but I do think it allows them to work. So I don’t think it is correct for gfortran to try to hide behind the standard for a decision that it made itself. Also, I don’t understand why specifying -fwrapv would adversely impact performance. It seems like it would be the other way around. If the overflows are trapped, that is what would take the effort, not ignoring them. If not, then what am I missing here? Given that gfortran is changing legacy behavior, Instead of a compiler option, my preference to address this would have been something more local in the source code. For example, a source code directive, or perhaps an intrinsic function that the compiler would inline, or a mode function that turns off the unwanted behavior temporarily. The ability to ignore integer overflow is only preferred in very limited places, so you don’t want to change compiler options on a whole program just to get a few specific multiplications to work right, just those few places where you want overflows to wrap. Are these the first adverse comments on this new feature that you have encountered? ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 5, 2023, 7:09am UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/98 "2023-05-05T07:09:45Z")
> [@kargl](#): > > It also appears the brokenness of LCG’s has been lurking in GCC, was only recently noticed, diagnosed, and a recommendation set forth. I read from this that other gcc languages, including C and C++, are also going to have difficulty implementing LCGs efficiently. LCGs are a common part of many algorithms, not just random number generators, but also the hashes and checksums that I mentioned, cryptography, security, and so on. LCGs are used within other encryption algorithms, primarily because they require just an integer multiplication and possibly an integer addition. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 5, 2023, 4:08pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/100 "2023-05-05T16:08:51Z")
> [@kargl](#): > > It seems you have found a good use case for an argument to J3 for `integer, unsigned :: i`. There have always been many good use cases for unisgned integers. However, with twos-complement arithmetic, multiplications, additions, etc. all work the same in the hardware for signed and unsigned integers. The only difference is how numerical values are assigned to the resulting bits. That is why things like LCGs have always worked correctly in fortran on such hardware, they are really doing 32-bit unsigned arithmetic modulo 2\*\*32 beneath the surface. And as you pointed out before, if the processor works that way, then the fortran standard allows the programmer to take advantage of that arithmetic feature. Of course we all understand that that behavior cannot be incorporated into the standard because the standard must also accommodate other signed integer conventions, ones-complement, signed magnitude, biased, etc. This all seems like it would be an important topic to me. I’m surprised that the gcc people (not just the gfortran people) have not had more push-back for this change from legacy behavior. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 5, 2023, 4:28pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/102 "2023-05-05T16:28:54Z")
Even the people writing compilers, gcc included, use hashes and checksums and LCGs internally. Certainly the people writing operating systems with these languages use them. By changing conventions so that LCGs can no longer be implemented, they are knowingly shooting themselves in the foot. My point was that the compiler writers should be the first ones to recognize the problem. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 5, 2023, 7:53pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/104 "2023-05-05T19:53:12Z")
> [@kargl](#): > > Here’s the leading comment to one of math library codes. In this 1988 article is the sentence, “As a convention we frequently advise our students to respond with the 9 digits of their social security number.” How times have changed! Regarding your sample codes, these all rely on the convention that the integer overflows that occur in the statement ```auto jsee = jsee * jm + ja ``` are silently ignored. The issue being discussed was that those overflows are no longer ignored in the new gcc/gfortran. Right? If the new gcc/gfortran is still treating these overflows the same as before, then this whole discussion has been a red herring. I’m not sure I understand why the results were wrong in the second run, with the -O compiler option. This is a compiler error, not a code error, right? Is it inlining the code, but missing the fact that the `intent(inout)` argument is modified? ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 5, 2023, 10:43pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/106 "2023-05-05T22:43:29Z")
> [@kargl](#): > > And, you can ask the compiler to detect the problem for you, which also prevent the optimization. The `-fsanitize=undefined` option is in the announcement reposted here. Do you mean that `-fsanitize=undefined` prevents the function from being inlined? That is a little surprising. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 6, 2023, 2:55am UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/108 "2023-05-06T02:55:45Z")
> [@kargl](#): > > ```auto > integer, parameter :: jm = 843314861 > integer, parameter :: ja = 453816693 > > ``` Just out of curiosity, what happens if the above lines are changed to ```auto integer, parameter :: jm = 5 integer, parameter :: ja = 3 ``` so that no integer overflow occurs. Does the -O version still print the same value every iteration of the DO loop? ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [May 6, 2023, 8:42am UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/109 "2023-05-06T08:42:27Z")
> [@kargl](#): > > Better yet, gfortran is in dire need of new contributors. I suspect a person bearing patches would be welcomed with opened arms. People interested by contributing to GFortran should read that post: > [@Loop variable reaching integer \`huge\` causes infinite loop](https://fortran-lang.discourse.group/t/loop-variable-reaching-integer-huge-causes-infinite-loop/5045/27): > > If anyone here would be interested in joining the gfortran developers team, send an email to [gfortran@gcc.gnu.org](mailto:gfortran@gcc.gnu.org) or myself at [jvdelisle@gcc.gnu.org](mailto:jvdelisle@gcc.gnu.org). We have set up a gfortran workspace on MatterMost cloud to facilitate chat, patch discussions, mentoring new folks, etc. We just started this up a few weeks ago. I like that it has live chat via phone, web browser interface and a desktop version. I run on Linux and do a little on Windows operating systems. As an administrator I can send you an … ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [May 6, 2023, 5:10pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/111 "2023-05-06T17:10:50Z")
Yes. For the moment, the free Mattermost instance is still online and we have time: > Upgrade to paid plan to keep your workspace > Cloud Free will be deprecated in 81 days. Upgrade to a paid plan or contact sales. And @JerryD has begun discussions with that university. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [August 12, 2023, 10:05am UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/112 "2023-08-12T10:05:09Z")
> [@vmagnin](#): > > And @JerryD has begun discussions with that university. Well, the [Oregon State University Open Source Lab](https://osuosl.org/) is now hosting the GFortran Mattermost instance: [https://gfortran-mm.osuosl.org/](https://gfortran-mm.osuosl.org/) Those people made a great job, importing the whole content of the previous instance. One thousand thanks! 🙏 As stated above by @JerryD : > If anyone here would be interested in joining the gfortran developers team, send an email to [gfortran@gcc.gnu.org](mailto:gfortran@gcc.gnu.org) or myself at [jvdelisle@gcc.gnu.org](mailto:jvdelisle@gcc.gnu.org). ---
**Author:** ![Walt](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/walt/32/2465_2.png) [@Walt](https://fortran-lang.discourse.group/u/Walt)\ **Post date:** [August 13, 2023, 3:22pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/113 "2023-08-13T15:22:46Z")
“like 1-2 hours of intense compiling using every single thread your CPU has, and typically with computer’s fans spinning fast” Sometimes I forget why I liked my Dell R820 with 40 cores… even though it cost me $6 per month to run in the garage and it wasn’t as performant as my new desktop… man could it compile code fast. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [August 13, 2023, 5:18pm UTC](https://fortran-lang.discourse.group/t/gfortran-releases/2704/114 "2023-08-13T17:18:36Z")
> [@Pap](#): > > A solution to the problem is to download and compile the GCC bundle yourself (I typically compile only what’s needed for gfortran). A faster solution is to install a Linux binary build. I had for example tested successfully a nightly build in an Ubuntu, following these steps: [https://fortranwiki.org/fortran/show/GFortran#testing\_the\_latest\_nightly\_build](https://fortranwiki.org/fortran/show/GFortran#testing_the_latest_nightly_build) [Previous page](https://fortran-lang.discourse.group/t/gfortran-releases/2704.md?page=4)