Re: [PATCH v7 2/4] p1689r5: initial support

[Jason Merrill via Fortran]

On 7/2/23 12:32, Ben Boeckel wrote:

This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.

Support is communicated through the following three new flags:

- `-fdeps-format=` specifies the format for the output. Currently named
   `p1689r5`.

- `-fdeps-file=` specifies the path to the file to write the format to.

- `-fdeps-target=` specifies the `.o` that will be written for the TU
   that is scanned. This is required so that the build system can
   correlate the dependency output with the actual compilation that will
   occur.

CMake supports this format as of 17 Jun 2022 (to be part of 3.25.0)
using an experimental feature selection (to allow for future usage
evolution without committing to how it works today). While it remains
experimental, docs may be found in CMake's documentation for
experimental features.

Future work may include using this format for Fortran module
dependencies as well, however this is still pending work.

[P1689R5]: https://isocpp.org/files/papers/P1689R5.html
[cmake-experimental]: 
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst

TODO:

- header-unit information fields

Header units (including the standard library headers) are 100%
unsupported right now because the `-E` mechanism wants to import their
BMIs. A new mode (i.e., something more workable than existing `-E`
behavior) that mocks up header units as if they were imported purely
from their path and content would be required.

- non-utf8 paths

The current standard says that paths that are not unambiguously
represented using UTF-8 are not supported (because these cases are rare
and the extra complication is not worth it at this time). Future
versions of the format might have ways of encoding non-UTF-8 paths. For
now, this patch just doesn't support non-UTF-8 paths (ignoring the
"unambiguously representable in UTF-8" case).

- figure out why junk gets placed at the end of the file

Sometimes it seems like the file gets a lot of `NUL` bytes appended to
it. It happens rarely and seems to be the result of some
`ftruncate`-style call which results in extra padding in the contents.
Noting it here as an observation at least.


Thank you for your patience, just a few tweaks left and I think we can 
put this all in this week or next.



diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h
index aef703f8111..141cfd60eda 100644
--- a/libcpp/include/cpplib.h
+++ b/libcpp/include/cpplib.h
@@ -302,6 +302,9 @@ typedef CPPCHAR_SIGNED_T cppchar_signed_t;
  /* Style of header dependencies to generate.  */
  enum cpp_deps_style { DEPS_NONE = 0, DEPS_USER, DEPS_SYSTEM };
  
+/* Structured format of module dependencies to generate.  */

+enum cpp_fdeps_format { DEPS_FMT_NONE = 0, DEPS_FMT_P1689R5 };


These should be FDEPS_FMT_* or just FDEPS_*.


@@ -395,10 +423,16 @@ make_write (const cpp_reader *pfile, FILE *fp, unsigned 
int colmax)
   if (colmax && colmax < 34)
 colmax = 34;
 
+  /* Write out C++ modules information if no other `-fdeps-format=`

+ option is given. */
+  cpp_fdeps_format fdeps_format = CPP_OPTION (pfile, deps.fdeps_format);
+  bool write_make_modules_deps = fdeps_format == DEPS_FMT_NONE &&
+CPP_OPTION (pfile, deps.modules);


We typically format an expression like this as:


+  bool write_make_modules_deps = (fdeps_format == FDEPS_FMT_NONE
+ && CPP_OPTION (pfile, deps.modules));



@@ -473,6 +507,117 @@ deps_write (const cpp_reader *pfile, FILE *fp, unsigned 
int colmax)
   make_write (pfile, fp, colmax);
 }
 
+static void

+p1689r5_write_filepath (const char *name, FILE *fp)


This and the other p1689r5 functions need more comments, at least one at 
the top explaining their purpose.


Jason

Re: [PATCH] Fortran: improve diagnostic message for COMMON with automatic object [PR32986]

[Steve Kargl via Fortran]

On Wed, Aug 23, 2023 at 09:16:08PM +0200, Harald Anlauf via Fortran wrote:
> 
> here's a simple patch for a very old PR that suggests a more helpful
> error message for an automatic object in a COMMON.  The patch also
> suppresses the less helpful old error message after the new one has
> been emitted.
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> 

OK.  I leave the decision on backporting to you.

-- 
Steve

[PATCH] Fortran: improve diagnostic message for COMMON with automatic object [PR32986]

[Harald Anlauf via Fortran]

Dear all,

here's a simple patch for a very old PR that suggests a more helpful
error message for an automatic object in a COMMON.  The patch also
suppresses the less helpful old error message after the new one has
been emitted.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From 829c0c06fe7ba2cf3e83508b95999b884b21236d Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Wed, 23 Aug 2023 21:08:01 +0200
Subject: [PATCH] Fortran: improve diagnostic message for COMMON with automatic
 object [PR32986]

