From Newsgroup: comp.lang.fortran

From https://gcc.gnu.org/gcc-16/changes.html :

- 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.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Fri, 1 May 2026 10:30:31 -0000 (UTC), Thomas Koenig wrote:

From https://gcc.gnu.org/gcc-16/changes.html :

- 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.

In addition to those listed by Thomas, gfortran 16.1
also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Here, log(y) is evaluated iff the condition is
true; otherwise, the other branch is evaluated.
--
steve
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

By the way, do you need the parentheses around the expression?
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Fri, 1 May 2026 22:34:42 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

1) Why re-invent the wheel in language design?

2) It is not exactly the same as C. You can
read the working draft of the Fortran standard
to learn more. One can use a conditional
expression as an actual argument to a subprogram
with an optional dummy argument.

call foo((y > 0 ? y : .nil.))

If the condition is true, you have

call foo(y)

if it is false you have

call foo()

By the way, do you need the parentheses around the expression?

Yes, you do.
--
steve

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 01:39:14 -0000 (UTC), Steven G. Kargl wrote:

On Fri, 1 May 2026 22:34:42 -0000 (UTC), Lawrence DrCOOliveiro wrote:

Doing it exactly the same way as C (which introduced this syntax)
and just about every other language which adopted the feature
afterwards ... except Python.

1) Why re-invent the wheel in language design?

Why indeed. I consider the Python way to be one of the few really bad
mistakes in its language design.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

Lawrence DrCOOliveiro wrote:

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

By the way, do you need the parentheses around the expression?

I first encountered that syntax in Algol68, this was around 1976.
There it would have been
x := (y > 0 | log (y) | some_error_fcn (x)) ;

- I can't remember if underscore is a permitted character in a variable
or a function name.
- The semicolon at the end is only required if another statement follows.
The first edition of my Algol68 manual was published in 1972 so I think
we can assume C got it from Algol68 (or they both got it from some other language).
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 11:57:05 +0200, R Daneel Olivaw wrote:

Lawrence DrCOOliveiro wrote:

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

By the way, do you need the parentheses around the expression?

I first encountered that syntax in Algol68, this was around 1976.
There it would have been
x := (y > 0 | log (y) | some_error_fcn (x)) ;

- I can't remember if underscore is a permitted character in a variable
or a function name.
- The semicolon at the end is only required if another statement follows.
The first edition of my Algol68 manual was published in 1972 so I think
we can assume C got it from Algol68 (or they both got it from some other language).

During the discussion of the syntax, J3 (standardization committee)
considered a few different syntax. They, of course, converged on
what is now in the Fortran standard. I haven't tried to verify,
but rather infer, that at least one committee member is/was active
in the algol standardization process. For those interested, they
can go to the J3 Fortran website and look at the documents from
2020-2022 to see the evolution of conditional expressions.

I forgot to mention an important aspect of a conditional expression,
and that is short-circuiting can occur. Consider,

if (a > b .and. c > foo(a)) then

Here, the Fortran standard does not specify the order of evaluation
for a > b and c > foo(a). In addition, both operands of .and. will
be evaluated. If foo(a) has a side-effect, an unfortuante thing
may occur. (Yes, a function with a side-effct is evil). Now, with
conditional expressions,

(a > b .and. c > foo(a) ? LFT : RGT)

it is evaluated left-to-right. If a > b is false, c > foo(a) is
not evaluated and RGT is selected.
--
steve



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On 5/1/2026 6:30 AM, Thomas Koenig wrote:

From https://gcc.gnu.org/gcc-16/changes.html :

- 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.

Native gfortran (including gcc, c++) compiler for Windows on Arm (Arm64)
is available.

https://www.equation.com/servlet/equation.cmd?fa=fortran



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

Trivia question: how many Middle Eastern nations can you name that have a minister convicted for terrorism-related offences under that countryrCOs *own* laws in its Government?


On Sat, 6 Jun 2026 20:51:01 -0400, JL wrote:

Native gfortran (including gcc, c++) compiler for Windows on Arm
(Arm64) is available.

[link omitted]

I wouldnrCOt describe site as adware-infested, but ... I hover over the rCLInstall nowrCY link, and I see a doubleclick URL.
--- Synchronet 3.22a-Linux NewsLink 1.2