[PATCH] Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

[Harald Anlauf]

Dear all,

the PR is about a redundant obsolescence warning for COMMON when
a symbols appears in the scope of a submodule.  As we did not warn
for use-associated symbols, it seemed natural to extend this to
symbols that are used in a submodule.  Or am I missing anything?

Regtests cleanly on x86_64-pc-linux-gnu.  OK for mainline?

The PR is marked as a regression (the warning appeared in gcc-9).
It looks simple enough for backporting, or does anybody see any
risk here?

Thanks,
Harald

From a962ab0417f5ff2efd51e710ae370d9f4a4b9f1a Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 23 Nov 2023 22:48:38 +0100
Subject: [PATCH] Fortran: avoid obsolescence warning for COMMON with submodule
 [PR111880]

gcc/fortran/ChangeLog:

	PR fortran/111880
	* resolve.cc (resolve_common_vars): Do not call gfc_add_in_common
	for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

	PR fortran/111880
	* gfortran.dg/pr111880.f90: New test.
---
 gcc/fortran/resolve.cc |  4 ++--
 gcc/testsuite/gfortran.dg/pr111880.f90 | 22 ++
 2 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr111880.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 81a14653a04..166b702cd9a 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -986,8 +986,8 @@ resolve_common_vars (gfc_common_head *common_block, bool named_common)

   /* gfc_add_in_common may have been called before, but the reported errors
 	 have been ignored to continue parsing.
-	 We do the checks again here.  */
-  if (!csym->attr.use_assoc)
+	 We do the checks again here, unless the symbol is USE associated.  */
+  if (!csym->attr.use_assoc && !csym->attr.used_in_submodule)
 	{
 	  gfc_add_in_common (>attr, csym->name, _block->where);
 	  gfc_notify_std (GFC_STD_F2018_OBS, "COMMON block at %L",
diff --git a/gcc/testsuite/gfortran.dg/pr111880.f90 b/gcc/testsuite/gfortran.dg/pr111880.f90
new file mode 100644
index 000..c0cd98a93d4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr111880.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options "-std=f2018" }
+! PR fortran/111880 - redundant warning of obsolescent COMMON with submodule
+
+module third_party_module
+  integer :: some_param
+  common /not_my_code/ some_param   ! { dg-warning "COMMON block" }
+end module third_party_module
+
+module foo
+  use third_party_module
+  interface
+module subroutine bar()
+end subroutine bar
+  end interface
+end module foo
+
+submodule (foo) foo_submod  ! We do not need a warning here!
+contains
+  module procedure bar
+  end procedure bar
+end submodule foo_submod
--
2.35.3

Re: [Patch] OpenMP: Accept argument to depobj's destroy clause

[Jakub Jelinek]

On Thu, Nov 23, 2023 at 04:59:16PM +0100, Tobias Burnus wrote:
> > There is also OEP_LEXICOGRAPHIC which could be used in addition to that.
> > The question is if we want to consider say
> > #pragma depobj (a[++i]) destroy (a[++i])
> > as same or different (similarly a[foo ()] in both cases).
> 
> I don't think that we want to permit those; I think there is (a) the
> question whether both expressions have to be evaluated or not and (b),
> if so, in which order and (c), if the run-time result is different,
> whether both have to be 'destory'ed or only one of them (which one?).

Well, we don't need to destroy two, because it would be UB if the two
aren't the same.  This is just about diagnostics if user messed stuff
up unintentionally.
The function call case can be the same very easily, just
int foo () { return 0; }
omp_depend_t a[2];
...
#pragma omp depobj (a[foo ()]) destroy (a[foo ()])
or
int i = 0;
#pragma omp depobj (a[((++i) * 2) & 1]) destroy (a[((++i) * 2) & 1])
The former may evaluate the function call multiple times, but user arranges
for it to do the same thing in each case, in the second case while there
are side-effects, they don't really matter for the value, just in whether
i after this pragma has value of 0, 1, 2 or something else (but if again
nothing cares about that value afterwards...).

The question is if same (I admit I haven't looked up the exact wording now)
means lexically same, or anything that has the same value, etc.
Because e.g.
omp_depend_t a;
...
omp_depend_t *p = 
#pragma omp depobj (a) destroy (p[0])
is the same value but not lexically same.

IMHO the argument to destroy clause shouldn't have ever been allowed, it is
only unnecessary extra pain.

Jakub

Re: [Patch] OpenMP: Accept argument to depobj's destroy clause

[Tobias Burnus]

Hi Jakub,

On 23.11.23 16:32, Jakub Jelinek wrote:

On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote:

@@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
+  else if (depobj != error_mark_node
+   && !operand_equal_p (destobj, depobj,
+OEP_MATCH_SIDE_EFFECTS))

There is also OEP_LEXICOGRAPHIC which could be used in addition to that.
The question is if we want to consider say
#pragma depobj (a[++i]) destroy (a[++i])
as same or different (similarly a[foo ()] in both cases).


I don't think that we want to permit those; I think there is (a) the
question whether both expressions have to be evaluated or not and (b),
if so, in which order and (c), if the run-time result is different,
whether both have to be 'destory'ed or only one of them (which one?).

Additionally, 'destroy-var must refer to the same depend object as the
depobj argument of the construct.' cannot be fulfilled if one is
evaluated before the other and both use the same 'i' in your case.

Thus, I do not really see an argument for permitting OEP_LEXICOGRAPHIC.

I think permitting 'volatile' does make sense, in a ways, as a
hyper-careful user might actually write such code.

[I wonder whether the OpenMP wording would permit 'omp depobj(obj)
destroy(f())' with 'auto f() { return obj; }' – but I am sure we don't
want to permit it in the compiler.]

Tobias

PS: In any case, I find it confusing to require that the same
variable/lvalue-expression has to be specified twice. The (only) pro is
that for 'omp interop destroy(...)' the argument is required and for
consistency of the 'destroy' clause, an argument now must be (always)
specified. But that leads to the odd 'omp depobj(obj) destroy(obj)',
which is really ugly. (In 5.2 the arg to destroy is optional but
omitting it is deprecated; hence, in OpenMP 6.0 (TR11, TR12) the
argument must be specified twice.)

-
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: [Patch] OpenMP: Accept argument to depobj's destroy clause

[Jakub Jelinek]

On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote:
> @@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
>   clause = error_mark_node;
>   }
>else if (!strcmp ("destroy", p))
> - kind = OMP_CLAUSE_DEPEND_LAST;
> + {
> +   matching_parens c_parens;
> +   kind = OMP_CLAUSE_DEPEND_LAST;
> +   if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)
> +   && c_parens.require_open (parser))
> + {
> +   tree destobj = c_parser_expr_no_commas (parser, NULL).value;
> +   if (!lvalue_p (destobj))
> + error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
> +   "% expression is not lvalue expression");
> +   else if (depobj != error_mark_node
> +&& !operand_equal_p (destobj, depobj,
> + OEP_MATCH_SIDE_EFFECTS))