gcc/fortran/ChangeLog:

	PR fortran/32986
	* resolve.cc (is_non_constant_shape_array): Add forward declaration.
	(resolve_common_vars): Diagnose automatic array object in COMMON.
	(resolve_symbol): Prevent confusing follow-on error.

gcc/testsuite/ChangeLog:

	PR fortran/32986
	* gfortran.dg/common_28.f90: New test.
---
 gcc/fortran/resolve.cc  | 15 ++-
 gcc/testsuite/gfortran.dg/common_28.f90 |  7 +++
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/common_28.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index ce8261d646a..1042b8c18e8 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -959,6 +959,10 @@ cleanup:
 }


+/* Forward declaration.  */
+static bool is_non_constant_shape_array (gfc_symbol *sym);
+
+
 /* Resolve common variables.  */
 static void
 resolve_common_vars (gfc_common_head *common_block, bool named_common)
@@ -1007,6 +1011,15 @@ resolve_common_vars (gfc_common_head *common_block, bool named_common)
 	gfc_error_now ("%qs at %L cannot appear in COMMON "
 		   "[F2008:C5100]", csym->name, >declared_at);

+  if (csym->attr.dimension && is_non_constant_shape_array (csym))
+	{
+	  gfc_error_now ("Automatic object %qs at %L cannot appear in "
+			 "COMMON at %L", csym->name, >declared_at,
+			 _block->where);
+	  /* Avoid confusing follow-on error.  */
+	  csym->error = 1;
+	}
+
   if (csym->ts.type != BT_DERIVED)
 	continue;

@@ -16612,7 +16625,7 @@ resolve_symbol (gfc_symbol *sym)
   /* Resolve array specifier. Check as well some constraints
  on COMMON blocks.  */

