[committed] Fortran: Fix (mostly) comment typos

[Tobias Burnus]

Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da

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
commit 7ebd4a1d61993c0a75e9ff3098aded21ef04a4da
Author: Tobias Burnus 
Date:   Fri Apr 28 09:23:18 2023 +0200

Fortran: Fix (mostly) comment typos

Only other changes are fixing the variable name a(b)breviated_modproc_decl
and a few typos in gfortran.texi.

gcc/fortran/ChangeLog:

* gfortran.texi: Fix typos.
* decl.cc: Fix typos in comments and in a variable name.
* arith.cc: Fix comment typos.
* check.cc: Likewise.
* class.cc: Likewise.
* dependency.cc: Likewise.
* expr.cc: Likewise.
* frontend-passes.cc: Likewise.
* gfortran.h: Likewise.
* intrinsic.cc: Likewise.
* iresolve.cc: Likewise.
* match.cc: Likewise.
* module.cc: Likewise.
* primary.cc: Likewise.
* resolve.cc: Likewise.
* simplify.cc: Likewise.
* trans-array.cc: Likewise.
* trans-decl.cc: Likewise.
* trans-expr.cc: Likewise.
* trans-intrinsic.cc: Likewise.
* trans-openmp.cc: Likewise.
* trans-stmt.cc: Likewise.

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index ddf9874671c..d1d814b3ae1 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1037 +1037 @@ gfc_arith_concat (gfc_expr *op1, gfc_expr *op2, gfc_expr **resultp)
- to get mismaching types here.  */
+ to get mismatching types here.  */
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 8c1ae8c2f00..b348bda6e6c 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -96 +96 @@ illegal_boz_arg (gfc_expr *x)
-/* Some precedures take two arguments such that both cannot be BOZ.  */
+/* Some procedures take two arguments such that both cannot be BOZ.  */
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index bffc03a..9d0c802b867 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -1634 +1634 @@ finalizer_insert_packed_call (gfc_code *block, gfc_finalizer *fini,
-   derived type "derived". The function first calls the approriate FINAL
+   derived type "derived". The function first calls the appropriate FINAL
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 233bf244d62..9c4b40d4ac4 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1084 +1084 @@ char_len_param_value (gfc_expr **expr, bool *deferred)
-  /* If gfortran gets an EXPR_OP, try to simplifiy it.  This catches things
+  /* If gfortran gets an EXPR_OP, try to simplify it.  This catches things
@@ -1579 +1579 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
-	 length of 1.  However, as an argument they are also iteroperable
+	 length of 1.  However, as an argument they are also interoperable
@@ -2850 +2850 @@ variable_decl (int elem)
-  /* The dummy arguments and result of the abreviated form of MODULE
+  /* The dummy arguments and result of the abbreviated form of MODULE
@@ -3120 +3120 @@ variable_decl (int elem)
-  /* Before adding a possible initilizer, do a simple check for compatibility
+  /* Before adding a possible initializer, do a simple check for compatibility
@@ -8351 +8351 @@ gfc_match_end (gfc_statement *st)
-  bool abreviated_modproc_decl = false;
+  bool abbreviated_modproc_decl = false;
@@ -8375 +8375 @@ gfc_match_end (gfc_statement *st)
-  abreviated_modproc_decl = gfc_state_stack->previous->sym
+  abbreviated_modproc_decl = gfc_state_stack->previous->sym
@@ -8383,2 +8383,2 @@ gfc_match_end (gfc_statement *st)
-  if (!abreviated_modproc_decl)
-abreviated_modproc_decl = gfc_current_block ()
+  if (!abbreviated_modproc_decl)
+abbreviated_modproc_decl = gfc_current_block ()
@@ -8398 +8398 @@ gfc_match_end (gfc_statement *st)
-  if (!abreviated_modproc_decl)
+  if (!abbreviated_modproc_decl)
@@ -8407 +8407 @@ gfc_match_end (gfc_statement *st)
-  if (!abreviated_modproc_decl)
+  if (!abbreviated_modproc_decl)
@@ -8536 +8536 @@ gfc_match_end (gfc_statement *st)
-			   abreviated_modproc_decl ? "END PROCEDURE"
+			   abbreviated_modproc_decl ? "END PROCEDURE"
@@ -8554 +8554 @@ gfc_match_end (gfc_statement *st)
-  gfc_error ("Expecting %s statement at %L", abreviated_modproc_decl
+  gfc_error ("Expecting %s statement at %L", abbreviated_modproc_decl
diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index 9117825ee6e..a648d5c7903 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -546 +546 @@ gfc_dep_difference (gfc_expr *e1, gfc_expr *e2, mpz_t *result)
-  /* Inizialize tentatively, clear if we don't return anything.  */
+  /* I

Re: [PATCH] OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]

[Tobias Burnus]

On 27.04.23 20:36, Julian Brown wrote:

This patch fixes several cases where multiple attach or detach mapping
nodes were being created for stand-alone attach or detach clauses
in Fortran.  After the introduction of stricter checking later during
compilation, these extra nodes could cause ICEs, as seen in the PR.

The patch also fixes cases that "happened to work" previously where
the user attaches/detaches a pointer to array using a descriptor, and
(I think!) the "_data" field has offset zero, hence the same address as
the descriptor as a whole.

Tested with offloading to nvptx. OK?


LGTM for mainline and, after some grace period, for GCC 13.

Thanks,

Tobias


2023-04-27  Julian Brown  

  PR fortran/109622

gcc/fortran/
  * trans-openmp.cc (gfc_trans_omp_clauses): Attach/detach clause fixes.

gcc/testsuite/
  * gfortran.dg/goacc/attach-descriptor.f90: Adjust expected output.

libgomp/
  * testsuite/libgomp.fortran/pr109622.f90: New test.
  * testsuite/libgomp.fortran/pr109622-2.f90: New test.
  * testsuite/libgomp.fortran/pr109622-3.f90: New test.

-
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

Re: libsanitizer: sync from master

[Florian Weimer via Fortran]

* Martin Liška:

> On 4/26/23 20:31, Florian Weimer wrote:
>> * Martin Liška:
>> 
>>> On 11/15/22 16:47, Martin Liška wrote:
 Hi.

 I've just pushed libsanitizer update that was tested on x86_64-linux and 
 ppc64le-linux systems.
 Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
 abidiff.
>>>
>>> Hello.
>>>
>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>> 
>> So … we have the issue that involves interceptors outside of libc.so.6,
>> namely crypt, crypt_r, and I posted an upstream patch for this:
>> 
>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>   
>> 
>> Can we just apply this downstream for now?  It blocks various folks from
>> using the sanitizers in their projects.
>
> Hello.
>
> Your upstream revision has been already accepted, so please apply it
> and I'm going to do one more merge from upstream in the following
> days. Does it work for you?

It's moving in a different direction now: 

But that's okay for me as well.

Thanks,
Florian

Re: [PATCH] OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]

[Thomas Schwinge]

Hi Julian!

On 2023-04-27T11:36:47-0700, Julian Brown  wrote:
> This patch fixes several cases where multiple attach or detach mapping
> nodes were being created for stand-alone attach or detach clauses
> in Fortran.  After the introduction of stricter checking later during
> compilation, these extra nodes could cause ICEs, as seen in the PR.
>
> The patch also fixes cases that "happened to work" previously where
> the user attaches/detaches a pointer to array using a descriptor, and
> (I think!) the "_data" field has offset zero, hence the same address as
> the descriptor as a whole.

Thanks for looking into this.

I haven't reviewed the patch itself, but noticed one thing:

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/pr109622-2.f90

> +!$acc enter data copyin(var)

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/pr109622-3.f90

> +!$acc enter data copyin(var, tgt)

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/pr109622.f90

> +!$acc enter data copyin(var, var2)

You'll want to move these into 'libgomp/testsuite/libgomp.oacc-fortran/'
to actually test them with '-fopenacc' instead of '-fopenmp'.  ;-)


Chalk up one for the idea that I once had, to have '-fopenacc',
'-fopenmp', '-fopenmp-simd' enable '-Wunknown-pragmas' by default.


Grüße
 Thomas
-
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

Hosting our gfortran MatterMost workspace

[Jerry D via Fortran]

Hello all and gcc overseers,

I received a notice that the MasterMost server providers decided to drop 
their free service. Unfortunate and understandable.


I plan to contact the Open Software Lab folks at Oregon State University 
to see if they can host for us.


If anyone else has any suggestions of possible places we can host an 
instance, please let me know.  The software for the platform is open 
source many folks self host, so we can do this.


I am not sure where gcc.gnu.org is hosted, but that might be a logical 
place.


Best regards,

Jerry

Re: Hosting our gfortran MatterMost workspace

[Andrew Pinski via Fortran]

On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran  wrote:
>
> Hello all and gcc overseers,
>
> I received a notice that the MasterMost server providers decided to drop
> their free service. Unfortunate and understandable.
>
> I plan to contact the Open Software Lab folks at Oregon State University
> to see if they can host for us.
>
> If anyone else has any suggestions of possible places we can host an
> instance, please let me know.  The software for the platform is open
> source many folks self host, so we can do this.
>
> I am not sure where gcc.gnu.org is hosted, but that might be a logical
> place.

Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 .
gcc.gnu.org is currently hosted as part of sourceware so ...

Thanks,
Andrew

>
> Best regards,
>
> Jerry

Re: Hosting our gfortran MatterMost workspace

[Mark Wielaard]

Hi Jerry, Hi Andrew,

On Fri, Apr 28, 2023 at 09:16:12AM -0700, Andrew Pinski via Gcc wrote:
> On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran  
> wrote:
> >
> > Hello all and gcc overseers,
> >
> > I received a notice that the MasterMost server providers decided to drop
> > their free service. Unfortunate and understandable.
> >
> > I plan to contact the Open Software Lab folks at Oregon State University
> > to see if they can host for us.
> >
> > If anyone else has any suggestions of possible places we can host an
> > instance, please let me know.  The software for the platform is open
> > source many folks self host, so we can do this.
> >
> > I am not sure where gcc.gnu.org is hosted, but that might be a logical
> > place.
> 
> Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 .
> gcc.gnu.org is currently hosted as part of sourceware so ...

OSUOSL already provides some machines for sourceware/gcc. If you could
put a bit more technical details into that bugzilla issue, with expected usage
(how many people, groups, moderation?) then we can coordinate and put
it on the overseers agenda.

Thanks,

Mark

Re: libsanitizer: sync from master

[Bernhard Reutner-Fischer via Fortran]

On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran 
 wrote:
>* Martin Liška:

>But that's okay for me as well.

Even better.

Re: [committed] Fortran: Fix (mostly) comment typos

[Bernhard Reutner-Fischer via Fortran]

On 28 April 2023 09:26:06 CEST, Tobias Burnus  wrote:
>Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da

 >  Only other changes are fixing the variable name a(b)breviated_modproc_decl

I think this is not good, I've mentioned it somewhere, i think, but I'll rename 
it.
thanks!