There is also OEP_LEXICOGRAPHIC which could be used in addition to that.
The question is if we want to consider say
#pragma depobj (a[++i]) destroy (a[++i])
as same or different (similarly a[foo ()] in both cases).
A function could at least in theory return the same value, for other
side-effects there is some wiggle room in unspecified number of times how
many the side-effects of clauses are evaluated (and for destroy we really
don't intend to evaluate them at all for the clause, just for the directive
argument).

Jakub

Re: [Patch] OpenMP: Accept argument to depobj's destroy clause

[Tobias Burnus]

Hi Jakub,

On 23.11.23 15:32, Jakub Jelinek wrote:

On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote:

I stumbled over this trivial omission which blocks some testcases.
I am not sure whether I have solved the is-same-expr most elegantly,

Answer: I didn't - as expected.

+ if (DECL_UID (t) != DECL_UID (t2))
Nothing checks that t and t2 here are decls.  Use operand_equal_p instead?


Yes – I think I can simply use this instead all the other checks. That is
the function I was looking for but couldn't find before.

(I even have use the function before for PR108545.)

I decided that volatileness is fine and using twice a volatile function is
Okay according to the spec - hence, I permit this in addition. (One can
argue about it - but as specifying both is mandatory in OpenMP 6.0, it
seems to make sense.)

Revised version attached.

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
OpenMP: Accept argument to depobj's destroy clause

