[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005

--- Comment #5 from Wileam Yonatan Phan  ---
Hi Steve,

I think I recognize you from the Fortran-lang Discourse forum!

> The committee is ready to vote, but it is still a non-existent standard.

That's technically true, since the votes haven't been cast, yet.

> The first thing required for gfortran to support any F2023 feature would be 
> the addition of a -std=f2023.  This has not been implemented, yet.

That is correct, and I guess work on implementing the `-std=f2023` flag will
start as soon as the standard is agreed upon and published. Do you know when
the committee will meet to vote?

> I'll also note that things don't magically appear in gfortran. Someone has to 
> implement it.

Hopefully I will be able to implement this particular part (REDUCE) as part of
my GSoC '22 project
. The
second phase of the project specifically addresses support in the parser, and
the third phase implements the actual parallelization.

So, my intention on filing this bug is to have a public record for tracking my
project's progress. I'll also periodically blog about it at
 and


Wish me luck!

Thanks,
Wil

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005

--- Comment #2 from Wileam Yonatan Phan  ---
Wait, I thought the committee is ready to vote on it? I've seen the draft of
the summary paper by Reid linked from here:

[Bug fortran/106005] New: (F2023) Support for REDUCTION clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005

Bug ID: 106005
   Summary: (F2023) Support for REDUCTION clause in DO CONCURRENT
loop
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wileamyp at outlook dot com
  Target Milestone: ---

GFortran 12.1.0 refuses to compile the following valid code under Fortran 2023.

$ cat dc-reduce.f90

PROGRAM dcreduce
  INTEGER, PARAMETER :: n = 10
  INTEGER :: ivec(n)
  ivec = [( i, i = 1, n )]
  ival = 0
  DO CONCURRENT (i=1:n) REDUCE(+:ival)
ival = ival + ivec(i)
  END DO
  PRINT *, ival
END PROGRAM

$ gfortran --version
GNU Fortran (Spack GCC) 12.1.0
Copyright (C) 2022 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 dc-reduce.f90
dc-reduce.f90:7:24:

7 |   DO CONCURRENT (i=1:n) REDUCE(+:ival)
  |1
Error: Syntax error in DO statement at (1)
dc-reduce.f90:9:5:

9 |   END DO
  | 1
Error: Expecting END PROGRAM statement at (1)

At the time of writing, only NVIDIA nvfortran compiles this successfully and
gives the correct result. Tested with nvfortran 22.5.

$ nvfortran --version

nvfortran 22.5-0 64-bit target on x86-64 Linux -tp zen2 
NVIDIA Compilers and Tools
Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.

$ nvfortran dc-reduce.f90
$ ./a.out 
   55

[Bug fortran/102003] [PDT] Length of character component not simplified

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003

Wileam Yonatan Phan  changed:

   What|Removed |Added

 CC||wileamyp at outlook dot com

--- Comment #1 from Wileam Yonatan Phan  ---
Behavior confirmed with master@ff91735a5b8. The error message seems to change
if this code block is commented out in gcc/fortran/expr.cc

---

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index be94c18c836..e5a3df214d7 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3201,12 +3201,14 @@ gfc_match_init_expr (gfc_expr **result)
   return m;
 }

+  #if 0
   if (gfc_derived_parameter_expr (expr))
 {
   *result = expr;
   gfc_init_expr_flag = false;
   return m;
 }
+  #endif

   t = gfc_reduce_init_expr (expr);
   if (!t)

---

Anyway, the new error message is

pr102003.f90:6:33:

6 |   integer, parameter :: m = len (p% c)  ! rejected
  | 1
Error: Parameter ‘p’ at (1) has not been declared or is a variable, which does
not reduce to a constant expression

Maybe something doesn't work properly in gfc_reduce_init_expr()?

[Bug fortran/103567] Compile error with assumed-rank RESULT variable

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103567

--- Comment #1 from Wileam Yonatan Phan  ---
Surprisingly, this one compiles just fine:

subroutine f(y)
  real, intent(out) :: y(..)
end subroutine f

[Bug fortran/103567] New: Compile error with assumed-rank RESULT variable

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103567

Bug ID: 103567
   Summary: Compile error with assumed-rank RESULT variable
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wileamyp at outlook dot com
  Target Milestone: ---

The following code:

function f() result(y)
  real :: y(..)
end function f

gives a bogus error message at compile time:

assumedrank.f90:1:22:

1 | function f() result(y)
  |  1
Error: Assumed-rank array at (1) must be a dummy argument

The same error message is also given with the following code:

function f()
  real :: f(..)
end function f

assumedrank.f90:1:0:

1 | function f()
  | 
Error: Assumed-rank array at (1) must be a dummy argument

[Bug fortran/103172] ICE in gfc_check_init_expr, at fortran/expr.c:3014

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103172

--- Comment #2 from Wileam Yonatan Phan  ---
Comment on attachment 51758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51758
Source code for minimal reproducer

>function assumed_rank_crash ( arr ) result( res )
>  implicit none
>
>  ! Arguments
>  real, intent(in) :: arr(..)
>  integer :: shparr = SHAPE(arr)
>  real :: res(shparr)
>
>  return
>end function assumed_rank_crash

Here's a condensed version that still reproduces the ICE.

function assumed_rank_crash ( arr )
  real :: arr(..)
  integer :: shparr = SHAPE(arr)
end function assumed_rank_crash

[Bug fortran/103172] New: ICE in gfc_check_init_expr, at fortran/expr.c:3014

[wileamyp at outlook dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103172

Bug ID: 103172
   Summary: ICE in gfc_check_init_expr, at fortran/expr.c:3014
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wileamyp at outlook dot com
  Target Milestone: ---

Created attachment 51758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51758=edit
Source code for minimal reproducer

Hi,

I'd like to report an internal compiler error (ICE) when using the SHAPE
intrinsic on assumed-rank arrays on GFortran 10.3.0 (Ubuntu
10.3.0-1ubuntu1~20.04). I have tested the code on godbolt.org for various
versions of GFortran. Version 11 and newer seem to correctly produce an error
message instead of producing an ICE, but all older versions reproduce the ICE.

A minimal reproducer is attached here.

Thanks,
Wileam Y. Phan