-  check_constant = sym->attr.in_common && !sym->attr.pointer;
+  check_constant = sym->attr.in_common && !sym->attr.pointer && !sym->error;

   /* Set the formal_arg_flag so that check_conflict will not throw
  an error for host associated variables in the specification
diff --git a/gcc/testsuite/gfortran.dg/common_28.f90 b/gcc/testsuite/gfortran.dg/common_28.f90
new file mode 100644
index 000..9b583b9948d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/common_28.f90
@@ -0,0 +1,7 @@
+! { dg-do compile }
+! PR fortran/32986 - Improve diagnostic message for COMMON with automatic object
+
+function a(n)
+  real :: x(n) ! { dg-error "Automatic object" }
+  common /c/ x ! { dg-error "cannot appear in COMMON" }
+end function
--
2.35.3

Re: Help with fortran pointer ans OpenACC

[Tobias Burnus]

Hi,

On 23.08.23 12:19, Patrick Begou via Fortran wrote:

For several days I have some trouble with OpenACC offloading and
fortran pointers. I'm testing with a very small peace of code to
investigate but I do not progress for several days and I need your help.

Could someone give me advices or a small explanation on what I have
not understood there ?


First, for debugging, using -fdump-tree-original -fdump-tree-gimple
-fdump-tree-omplower and looking at the file .* might
help - grep for '#pragma'; this shows the internal representation
(incomplete) in a C like output. That's how I spotted the issue below.

* * *

For gfortran, the issue is:

!$acc parallel loop collapse(2) default(present) if(runongpu)

It works if you add a "present(current)" → see also newly filed
https://gcc.gnu.org/PR16

gfortran seems to follow - but not completely - the spec:

Quoting from OpenACC 3.2: "2.6.2 Variables with Implicitly Determined
Data Attributes":

"A scalar variable will be treated as if it appears either:

* In a copy clause if the compute construct is a kernels construct.
* In a firstprivate clause otherwise.

Note: Any default(none) clause visible at the compute construct applies
to both aggregate and scalar variables. However, any default(present)
clause visible at the compute construct applies only to aggregate
variables."

However, the glossary defines:

"Aggregate variables – a variable of any non-scalar datatype, including
array or composite variables.
In Fortran, this includes any variable with allocatable or pointer
attribute and character variables."

And, as you have a (scalar) Fortran pointer, the following should have
applied instead:

"An aggregate variable will be treated as if it appears either:
• In a present clause if there is a default(present) clause visible at
the compute construct.
• In a copy clause otherwise."

* * *

Thus: It looks as if your program is valid, adding 'present(current)'
will fix it for gfortran (and Cray?), 'default(...)' and implicit
mapping is confusing, and there is now a gfortran PR to track this
issue: https://gcc.gnu.org/PR16

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Help with fortran pointer ans OpenACC

[Patrick Begou via Fortran]

Hi everyone!

For several days I have some trouble with OpenACC offloading and fortran 
pointers. I'm testing with a very small peace of code to investigate but 
I do not progress for several days and I need your help.


The attached code goal is just to initialize some data on the GPU and is 
representative of my problem on a very large code.


   - It works fine with nvfortran (22.11)

   - it do not work with Gnu fortran (14.0.0 20230822 - experimental) 
   => invalid memory

   - it do not work with  Cray Fortran (15.1) => wrong results

so I think the problem is the code, not the compiler.

It is also difficult to find some openACC offloading examples using 
Fortran pointers and I'm stuck with this problem.


Could someone give me advices or a small explanation on what I have not 
understood there ?


Thanks for your help

Patrick


Code details:

- all my fortran modules are grouped in the same file for simplification 
of the provided test-case.


- compilation with GNU Firtran is: "gfortran -cpp -g -fopenacc grouped.f90"

- setting  "runongpu=.false." line 7 (no GPU) the result is:

 Default init OK
 Default value OK

- setting  "runongpu=.true." line 7 (no GPU) the result is:

Default init OK
libgomp: cuStreamSynchronize error: an illegal memory access was encountered

- with nvhpc/22.11 and "runongpu=.true.", built with  "nvfortran 
-acc=gpu,noautopar  -gpu=cc80 -Minfo=accel grouped.f90"


Default init OK
Default value OK
!=
! Just to say run on the device or not.
!=
module openacc_defs

  implicit none
  logical, save :: runongpu=.true.
end module openacc_defs



!=
! Data structure for r2_tab and r2_ptr to manage pointers.
! r2_ptr is used in an allocatable array for a dynamivc number of r2_tab variables
! but could be used later in chained lists
! Memory is allocated on GPU each time.
!=

module tab_m

  implicit none

 type r2_tab
 double precision, dimension(:,:), allocatable :: val
 integer :: dim1
 integer :: dim2
 end type r2_tab

 type r2_ptr
 type(r2_tab), pointer :: ptr
 type(r2_ptr), pointer :: next
 end type r2_ptr


contains

subroutine  new_r2_tab(tab,n,m)
implicit none
integer, intent(in) ::n,m
type(r2_tab), pointer, intent(inout) ::tab
!

   if (.not. associated(tab)) allocate(tab)
   if (allocated(tab%val)) deallocate(tab%val)

   allocate (tab%val(n,m))
   tab%dim1=n
   tab%dim2=m
   tab%val(:,:)=1.0D0 
   !$acc enter data create(tab)
   !$acc enter data create(tab%val)
end subroutine new_r2_tab

end module tab_m

!=
! This module implements data processing (just an initialization here)
! if runongpu is .true. initialization is run on the GPU and then host is updated.
!=
module manage_data
   use openacc_defs
   use tab_m
   implicit none

   contains

   subroutine set_default_val_gpu(liste, defval, nitems)
 implicit none
 integer, intent(in) :: nitems
 double precision, intent(in) :: defval
 type(r2_ptr), dimension(nitems) :: liste

 type(r2_tab), pointer :: current=>null()
 integer:: item,j,k

 do item=1, nitems
current=>liste(item)%ptr
!print*,current%dim1, current%dim2,size(current%val)

!$acc parallel loop collapse(2) default(present) if(runongpu)
do k=1, current%dim2
   do j=1, current%dim1
  current%val(j,k)=defval
   end do
end do
!$acc update if(runongpu) host(current%val)
 end do
   end subroutine set_default_val_gpu

end module manage_data


!=
! main program.
!
!=

program main
  use tab_m
  use manage_data
  implicit none

  integer, parameter:: N=5
  type(r2_ptr), dimension(N) :: liste
  integer:: i,j,k
  type(r2_tab), pointer :: current=>null()
  double precision :: total

 ! Initialize 
 do i=1,N
 nullify(liste(i)%ptr)
 nullify(liste(i)%next)
 end do

 ! Allocate (do not manage "next" pointer, all elements are set to 1.0)
 do i=1,N
call new_r2_tab(liste(i)%ptr,N,i*N)
 end do

 ! Check all is correct on host side
 do i=1,N
if (sum(liste(i)%ptr%val) .NE. N*i*N) then
   write(6,*)"Something goes wrong",sum(liste(i)%ptr%val)," != ",N*i*N
   STOP (1)
end if
 end do
 write(6,*) "Default init OK"

 ! Update on host (runongpu is false)
 call 

Re:

[Arjen Markus via Fortran]

Hello,

gfortran is certainly an option, I use an installation from equation.com,
but there are other possibilities as well. The best solution does depend a
bit on your actual requirements.

Regards,

Arjen

Op di 22 aug 2023 om 15:06 schreef Mamadou Diop via Fortran <
fortran@gcc.gnu.org>:

> I am a retired scientist and have some fortan programs and looking for an
> open source fortran compiler.
> Regards ?
>
> Mamadou Diop
>
> Envoyé à partir de Courrier
> pour Windows
>
>