Since OpenMP 5.2, the destroy clause takes an depend argument as argument;
for the depobj directive, it the new argument is optional but, if present,
it must be identical to the directive's argument.

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_depobj): Accept optionally an argument
	to the destroy clause.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_depobj): Accept optionally an argument
	to the destroy clause.

gcc/fortran/ChangeLog:

	* openmp.cc (gfc_match_omp_depobj): Accept optionally an argument
	to the destroy clause.

libgomp/ChangeLog:

	* libgomp.texi (5.2 Impl. Status): An argument to the destroy clause
	is now supported.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/depobj-3.c: New test.
	* gfortran.dg/gomp/depobj-3.f90: New test.

 gcc/c/c-parser.cc   | 23 +-
 gcc/cp/parser.cc| 24 ++-
 gcc/fortran/openmp.cc   | 15 -
 gcc/testsuite/c-c++-common/gomp/depobj-3.c  | 47 +
 gcc/testsuite/gfortran.dg/gomp/depobj-3.f90 | 18 +++
 libgomp/libgomp.texi|  2 +-
 6 files changed, 125 insertions(+), 4 deletions(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 371dd29557b..006aee3e93f 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -21605,6 +21605,9 @@ c_parser_omp_critical (location_t loc, c_parser *parser, bool *if_p)
  destroy
  update (dependence-type)
 
+   OpenMP 5.2 additionally:
+ destroy ( depobj )
+
dependence-type:
  in
  out
@@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
 	clause = error_mark_node;
 	}
   else if (!strcmp ("destroy", p))
-	kind = OMP_CLAUSE_DEPEND_LAST;
+	{
+	  matching_parens c_parens;
+	  kind = OMP_CLAUSE_DEPEND_LAST;
+	  if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)
+	  && c_parens.require_open (parser))
+	{
+	  tree destobj = c_parser_expr_no_commas (parser, NULL).value;
+	  if (!lvalue_p (destobj))
+		error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
+			  "% expression is not lvalue expression");
+	  else if (depobj != error_mark_node
+		   && !operand_equal_p (destobj, depobj,
+	OEP_MATCH_SIDE_EFFECTS))
+		error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
+			  "the % expression %qE must be the same as "
+			  "the % argument %qE", destobj, depobj);
+	  c_parens.skip_until_found_close (parser);
+	}
+	}
   else if (!strcmp ("update", p))
 	{
 	  matching_parens c_parens;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index f6d088bc73f..1fca6bff795 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -43173,6 +43173,9 @@ cp_parser_omp_critical (cp_parser *parser, cp_token *pragma_tok, bool *if_p)
  destroy
  update (dependence-type)
 
+   OpenMP 5.2 additionally:
+ destroy ( depobj )
+
dependence-type:
  in
  out
@@ -43219,7 +43222,26 @@ cp_parser_omp_depobj (cp_parser *parser, cp_token *pragma_tok)
 	clause = error_mark_node;
 	}
   else if (!strcmp ("destroy", p))
