# Gcc/gfortran 16 released

**URL:** <https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870>\
**Category:** GNU\
**Created:** [April 23, 2026, 6:21pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870 "2026-04-23T18:21:51Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [April 23, 2026, 6:21pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/1 "2026-04-23T18:21:51Z")

</div>

FYI.

Here are the changes listed on the [gcc website](https://gcc.gnu.org/gcc-16/changes.html#fortran)

- Coarrays using native shared memory mulithreading on single node machines and handling Fortran 2018’s `TEAM` feature.
- Fortran 2003: Parameterized Derived Types support is improved. Handling of LEN parameters works but still requires a future change of representation (see PR82649).
- Fortran 2018: Support the extensions to the `IMPORT` statement, the `REDUCE` intrinsic and the new `GENERIC` statement.
- The Fortran 2023 additions to the trigonometric functions are now supported (such as the `sinpi` intrinsic).
- Fortran 2023: The `split` intrinsic subroutine is now supported and `c_f_pointer` now accepts an optional lower bound as a argument.
- The `-fexternal-blas64` option has been added to call external BLAS routines with 64-bit integer arguments for `MATMUL`. This option is only valid for 64-bit systems and when `-ffrontend-optimize` is in effect.

Of these the shared memory version of co-arrays is probably the biggest addition along with improved PDT support

---

<div class="post-metadata">

**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:** [April 23, 2026, 9:10pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/2 "2026-04-23T21:10:28Z")

</div>

I have tested it with a recent nightly build (see the [Fortran Wiki](https://fortranwiki.org/fortran/show/GFortran#contributing) for instructions), using two small demos computing Pi by Monte Carlo with corrays and collectives. GFortran automatically used 8 threads on my machine:

```bash
$ /usr/local/bin/gfortran -fcoarray=lib coarrays.f90 -lcaf_shmem
$ ./a.out
   3.1415699479999999 
$ /usr/local/bin/gfortran -fcoarray=lib collective.f90 -lcaf_shmem
$ ./a.out
   3.1415925240000000     
$ /usr/local/bin/gfortran --version
GNU Fortran (GCC) 16.0.1 20260405 (experimental)
Copyright © 2026 Free Software Foundation, Inc.

```

According to @jerryd , the option `-lcaf_shmem` is temporarily necessary, until an option like `-fcoarray=shared` is added in a later release. Note also that I had to put the option `-lcaf_shmem` _at the end of the command_ for the linker.

Also tested with the GFortran 16.0.1 (20260321) already [available in Fedora 44 Beta](https://packages.fedoraproject.org/pkgs/gcc/gcc-gfortran/fedora-44.html).

GFortran 16.1 should be released on April, 30th. Today it is the RC.

---

<div class="post-metadata">

**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:** [April 23, 2026, 9:27pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/3 "2026-04-23T21:27:47Z")

</div>

Also tested with my parallel Buddhabrot demo: [gtk-fortran-extra/parallel\_app at main · vmagnin/gtk-fortran-extra · GitHub](https://github.com/vmagnin/gtk-fortran-extra/tree/main/parallel_app)

And note that you can set the number of images with the variable:

```bash
$ export GFORTRAN_NUM_IMAGES=8

```

else GFortran automatically uses the number of available cores.

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [April 23, 2026, 11:21pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/4 "2026-04-23T23:21:54Z")

</div>

> [@vmagnin](#):
>
> GFortran 16.1 should be released on April, 30th. Today it is the RC.

Thanks. I didn’t see that it was an RC on the web site. I hope the shmem version of CAF performs better than the current MPI based version which (at least on an 8 core Ryzen) doesn’t perform at all and usually “deadlocks”. I have not bothered to dig very deep into the standard CAF implementation (have used Cray’s CAF before) due to the horrendous performance (at least for me) on multi-core “single node” workstations. If the Gfortran shmem version shows a usable speedup then I hope it will lead to further adoption and improvement as more people like me finally start to use CAF.

---

<div class="post-metadata">

**Author:** ![wspector](https://avatars.discourse-cdn.com/v4/letter/w/47e85d/32.png) [@wspector](https://fortran-lang.discourse.group/u/wspector)\
**Post date:** [April 24, 2026, 12:14am UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/5 "2026-04-24T00:14:21Z")

</div>

As of last September (2025) they also added F2023 conditional expressions. (A feature Fortran should have had 60+ years ago - if only IBM had listened to John McCarthy.) Particularly with Fortran, it should be useful for simplifying handling optional arguments, where the `merge` intrinsic doesn’t work.

---

<div class="post-metadata">

**Author:** ![rgaelzer](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@rgaelzer](https://fortran-lang.discourse.group/u/rgaelzer)\
**Post date:** [April 25, 2026, 5:04pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/6 "2026-04-25T17:04:30Z")

</div>

> [@wspector](#):
>
> As of last September (2025) they also added F2023 conditional expressions. (

Really? Which version?

I tried this very simple test:

```auto
!Test conditional expressions in Fortran 2023.
!Ref: Metcalf, 6th Ed. Section 23.2.3 Conditional expressions and arguments
!OBS: still not implemented in ifx v. 2025.3.3 and gfortran 15.2.1

program tes_conditional_expressions
implicit none
real :: x, val
call random_number(x)
print’(a,g0)', ‘x= ‘, x
val= (x > 0.5 ? x : 0.0 )
print’(a,g0)’, 'val= ', x
end program tes_conditional_expressions

```

Right now, the latest gfortran version distributed by Fedora repo is:

GNU Fortran (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7)

And the error message is:

**`tes_conditional_expressions.f90:11:14:`** ` `  
` `  
` 11 | val= (x > 0.5 ? x : 0.0 )`  
` | ` **`1`** ` `  
**`Error:`** `Expected a right parenthesis in expression at`**`(1)`**

---

<div class="post-metadata">

**Author:** ![wspector](https://avatars.discourse-cdn.com/v4/letter/w/47e85d/32.png) [@wspector](https://fortran-lang.discourse.group/u/wspector)\
**Post date:** [April 25, 2026, 5:37pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/7 "2026-04-25T17:37:17Z")

</div>

> [@rgaelzer](#):
>
> Really? Which version?

V16.

Here is a fun little test program I put together a few months ago:

```auto
program cond_expr
  implicit none

  integer :: i, ival, j
  integer, allocatable :: ivals(:), results(:)

  real, allocatable :: rvals(:)

! Use with statement function
  integer :: ce_sgn
  real :: f
  ce_sgn (f) = (f < 0.0 ? -1 : &
                f > 0.0 ? 1 : &
                0)

! Present vs non-present args
  ival = init (null ())
  print *, (ival == -99 ? "pass" : "fail")
  
  ival = init (42)
  print *, (ival == 42 ? "pass" : "fail")

! Simple scalar test
  ival = (.true. ? 1 : 0)
  print *, 'ival =', ival

! Nested CE in the true position, rather than the else position
  j = 4
  do, i=1,5
    ival = (i == 1 ? (j > 5 ? -1 : -5) : &
            i == 2 ? -2 : &
            i == 3 ? -3 : &
                      0)
    print *, i, ival
  end do

! Earlier gfortran failure. Now passes.
  print *, (.true. ? 1 : 0)

! Factorial
  do, i=0,10
    print *, 'factorial of', i, ' =', fact (i)
  end do

  ivals = [1, 2, 3, 4, 5, 6, 7, 8]
  results = pfact (ivals)
  print *, 'results =', results

! From McCarthy's 1959 Letter to the Editor in CACM
  i = (1 < 2 ? 4 : &
       1 >= 2 ? 3 : 0)
  print *, 'McCarthy 1: ', (i == 4 ? "pass" : "fail")

  i = (2 < 1 ? 4 : &
       2 > 1 ? 3 : &
       2 > 1 ? 2 : 0)
  print *, 'McCarthy 2: ', (i == 3 ? "pass" : "fail")

  i = (2 < 1 ? 4 : &
       .true. ? 3 : 0)
  print *, 'McCarthy 3: ', (i == 3 ? "pass" : "fail")

! i = (2 < 1 ? 0/0 : &
! .true. ? 3 : 0)
! print *, 'McCarthy 4: ', (i == undefined ? "pass" : "fail")

! i = (2 < 1 ? 3 : &
! .true. ? 0/0 : 0)
! print *, 'McCarthy 5: ', (i == undefined ? "pass" : "fail")

! i = (2 < 1 ? 3 : &
! 4 < 1 ? 4 : undefined)
! print *, 'McCarthy 6: ', (i == undefined ? "pass" : "fail")

! Simulate arithmetic IF with SELECT CASE

  rvals = [-42.0, -.001, 0.0, .042, 4.2]
  do, i = 1, size (rvals)
    select case (ce_sgn (rvals(i)))
    case (-1)
      print *, rvals(i), ': negative'
    case (0)
      print *, rvals(i), ': zero'
    case (1)
      print *, rvals (i), ': positive'
    case default
      print *, rvals (i), ': should never happen'
    end select
  end do

contains

  integer function init (i)
    integer, intent(in), optional :: i

    integer :: dummy

    init = (present (i) ? i : -99)
    dummy = (present (i) ? &
        printout ("init: arg present") : &
        printout ("init: arg absent"))
  end function

  recursive elemental function fact (i) result (res)
    integer, intent(in) :: i
    integer :: res

    res = (i<=1 ? &
              1 : &
              i*fact (i-1))

  end function

  recursive pure function pfact (ia) result (res)
    integer, intent(in) :: ia(:)
    integer, allocatable :: res(:)

    if (size (ia) == 1) then
      res = fact (ia(1))
    else
      res = [fact (ia(1)), pfact (ia(2:))]
    end if

  end function

  integer function printout (s)
    character(*), intent(in) :: s
    
    print *, s
    
  end function
end program

```

```auto
$ gfortran --version
GNU Fortran (GCC) 16.0.1 20260410 (experimental)
Copyright (C) 2026 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gfortran condexpr.f90
$ ./a.out
 init: arg absent
 pass
 init: arg present
 pass
 ival = 1
           1 -5
           2 -2
           3 -3
           4 0
           5 0
           1
 factorial of 0 = 1
 factorial of 1 = 1
 factorial of 2 = 2
 factorial of 3 = 6
 factorial of 4 = 24
 factorial of 5 = 120
 factorial of 6 = 720
 factorial of 7 = 5040
 factorial of 8 = 40320
 factorial of 9 = 362880
 factorial of 10 = 3628800
 results = 1 2 6 24 120 720 5040
 McCarthy 1: pass
 McCarthy 2: pass
 McCarthy 3: pass
  -42.0000000 : negative
  -1.00000005E-03 : negative
   0.00000000 : zero
   4.19999994E-02 : positive
   4.19999981 : positive
$

```

---

<div class="post-metadata">

**Author:** ![rgaelzer](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@rgaelzer](https://fortran-lang.discourse.group/u/rgaelzer)\
**Post date:** [April 25, 2026, 6:14pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/8 "2026-04-25T18:14:06Z")

</div>

Right, thanks.

I’ll test it when Fedora includes it in the repo.

---

<div class="post-metadata">

**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:** [April 25, 2026, 7:14pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/9 "2026-04-25T19:14:35Z")

</div>

I have just created this repository with a buddhabrot example:

> **[GitHub - vmagnin/coarray\_examples: Modern Fortran examples using parallel features...](https://github.com/vmagnin/coarray_examples)**
>
> Modern Fortran examples using parallel features like coarrays, collective subroutines, etc.

> `ppm_coarray_buddhabrot.f90` is a CLI program drawing a [Buddhabrot](https://en.wikipedia.org/wiki/Buddhabrot) in a [portable pixmap binary format (PPM)](https://en.wikipedia.org/wiki/Netpbm#File_formats) file, a very basic uncompressed image file format. Each Fortran _image_ is computing its own Buddhabrot, and they are finally summed using the `co_sum()` _collective subroutine._ The process is therefore very similar to what is done in astrophotography.

---

<div class="post-metadata">

**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\
**Post date:** [April 28, 2026, 9:19pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/10 "2026-04-28T21:19:08Z")

</div>

> [@rwmsu](#):
>
> Coarrays using native shared memory mulithreading on single node machines and handling Fortran 2018’s `TEAM` feature.

Does it mean it won’t require OpenCoarrays to build parallel programs? I’m using Homebrew for Linux to get latest gfortran (still 15.2 there) but unfortunately the `opencoarrays` package requires `gcc@13` which seems quite out-of-date now that v16 has been released.

---

<div class="post-metadata">

**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\
**Post date:** [April 28, 2026, 9:26pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/11 "2026-04-28T21:26:07Z")

</div>

The announcement made there is for **shared** memory parallelism. For **distributed** memory parallelism with coarray one still needs OpenCoarrays to enhance gfortran (AFAIK).

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [April 28, 2026, 9:59pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/12 "2026-04-28T21:59:17Z")

</div>

I’m probably very wrong about this but I think OpenCoarrays is just the interface to a version of MPI thats used for the transport layer. The standard CAF syntax is built into the compiler so any backend that acts as a transport layer for communicating between processors or threads can be used to implement CAF. I think the NAG implementation of CAF is shared memory. My best guess is that the gfortran shared memory version of CAF is built on top of OpenMP or maybe some native implementation using Pthreads etc. So no I don’t think you will need OpenCoarrays unless you want to write something that can be used on a massively parallel distributed memory machine (think a Cray with thousands of cores etc). However, if I’m going to run on a Cray I would used Cray’s compilers.

---

<div class="post-metadata">

**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:** [April 29, 2026, 8:11am UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/13 "2026-04-29T08:11:42Z")

</div>

> [@msz59](#):
>
> Does it mean it won’t require OpenCoarrays to build parallel programs?

Exactly, on single node machines, you just need to install GFortran 16.1 (just like you just need to install Intel ifx to use coarrays). I am playing with it and it works nicely.

GCC 16.1 should be released officially tomorrow. It will then arrive progressively in all packaging systems.

---

<div class="post-metadata">

**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:** [April 29, 2026, 8:48am UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/14 "2026-04-29T08:48:38Z")

</div>

> [@rwmsu](#):
>
> My best guess is that the gfortran shared memory version of CAF is built on top of OpenMP or maybe some native implementation using Pthreads etc.

It is using a `caf_shmem` library:

> **[Shared-memory Coarrays (The GNU Fortran Compiler)](https://gcc.gnu.org/onlinedocs/gfortran/Shared-memory-Coarrays.html)**
>
> Shared-memory Coarrays (The GNU Fortran Compiler)

But I don’t know what is under the hood. I am going to ask Jerry and report here.

---

<div class="post-metadata">

**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:** [April 29, 2026, 9:33am UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/15 "2026-04-29T09:33:21Z")

</div>

Meanwhile, we can see a `thread_support.c` file in the tree: [Making sure you're not a bot!](https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgfortran/caf/shmem;h=b00cd6a9e228ed1077ca7b118c18a5c2f5993112;hb=HEAD)

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [April 29, 2026, 2:05pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/16 "2026-04-29T14:05:50Z")

</div>

A quick look at the source code shows references to pthreads if WIN32 and CYGWYN are not defined. Does WIndows support pthreads? If so it appears to be based on pthreads. As a side note, a [Fortran pthread package](https://dl.acm.org/doi/10.1145/569147.569152) was written by Richard Hanson, Henry Gabb and Clay Breshears (AKA [Mr. Concurrency](https://www.oreilly.com/library/view/the-art-of/9780596802424/)) around 2002. Richard, Henry, Clay and I all worked for or was affiliated with the old DoD HPCMP Programming Environments and Training (PET) program at the time. Richard was working with Rice University at the time and I lent him a two processor Pentium Pro box I had put together to use as a work station until he got official access to the DoD systems. There also appears to be a more recent Fortran Pthreads library based on [F2003](https://dl.acm.org/doi/abs/10.1145/2558889)

---

<div class="post-metadata">

**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:** [April 29, 2026, 2:06pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/17 "2026-04-29T14:06:14Z")

</div>

> [@rwmsu](#):
>
> My best guess is that the gfortran shared memory version of CAF is built on top of OpenMP or maybe some native implementation using Pthreads etc.

Indeed, according to @JerryD : _“The library is using pthreads if it is available”._

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [April 29, 2026, 10:40pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/18 "2026-04-29T22:40:48Z")

</div>

GCC16 has an [Algol68 Front-End](https://gcc.gnu.org/wiki/Algol68FrontEnd). One of the recent additions is a way to call C from Algol so Fortran can be called too. No sign of how to go the other way round.

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [April 29, 2026, 10:52pm UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/19 "2026-04-29T22:52:24Z")

</div>

Yes I saw the Algol front end mentioned on the GCC web site. There also appears to be a GCC Rust compiler under development but I don’t know enough about Rust to compare it with the standard compiler. I will say if I was going to make the effort to learn a new language it would probably be Rust. I think Microsoft has announced they are rewritting parts of Windows in Rust.

---

<div class="post-metadata">

**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:** [April 30, 2026, 8:17am UTC](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870/20 "2026-04-30T08:17:39Z")

</div>

> [@rwmsu](#):
>
> I will say if I was going to make the effort to learn a new language it would probably be Rust.

Rust is definitely a nice language to learn, for discovering new programming and computing concepts and rediscovering classical ones. I have read last year that book to acquire the basics (which does not mean it is a book for beginners, it is definitely for people knowing already several languages):

> **[Programming with Rust](https://www.pearson.com/en-us/subject-catalog/p/programming-with-rust/P200000007289/9780137889396)**

And I am now deepening my understanding with:

> **[Rust in Action - Tim McNamara](https://www.manning.com/books/rust-in-action)**
>
> A hands-on guide to systems programming with Rust. Written for inquisitive programmers, it presents real-world use cases that go far beyond syntax and structure.

Two books that are very well-designed.

[Next page](https://fortran-lang.discourse.group/t/gcc-gfortran-16-released/10870.md?page=2)