-	kind = OMP_CLAUSE_DEPEND_LAST;
+	{
+	  kind = OMP_CLAUSE_DEPEND_LAST;
+	  matching_parens c_parens;
+	  if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_PAREN)
+	  && c_parens.require_open (parser))
+	{
+	  tree destobj = cp_parser_assignment_expression (parser);
+	  if (depobj != error_mark_node
+		  && destobj != error_mark_node
+		  && !operand_equal_p (destobj, depobj, OEP_MATCH_SIDE_EFFECTS))
+		error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
+			  "the % expression %qE must be the same as "
+			  "the % argument %qE", destobj, depobj);
+	  if (!c_parens.require_close (parser))
+		cp_parser_skip_to_closing_parenthesis (parser,
+		   /*recovering=*/true,
+		   /*or_comma=*/false,
+		   

Re: [Patch] OpenMP: Accept argument to depobj's destroy clause

[Jakub Jelinek]

On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote:
> I stumbled over this trivial omission which blocks some testcases.
> 
> I am not sure whether I have solved the is-same-expr most elegantly,
> but I did loosely follow the duplicated-entry check for 'map'. As that's
> a restriction to the user, we don't have to catch all and I hope the code
> catches the most important violations, doesn't ICE and does not reject
> valid code. At least for all real-world code it should™ work, but I
> guess for lvalue expressions involving function calls it probably doesn't.
> 
> Thoughts, comments?
> 
> Tobias
> 
> PS: GCC accepts an lvalue expression in C/C++ and only a identifier
> for a scalar variable in Fortran, i.e. neither array elements nor
> structure components.
> 
> Which variant is right depends whether one reads OpenMP 5.1 (lvalue expr,
> scalar variable) or 5.2 (variable without permitting array sections or
> structure components) - whereas TR12 has the same but talks about
> locator list items in one restriction. For the OpenMP mess, see spec
> issue #3739.
> -
> 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

> OpenMP: Accept argument to depobj's destroy clause
> 
> Since OpenMP 5.2, the destroy clause takes an depend argument as argument;
> for the depobj directive, it the new argument is optional but, if present,
> it must be identical to the directive's argument.
> 
> gcc/c/ChangeLog:
> 
>   * c-parser.cc (c_parser_omp_depobj): Accept optionally an argument
>   to the destroy clause.
> 
> gcc/cp/ChangeLog:
> 
>   * parser.cc (cp_parser_omp_depobj): Accept optionally an argument
>   to the destroy clause.
> 
> gcc/fortran/ChangeLog:
> 
>   * openmp.cc (gfc_match_omp_depobj): Accept optionally an argument
>   to the destroy clause.
> 
> libgomp/ChangeLog:
> 
>   * libgomp.texi (5.2 Impl. Status): An argument to the destroy clause
>   is now supported.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/gomp/depobj-3.c: New test.
>   * gfortran.dg/gomp/depobj-3.f90: New test.
> 
>  gcc/c/c-parser.cc   | 57 ++-
>  gcc/cp/parser.cc| 60 
> -
>  gcc/fortran/openmp.cc   | 15 +++-
>  gcc/testsuite/c-c++-common/gomp/depobj-3.c  | 40 +++
>  gcc/testsuite/gfortran.dg/gomp/depobj-3.f90 | 18 +
>  libgomp/libgomp.texi|  2 +-
>  6 files changed, 188 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
> index 371dd29557b..378647c1a67 100644
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -21605,6 +21605,9 @@ c_parser_omp_critical (location_t loc, c_parser 
> *parser, bool *if_p)
>   destroy
>   update (dependence-type)
>  
> +   OpenMP 5.2 additionally:
> + destroy ( depobj )
> +
> dependence-type:
>   in
>   out
> @@ -21663,7 +21666,59 @@ c_parser_omp_depobj (c_parser *parser)
>   clause = error_mark_node;
>   }
>else if (!strcmp ("destroy", p))
> - kind = OMP_CLAUSE_DEPEND_LAST;
> + {
> +   matching_parens c_parens;
> +   kind = OMP_CLAUSE_DEPEND_LAST;
> +   if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)
> +   && c_parens.require_open (parser))
> + {
> +   tree destobj = c_parser_expr_no_commas (parser, NULL).value;
> +   /* OpenMP requires that the two expressions are identical; catch
> +  the most common mismatches.  */
> +   if (!lvalue_p (destobj))
> + error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
> +   "% expression is not lvalue expression");
> +   else if (depobj != error_mark_node)
> + {
> +   tree t = depobj;
> +   tree t2 = build_unary_op (EXPR_LOC_OR_LOC (destobj, c_loc),
> + ADDR_EXPR, destobj, false);
> +   if (t2 != error_mark_node)
> + t2 = build_indirect_ref (EXPR_LOC_OR_LOC (t2, c_loc),
> +  t2, RO_UNARY_STAR);

Please watch indentation, seems there is a mix of 8 spaces vs. tabs:

> +   while (TREE_CODE (t) == COMPONENT_REF
> +  || TREE_CODE (t) == ARRAY_REF)
> +{
> +   t = TREE_OPERAND (t, 0);
> +   if (TREE_CODE (t) == MEM_REF || INDIRECT_REF_P (t))
> + {
> +   t = TREE_OPERAND (t, 0);
> +   STRIP_NOPS (t);
> +   if (TREE_CODE (t) == POINTER_PLUS_EXPR)
> + t = TREE_OPERAND (t, 0);
> +}
> + }
> +  

[Patch] OpenMP: Accept argument to depobj's destroy clause

[Tobias Burnus]

I stumbled over this trivial omission which blocks some testcases.

I am not sure whether I have solved the is-same-expr most elegantly,
but I did loosely follow the duplicated-entry check for 'map'. As that's
a restriction to the user, we don't have to catch all and I hope the code
catches the most important violations, doesn't ICE and does not reject
valid code. At least for all real-world code it should™ work, but I
guess for lvalue expressions involving function calls it probably doesn't.

Thoughts, comments?

Tobias

PS: GCC accepts an lvalue expression in C/C++ and only a identifier
for a scalar variable in Fortran, i.e. neither array elements nor
structure components.

Which variant is right depends whether one reads OpenMP 5.1 (lvalue expr,
scalar variable) or 5.2 (variable without permitting array sections or
structure components) - whereas TR12 has the same but talks about
locator list items in one restriction. For the OpenMP mess, see spec
issue #3739.
-
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
OpenMP: Accept argument to depobj's destroy clause

Since OpenMP 5.2, the destroy clause takes an depend argument as argument;
for the depobj directive, it the new argument is optional but, if present,
it must be identical to the directive's argument.

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_depobj): Accept optionally an argument
	to the destroy clause.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_depobj): Accept optionally an argument
	to the destroy clause.

gcc/fortran/ChangeLog:

	* openmp.cc (gfc_match_omp_depobj): Accept optionally an argument
	to the destroy clause.

libgomp/ChangeLog:

	* libgomp.texi (5.2 Impl. Status): An argument to the destroy clause
	is now supported.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/depobj-3.c: New test.
	* gfortran.dg/gomp/depobj-3.f90: New test.

 gcc/c/c-parser.cc   | 57 ++-
 gcc/cp/parser.cc| 60 -
 gcc/fortran/openmp.cc   | 15 +++-
 gcc/testsuite/c-c++-common/gomp/depobj-3.c  | 40 +++
 gcc/testsuite/gfortran.dg/gomp/depobj-3.f90 | 18 +
 libgomp/libgomp.texi|  2 +-
 6 files changed, 188 insertions(+), 4 deletions(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 371dd29557b..378647c1a67 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -21605,6 +21605,9 @@ c_parser_omp_critical (location_t loc, c_parser *parser, bool *if_p)
  destroy
  update (dependence-type)
 
+   OpenMP 5.2 additionally:
+ destroy ( depobj )
+
dependence-type:
  in
  out
@@ -21663,7 +21666,59 @@ c_parser_omp_depobj (c_parser *parser)
 	clause = error_mark_node;
 	}
   else if (!strcmp ("destroy", p))
-	kind = OMP_CLAUSE_DEPEND_LAST;
+	{
+	  matching_parens c_parens;
+	  kind = OMP_CLAUSE_DEPEND_LAST;
+	  if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)
+	  && c_parens.require_open (parser))
+	{
+	  tree destobj = c_parser_expr_no_commas (parser, NULL).value;
+	  /* OpenMP requires that the two expressions are identical; catch
+		 the most common mismatches.  */
+	  if (!lvalue_p (destobj))
+		error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
+			  "% expression is not lvalue expression");
+	  else if (depobj != error_mark_node)
+		{
+		  tree t = depobj;
+		  tree t2 = build_unary_op (EXPR_LOC_OR_LOC (destobj, c_loc),
+	ADDR_EXPR, destobj, false);
+		  if (t2 != error_mark_node)
+		t2 = build_indirect_ref (EXPR_LOC_OR_LOC (t2, c_loc),
+	 t2, RO_UNARY_STAR);
+		  while (TREE_CODE (t) == COMPONENT_REF
+			 || TREE_CODE (t) == ARRAY_REF)
+{
+		  t = TREE_OPERAND (t, 0);
+		  if (TREE_CODE (t) == MEM_REF || INDIRECT_REF_P (t))
+			{
+			  t = TREE_OPERAND (t, 0);
+			  STRIP_NOPS (t);
+			  if (TREE_CODE (t) == POINTER_PLUS_EXPR)
+			t = TREE_OPERAND (t, 0);
+}
+		}
+		  while (TREE_CODE (t2) == COMPONENT_REF
+			 || TREE_CODE (t2) == ARRAY_REF)
+{
+		  t2 = TREE_OPERAND (t2, 0);
+		  if (TREE_CODE (t2) == MEM_REF || INDIRECT_REF_P (t2))
+			{
+			  t2 = TREE_OPERAND (t2, 0);
+			  STRIP_NOPS (t2);
+			  if (TREE_CODE (t2) == POINTER_PLUS_EXPR)
+			t2 = TREE_OPERAND (t2, 0);
+}
+		}
+		  if (DECL_UID (t) != DECL_UID (t2))
+		error_at (EXPR_LOC_OR_LOC (destobj, c_loc),
+			  "the % expression %qE must be the same "
+			  "as the % argument %qE",
+			  destobj, depobj);
+		}
+	  c_parens.skip_until_found_close (parser);
+	}
+	}
   else if (!strcmp ("update", p))
 	{
 	  matching_parens c_parens;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 

Re: [PATCH, testsuite, fortran] fix invalid testcases (missing MOLD argument to NULL)

[Mikael Morin]

Hello,

Le 22/11/2023 à 22:02, Harald Anlauf a écrit :

Dear all,

testcases assumed_rank_8.f90 and assumed_rank_10.f90 are invalid:
NULL() is passed without MOLD to an assumed-rank dummy argument.

This is detected by NAG, but not yet by gfortran (see pr104819).
gfortran even ignores the MOLD argument; the dump-tree is identical
if MOLD is there or not.

Now these testcases are { dg-do run }.  Therefore I would like to
fix these testcases, independent of the work on fixing pr104819.

Comments?


Makes sense; OK from my point of view.

Mikael

RE: [PATCH v4] libgfortran: Replace mutex with rwlock

[Zhu, Lipeng]

> [CCing Ian as libgcc maintainer]
> 
> On Wed, 1 Nov 2023 10:14:37 +
> "Zhu, Lipeng"  wrote:
> 
> > > >
> > > > Hi Lipeng,
> > > >
> > > > >>> Sure, as your comments, in the patch V6, I added 3 test cases
> > > > >>> with OpenMP to test different cases in concurrency respectively:
> > > > >>> 1. find and create unit very frequently to stress read lock and 
> > > > >>> write
> lock.
> > > > >>> 2. only access the unit which exist in cache to stress read lock.
> > > > >>> 3. access the same unit in concurrency.
> > > > >>> For the third test case, it also help to find a bug:  When
> > > > >>> unit can't be found in cache nor unit list in read phase, then
> > > > >>> threads will try to acquire write lock to insert the same
> > > > >>> unit, this will cause duplicate key
> > > > >> error.
> > > > >>> To fix this bug, I get the unit from unit list once again
> > > > >>> before insert in write
> > > > >> lock.
> > > > >>> More details you can refer the patch v6.
> > > > >>>
> > > > >>
> > > > >> Could you help to review this update? I really appreciate your
> assistance.
> > > > >>
> > > >
> > > > > Could you help to review this update?  Any concern will be
> appreciated.
> > > >
> > > > Fortran parts are OK (I think I wrote that already), we need
> > > > somebody for the non-Fortran parts.
> > > >
> > > Hi Thomas,
> > >
> > > Thanks for your response. Very appreciate for your patience and help.
> > >
> > > > Jakub, could you maybe take a look?
> > > >
> > > > Best regards
> > > >
> > > > Thomas
> > >
> > > Hi Jakub,
> > >
> > > Can you help to take a look at the change for libgcc part that added
> > > several rwlock macros in libgcc/gthr-posix.h?
> > >
> >
> > Hi Jakub,
> >
> > Could you help to review this, any comment will be greatly appreciated.
> 
> Latest version is at
> https://inbox.sourceware.org/gcc-patches/20230818031818.2161842-1-
> lipeng@intel.com/
> 
Thanks Bernhard.

Hi Ian, 
Could you help to review the changes for libgcc part?  
Very looking forward to your help.

> >
> > > Best Regards,
> > > Lipeng Zhu
> >

Re: [PATCH, v4] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

[Mikael Morin]

Le 22/11/2023 à 21:36, Harald Anlauf a écrit :

Hi Mikael!

On 11/22/23 10:36, Mikael Morin wrote:

(...)


diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 2ac51e95e4d..be715b50469 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -980,7 +980,11 @@ char const*
 notify_std_msg(int std)
 {

-  if (std & GFC_STD_F2018_DEL)
+  if (std & GFC_STD_F2023_DEL)
+    return _("Fortran 2023 deleted feature:");


As there are officially no deleted feature in f2023, maybe use a
slightly different wording?  Say "Not allowed in fortran 2023" or
"forbidden in Fortran 2023" or similar?


+  else if (std & GFC_STD_F2023)
+    return _("Fortran 2023:");
+  else if (std & GFC_STD_F2018_DEL)
 return _("Fortran 2018 deleted feature:");
   else if (std & GFC_STD_F2018_OBS)
 return _("Fortran 2018 obsolescent feature:");


I skimmed over existing error messages, and since "forbidden" did
not show up and since "Not allowed" exists but not at the beginning
of a message, I found that

"Prohibited in Fortran 2023"

appeared to be a good alternative.

Not being a native speaker, I hope that someone speaks up if this
is not appropriate.  And since I do not explicitly verify that part
in the testcase, it can be changed.


diff --git a/gcc/fortran/libgfortran.h b/gcc/fortran/libgfortran.h
index bdddb317ab0..af7a170c2b1 100644
--- a/gcc/fortran/libgfortran.h
+++ b/gcc/fortran/libgfortran.h
@@ -19,9 +19,10 @@ along with GCC; see the file COPYING3.  If not see


 /* Flags to specify which standard/extension contains a feature.
-   Note that no features were obsoleted nor deleted in F2003 nor in
F2023.
+   Note that no features were obsoleted nor deleted in F2003.


I think we can add a comment that F2023 has no deleted feature, but some
more stringent restrictions in f2023 forbid some previously valid code.


    Please remember to keep those definitions in sync with
    gfortran.texi.  */
+#define GFC_STD_F2023_DEL    (1<<13)    /* Deleted in F2023.  */
 #define GFC_STD_F2023    (1<<12)    /* New in F2023.  */
 #define GFC_STD_F2018_DEL    (1<<11)    /* Deleted in F2018.  */
 #define GFC_STD_F2018_OBS    (1<<10)    /* Obsolescent in F2018.  */
@@ -41,12 +42,13 @@ along with GCC; see the file COPYING3.  If not see
  * are allowed with a certain -std option.  */
 #define GFC_STD_OPT_F95    (GFC_STD_F77 | GFC_STD_F95 |
GFC_STD_F95_OBS  \
 | GFC_STD_F2008_OBS | GFC_STD_F2018_OBS \
-    | GFC_STD_F2018_DEL)
+    | GFC_STD_F2018_DEL | GFC_STD_F2023_DEL)
 #define GFC_STD_OPT_F03    (GFC_STD_OPT_F95 | GFC_STD_F2003)
 #define GFC_STD_OPT_F08    (GFC_STD_OPT_F03 | GFC_STD_F2008)
 #define GFC_STD_OPT_F18    ((GFC_STD_OPT_F08 | GFC_STD_F2018) \
 & (~GFC_STD_F2018_DEL))

F03, F08 and F18 should have GFC_STD_F2023_DEL (and also F03 and F08
should have GFC_STD_F2018_DEL).


Well, these macros do an incremental bitwise-or, so the bit representing
GFC_STD_F2023_DEL is included everywhere.  I also ran the testcases with
different -std= options to check.


Ah, yes.  I confused the GFC_STD_OPT* values with the GFC_STD_* ones.


OK with this fixed (and the previous comments as you wish), if Steve has
no more comments.

Thanks for the patch.




If there are no further comments, I will commit once I am able to
fully build again with --disable-bootstrap and -march=native ...

Thanks,
Harald


Thanks again.

Request for a quote_GCC - GNU Fortran

[Phạm Thị Hương Xuân]

Hi Sales team,

We are A International Trading Service Company, reseller of software in 
Vietnam.

You could access our information as a link: https://licensesoft.vn/
Our customer would like to buy the license of GCC - GNU Fortran.

Could you quote us the reseller price?

Kindly advise us the procedure to get your discount policy if you have.

If you need any additional information, please kindly let me know.



Thank you!

-

Xuan Pham (Mrs)

A International Service and Trading Co., Ltd

Address: 7th floor, Zen Tower, 12 Khuat Duy Tien Street

Thanh Xuan Trung Ward, Thanh Xuan District, Hanoi, Vietnam

Zip code: 1

M: +84 988 282169   Skype: huongxuan2202
Website: https://licensesoft.vn