date:20230209

[Patch] Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'

2023-02-09 Thread Tobias Burnus


Found by chance recently; I thought about a couple of ways to handle it
but then settled to the proposed solution.

OK for mainline?

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
Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'

While 'omp assume' is enabled by -fopenmp-simd, 'omp assumes' is not;
however, due to the way parsing works in Fortran (esp. for fixed-form
source code), 'assumes' was parsed by 'assume' which then stumbled over
the tailing 's'.

gcc/fortran/

* parse.cc (decode_omp_directive): Really ignore 'assumes' with
	-fopenmp-simd.

gcc/testsuite/

* gfortran.dg/gomp/openmp-simd-8.f90: New test.

 gcc/fortran/parse.cc |  3 +++
 gcc/testsuite/gfortran.dg/gomp/openmp-simd-8.f90 | 25 
 2 files changed, 28 insertions(+)

diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 039e7e7da53..f5154d97ae8 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -885,6 +885,9 @@ decode_omp_directive (void)
   switch (c)
 {
 case 'a':
+  /* For -fopenmp-simd, ignore 'assumes'; note no clause starts with 's'. */
+  if (!flag_openmp && gfc_match ("assumes") == MATCH_YES)
+	break;
   matcho ("assumes", gfc_match_omp_assumes, ST_OMP_ASSUMES);
   matchs ("assume", gfc_match_omp_assume, ST_OMP_ASSUME);
   matcho ("atomic", gfc_match_omp_atomic, ST_OMP_ATOMIC);
diff --git a/gcc/testsuite/gfortran.dg/gomp/openmp-simd-8.f90 b/gcc/testsuite/gfortran.dg/gomp/openmp-simd-8.f90
new file mode 100644
index 000..cf92abf2f9e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/openmp-simd-8.f90
@@ -0,0 +1,25 @@
+! { dg-options "-fno-openmp -fopenmp-simd -fdump-tree-original" }
+
+! While 'omp assumes' is ignored with -fopenmp-simd,
+! 'omp assume' is processed - check that this works.
+
+module m
+  !$omp assumes no_openmp invalid_clause  ! Should get ignored
+contains
+  integer function foo()
+foo = 5
+  end function
+end
+
+program main
+  use m
+  implicit none
+  !$omp assumes no_openmp  ! likewise ignored
+  integer :: n
+  !$omp assume holds (foo() > 0) ! should be honoured
+n = foo()
+if (n == 0) stop
+  !$omp end assume
+end
+
+! { dg-final { scan-tree-dump "\\.ASSUME \\(foo \\(\\) > 0\\);" "original" } }

Re: [Patch] Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'

2023-02-09 Thread Jakub Jelinek via Fortran

On Thu, Feb 09, 2023 at 09:56:09AM +0100, Tobias Burnus wrote:
> Found by chance recently; I thought about a couple of ways to handle it
> but then settled to the proposed solution.
> 
> OK for mainline?
> 
> 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

> Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'
> 
> While 'omp assume' is enabled by -fopenmp-simd, 'omp assumes' is not;
> however, due to the way parsing works in Fortran (esp. for fixed-form
> source code), 'assumes' was parsed by 'assume' which then stumbled over
> the tailing 's'.
> 
> gcc/fortran/
> 
> * parse.cc (decode_omp_directive): Really ignore 'assumes' with
>   -fopenmp-simd.
> 
> gcc/testsuite/
> 
> * gfortran.dg/gomp/openmp-simd-8.f90: New test.

Ok.

Jakub

[og12] 'c-c++-common/gomp/alloc-pinned-1.c' -> 'libgomp.c-c++-common/alloc-pinned-1.c' (was: [PATCH 5/5] openmp: -foffload-memory=pinned)

2023-02-09 Thread Thomas Schwinge

Hi!

On 2022-03-08T11:30:59+, Hafiz Abid Qadeer  wrote:
> From: Andrew Stubbs 
>
> [...]

> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/alloc-pinned-1.c
> @@ -0,0 +1,28 @@
> +/* { dg-do run } */

Pushed to devel/omp/gcc-12 branch
commit 9c0ffa3776a135a69697253a0bd75ebf9b9d0150
"'c-c++-common/gomp/alloc-pinned-1.c' -> 
'libgomp.c-c++-common/alloc-pinned-1.c'",
see attached.

Note that this likewise applies to the current upstream submission:

"openmp: -foffload-memory=pinned".


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
>From 9c0ffa3776a135a69697253a0bd75ebf9b9d0150 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 30 Jan 2023 17:46:29 +0100
Subject: [PATCH] 'c-c++-common/gomp/alloc-pinned-1.c' ->
 'libgomp.c-c++-common/alloc-pinned-1.c'

Otherwise, for build-tree testing:

xgcc: fatal error: cannot read spec file 'libgomp.spec': No such file or directory

..., and thus corresponding FAILs, UNRESOLVEDs.

Fix-up for og12 commit 842df187487f5b16ae29bbe7e9acd79661a9df48
"openmp: -foffload-memory=pinned".

	gcc/testsuite/
	* c-c++-common/gomp/alloc-pinned-1.c: Cut.
	libgomp/
	* testsuite/libgomp.c-c++-common/alloc-pinned-1.c: Paste.
---
 gcc/testsuite/ChangeLog.omp   | 2 ++
 libgomp/ChangeLog.omp | 4 
 .../testsuite/libgomp.c-c++-common}/alloc-pinned-1.c  | 0
 3 files changed, 6 insertions(+)
 rename {gcc/testsuite/c-c++-common/gomp => libgomp/testsuite/libgomp.c-c++-common}/alloc-pinned-1.c (100%)

diff --git a/gcc/testsuite/ChangeLog.omp b/gcc/testsuite/ChangeLog.omp
index 42769c7dae5..9f9d5a10ac3 100644
--- a/gcc/testsuite/ChangeLog.omp
+++ b/gcc/testsuite/ChangeLog.omp
@@ -1,5 +1,7 @@
 2023-02-09  Thomas Schwinge  
 
+	* c-c++-common/gomp/alloc-pinned-1.c: Cut.
+
 	* gfortran.dg/gomp/allocate-4.f90: Fix 'omp_allocator_handle_kind'
 	example.
 
diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index d319d43ceb0..39165173884 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,3 +1,7 @@
+2023-02-09  Thomas Schwinge  
+
+	* testsuite/libgomp.c-c++-common/alloc-pinned-1.c: Paste.
+
 2023-02-08  Tobias Burnus  
 
 	Backported from master:
diff --git a/gcc/testsuite/c-c++-common/gomp/alloc-pinned-1.c b/libgomp/testsuite/libgomp.c-c++-common/alloc-pinned-1.c
similarity index 100%
rename from gcc/testsuite/c-c++-common/gomp/alloc-pinned-1.c
rename to libgomp/testsuite/libgomp.c-c++-common/alloc-pinned-1.c
-- 
2.25.1

[og12] 'gfortran.dg/gomp/allocate-4.f90' -> 'libgomp.fortran/allocate-5.f90' (was: [PATCH 1/5] [gfortran] Add parsing support for allocate directive (OpenMP 5.0))

2023-02-09 Thread Thomas Schwinge

Hi!

On 2022-01-13T14:53:16+, Hafiz Abid Qadeer  wrote:
> [...]

> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/allocate-4.f90

> +  use omp_lib

Pushed to devel/omp/gcc-12 branch
commit 7e1963a4e6ac97b6629c1e9e858ae28487f518cf
"'gfortran.dg/gomp/allocate-4.f90' -> 'libgomp.fortran/allocate-5.f90'",
see attached.

Note that this likewise applies to the current upstream submission:

"Add parsing support for allocate directive (OpenMP 5.0)".


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
>From 7e1963a4e6ac97b6629c1e9e858ae28487f518cf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 30 Jan 2023 18:04:16 +0100
Subject: [PATCH] 'gfortran.dg/gomp/allocate-4.f90' ->
 'libgomp.fortran/allocate-5.f90'

Otherwise, for build-tree testing:

[...]/gcc/testsuite/gfortran.dg/gomp/allocate-4.f90:10:7: Fatal Error: Cannot open module file 'omp_lib.mod' for reading at (1): No such file or directory

..., and thus corresponding FAILs.

(Not renamed to 'libgomp.fortran/allocate-4.f90', as that one already exists.)

Fix-up for og12 commit 491478d12b83e102f72858e8a871a25c951df293
"Add parsing support for allocate directive (OpenMP 5.0)".

	gcc/testsuite/
	* gfortran.dg/gomp/allocate-4.f90: Cut.
	libgomp/
	* testsuite/libgomp.fortran/allocate-5.f90: Paste.
---
 gcc/testsuite/ChangeLog.omp | 2 ++
 libgomp/ChangeLog.omp   | 2 ++
 .../testsuite/libgomp.fortran/allocate-5.f90| 0
 3 files changed, 4 insertions(+)
 rename gcc/testsuite/gfortran.dg/gomp/allocate-4.f90 => libgomp/testsuite/libgomp.fortran/allocate-5.f90 (100%)

diff --git a/gcc/testsuite/ChangeLog.omp b/gcc/testsuite/ChangeLog.omp
index 936e7af0945..f0c58e4d26a 100644
--- a/gcc/testsuite/ChangeLog.omp
+++ b/gcc/testsuite/ChangeLog.omp
@@ -1,5 +1,7 @@
 2023-02-09  Thomas Schwinge  
 
+	* gfortran.dg/gomp/allocate-4.f90: Cut.
+
 	* c-c++-common/gomp/uses_allocators-1.c: Cut.
 	* c-c++-common/gomp/uses_allocators-2.c: Likewise.
 	* c-c++-common/gomp/uses_allocators-3.c: Likewise.
diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index 0a3d53602da..603a17e4c8d 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,5 +1,7 @@
 2023-02-09  Thomas Schwinge  
 
+	* testsuite/libgomp.fortran/allocate-5.f90: Paste.
+
 	* testsuite/libgomp.c++/c++.exp (check_effective_target_c)
 	(check_effective_target_c++): New.
 	* testsuite/libgomp.c/c.exp (check_effective_target_c)
diff --git a/gcc/testsuite/gfortran.dg/gomp/allocate-4.f90 b/libgomp/testsuite/libgomp.fortran/allocate-5.f90
similarity index 100%
rename from gcc/testsuite/gfortran.dg/gomp/allocate-4.f90
rename to libgomp/testsuite/libgomp.fortran/allocate-5.f90
-- 
2.25.1

Re: [Patch][v2] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

2023-02-09 Thread Tobias Burnus


Updated patch. Changes: the canonic(al) and the if/else(if) cosmetic
formatting changes.

Testcases: Additionally, I checked for the value of a zero-loop trip in
libgomp.fortran/non-rectangular-loop-1.f90 and added lastprivate to all
of .../non-rectangular-loop-{3,4}.f90 (unless the loop-iteration
variable is a pointer).

At least those three files pass with and without -fopenmp, implying that
there the lastprivate check is correct. ('1a' and '5' also use
lastprivate, but those fail with a 'sorry' before a value test can be
done.) In '1' there are also several tests with 'parallel do', but only
SIMD has been tested more extensively (in general and for lastprivate).

I think the test coverage should be sufficient. Any further test idea?
Otherwise, I would commit it now.

Tobias

PS: Next planned by me: revising the 'omp loop' patch and a longer
pending 'map(alloc:' patch. And at some point supporting at least some
non-±1 increments with non-rect loop nests.

On 31.01.23 12:37, Jakub Jelinek wrote:

On Wed, Jan 25, 2023 at 03:47:18PM +0100, Tobias Burnus wrote:

updated patch included, i.e. avoiding 'count' for 'j' when a 'j.0' would
do (i.e. only local var without the different step calculation). I also
now reject if there is a non-unit step on the loop using an outer var.

Eventually still to be done: replace the 'sorry' by working code, i.e.
implement the suggestions to handle some/all non-unit iteration steps as
proposed in this thread.

On 20.01.23 18:39, Jakub Jelinek wrote:

I think instead of non-unity etc. it is better to talk about constant
step 1 or -1.

I concur.



The actual problem with non-simple loops for non-rectangular loops is
both in case it is an inner loop which uses some outer loop's iterator,
or if it is outer loop whose iterator is used, both of those cases
will not be handled properly.

I have now added a check for the other case as well.

Just to confirm, the following is fine, isn't it?

!$omp simd collapse(4)
do i = 1, 10, 2
   do outer_var = 1, 10  ! step = + 1
 do j = 1, 10, 2
   do inner_var = 1, outer_var  ! step = 1

i.e. both the inner_var and outer_var have 'step = 1',
even if other loops in the 'collapse' have step != 1.
I think it should be fine.

Yes, the loops which don't define outer_var for other loops nor
use outer_var from other loops can be in any form, we can compute
their number of iterations before the whole loop nest for them,
so for the non-rectangular iterations computations we can ignore
those except for multiplication by the pre-computed count.


OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

This patch ensures that loop bounds depending on outer loop vars use the
proper TREE_VEC format. It additionally gives a sorry if such an outer
var has a non-one/non-minus-one increment as currently a count variable
is used in this case (see PR).

Finally, it avoids 'count' and just uses a local loop variable if the
step increment is +/-1.

 PR fortran/107424

gcc/fortran/ChangeLog:

 * trans-openmp.cc (struct dovar_init_d): Add 'sym' and
 'non_unit_incr' members.
 (gfc_nonrect_loop_expr): New.
 (gfc_trans_omp_do): Call it; use normal loop bounds
 for unit stride - and only create local loop var.

libgomp/ChangeLog:

 * testsuite/libgomp.fortran/non-rectangular-loop-1.f90: New test.
 * testsuite/libgomp.fortran/non-rectangular-loop-1a.f90: New test.
 * testsuite/libgomp.fortran/non-rectangular-loop-2.f90: New test.
 * testsuite/libgomp.fortran/non-rectangular-loop-3.f90: New test.
 * testsuite/libgomp.fortran/non-rectangular-loop-4.f90: New test.
 * testsuite/libgomp.fortran/non-rectangular-loop-5.f90: New test.

gcc/testsuite/ChangeLog:

 * gfortran.dg/goacc/privatization-1-compute-loop.f90: Update dg-note.
 * gfortran.dg/goacc/privatization-1-routine_gang-loop.f90: Likewise.

+static bool
+gfc_nonrect_loop_expr (stmtblock_t *pblock, gfc_se *sep, int loop_n,
+   gfc_code *code, gfc_expr *expr, vec *inits,
+   int simple, gfc_expr *curr_loop_var)
+{
+  int i;
+  for (i = 0; i < loop_n; i++)
+{
+  gcc_assert (code->ext.iterator->var->expr_type == EXPR_VARIABLE);
+  if (gfc_find_sym_in_expr (code->ext.iterator->var->symtree->n.sym, expr))
+break;
+  code = code->block->next;
+}
+  if (i >= loop_n)
+return false;
+
+  /* Canonic format: TREE_VEC with [var, multiplier, offset].  */

I think we use everywhere Canonical rather than Canonic


+  gfc_symbol *var = code->ext.iterator->var->symtree->n.sym;
+
+  tree tree_var = NULL_TREE;
+  tree a1 = integer_one_node;
+  tree a2 = integer_zero_node;
+
+  if (!simple)
+{
+  /* FIXME: Handle non-unit iter steps, cf. PR fortran/107424.  */
+  sorry_at (gfc_get_location (&curr_loop_var->where),
+"non-rectangular loop nest with step other than constant 1 "
+"or -1 for %qs", curr_loop_var->symtree->n.sym->name);
+  return false;
+}
+
+  dovar_init *di;

Re: [Patch][v2] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

2023-02-09 Thread Jakub Jelinek via Fortran

On Thu, Feb 09, 2023 at 03:46:35PM +0100, Tobias Burnus wrote:
> I think the test coverage should be sufficient. Any further test idea?
> Otherwise, I would commit it now.

LGTM, thanks.

Jakub

[PATCH, committed] Fortran: catch invalid kind in character conversion [PR69636,PR103779]

2023-02-09 Thread Harald Anlauf via Fortran

Dear all,

the attached trivial and obvious patch replaces an internal error
on encountering an invalid kind in a character conversion by a
regular error recovery.

Pushed after regtesting on x86_64-pc-linux-gnu as
r13-5760-ga618b45ac41cf480f54c4fa4014aed6218931290

Thanks,
Harald

From a618b45ac41cf480f54c4fa4014aed6218931290 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 9 Feb 2023 21:16:14 +0100
Subject: [PATCH] Fortran: catch invalid kind in character conversion
 [PR69636,PR103779]

gcc/fortran/ChangeLog:

	PR fortran/69636
	PR fortran/103779
	* intrinsic.cc (gfc_convert_chartype): Recover on invalid character
	kind in conversion instead of generating an internal error.

gcc/testsuite/ChangeLog:

	PR fortran/69636
	PR fortran/103779
	* gfortran.dg/pr103779.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/intrinsic.cc   |  3 ++-
 gcc/testsuite/gfortran.dg/pr103779.f90 | 18 ++
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr103779.f90

diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 68f481473b4..17ee999c3b9 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -5419,7 +5419,8 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec *ts)
   gcc_assert (expr->ts.type == BT_CHARACTER && ts->type == BT_CHARACTER);

   sym = find_char_conv (&expr->ts, ts);
-  gcc_assert (sym);
+  if (sym == NULL)
+return false;

   /* Insert a pre-resolved function call to the right function.  */
   old_where = expr->where;
diff --git a/gcc/testsuite/gfortran.dg/pr103779.f90 b/gcc/testsuite/gfortran.dg/pr103779.f90
new file mode 100644
index 000..3d76c901e75
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103779.f90
@@ -0,0 +1,18 @@
+! { dg-do compile }
+! PR fortran/69636
+! PR fortran/103779
+! Contributed by G.Steinmetz
+
+character(1,) function f() ! { dg-error "Expected initialization expression" }
+  f = 'a'
+end
+
+character(1,kind=) function g() ! { dg-error "Expected initialization expression" }
+  g = 'a'
+end
+
+character(1,n) function h() ! { dg-error "has not been declared" }
+  h = 'a'
+end
+
+! { dg-prune-output "Bad kind expression" }
--
2.35.3

Support for NOINLINE attribute

2023-02-09 Thread Rimvydas Jasinskas via Fortran

Hello everyone,

would it be possible to extend gfortran attribute support to handle
NOINLINE too? Like: "!GCC$ ATTRIBUTES noinline :: ...".

Recent testing with gcc-13 trunk uncovered several issues with LTO
usage and for now it is unknown if it is host specific or something
else.  Given that there is little to no control from the fortran side
to influence how lto1 backend handles symbol manipulations, such
attribute (while not fixing root problems) would allow workaround
compilation issues at source level, since most of LTO usage problems
come from inlining and limits of resources available.

While there, it would be handy to have support for NORETURN and WEAK
attributes too.
In one of the projects just adding 2 NORETURN comment pragmas into
commonly used custom critical abort subroutine interfaces reduced the
number of -Wmaybe-uninitialized diagnostics from 2867 to 2654.   That
is a huge reduction of pure false positives and results in smaller
binaries produced.
Explaining the need for the WEAK attribute is somewhat more
complicated, when it is needed - it is needed (even if that means
compiling to assembly intermediates and sed "/SYM/s/.globl/.weak/"
which is quite fragile).

Attached is a proof of concept patch with some test cases adapted
mainly from already existing C testsuite variants and tested on
x86_64.  These additions are not intrusive and quite useful.
I'm willing to help test/code to get NOINLINE support added,

Best regards,
Rimvydas
From 7a197623c2efb30e4ecf78ce650b6727eef5e60b Mon Sep 17 00:00:00 2001
From: Rimvydas Jasinskas 
Date: Fri, 10 Feb 2023 04:34:12 +
Subject: Fortran: Add !GCC$ attributes NOINLINE,NORETURN,WEAK

gcc/fortran/ChangeLog:

	* decl.cc: Add EXT_ATTR_NOINLINE, EXT_ATTR_NORETURN, EXT_ATTR_WEAK.
	* gfortran.h (ext_attr_id_t): Ditto.
	* gfortran.texi (GCC$ ATTRIBUTES): Document them.
	* trans-decl.cc (build_function_decl): Apply them.

gcc/testsuite/ChangeLog:

	* gfortran.dg/noinline.f90: New test.
	* gfortran.dg/noreturn-1.f90: New test.
	* gfortran.dg/noreturn-2.f90: New test.
	* gfortran.dg/noreturn-3.f90: New test.
	* gfortran.dg/noreturn-4.f90: New test.
	* gfortran.dg/noreturn-5.f90: New test.
	* gfortran.dg/weak-1.f90: New test.

Signed-off-by: Rimvydas Jasinskas 
---
 gcc/fortran/decl.cc  |  3 ++
 gcc/fortran/gfortran.h   |  3 ++
 gcc/fortran/gfortran.texi|  9 +
 gcc/fortran/trans-decl.cc| 19 +-
 gcc/testsuite/gfortran.dg/noinline.f90   | 23 
 gcc/testsuite/gfortran.dg/noreturn-1.f90 | 62 
 gcc/testsuite/gfortran.dg/noreturn-2.f90 | 53 +++
 gcc/testsuite/gfortran.dg/noreturn-3.f90 | 14 
 gcc/testsuite/gfortran.dg/noreturn-4.f90 | 11 ++
 gcc/testsuite/gfortran.dg/noreturn-5.f90 |  9 +
 gcc/testsuite/gfortran.dg/weak-1.f90 |  6 
 11 files changed, 211 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/noinline.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noreturn-1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noreturn-2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noreturn-3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noreturn-4.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noreturn-5.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-1.f90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 27b728ff551..eec0314cf4c 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -11732,6 +11732,9 @@ const ext_attr_t ext_attr_list[] = {
   { "fastcall", EXT_ATTR_FASTCALL, "fastcall"  },
   { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL},
   { "deprecated",   EXT_ATTR_DEPRECATED,   NULL	   },
+  { "noinline", EXT_ATTR_NOINLINE, NULL	   },
+  { "noreturn", EXT_ATTR_NORETURN, NULL	   },
+  { "weak",	EXT_ATTR_WEAK,	   NULL	   },
   { NULL,   EXT_ATTR_LAST, NULL}
 };
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 9884a55882b..a893ee06f3d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -838,6 +838,9 @@ typedef enum
   EXT_ATTR_FASTCALL,
   EXT_ATTR_NO_ARG_CHECK,
   EXT_ATTR_DEPRECATED,
+  EXT_ATTR_NOINLINE,
+  EXT_ATTR_NORETURN,
+  EXT_ATTR_WEAK,
   EXT_ATTR_LAST, EXT_ATTR_NUM = EXT_ATTR_LAST
 }
 ext_attr_id_t;
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index c3813d06c20..4d7f4dbd7d8 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -3246,6 +3246,15 @@ requires an explicit interface.
 @item @code{DEPRECATED} -- print a warning when using a such-tagged
 deprecated procedure, variable or parameter; the warning can be suppressed
 with @option{-Wno-deprecated-declarations}.
+@item @code{NOINLINE} -- prevent inlining given function.
+@item @code{NORETURN} -- add hint that given function cannot return.  This
+makes slightly better code.  More importantly, it helps avoid spurious war

[Patch] Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'

Re: [Patch] Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'

[og12] 'c-c++-common/gomp/alloc-pinned-1.c' -> 'libgomp.c-c++-common/alloc-pinned-1.c' (was: [PATCH 5/5] openmp: -foffload-memory=pinned)

[og12] 'gfortran.dg/gomp/allocate-4.f90' -> 'libgomp.fortran/allocate-5.f90' (was: [PATCH 1/5] [gfortran] Add parsing support for allocate directive (OpenMP 5.0))

Re: [Patch][v2] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

Re: [Patch][v2] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

[PATCH, committed] Fortran: catch invalid kind in character conversion [PR69636,PR103779]

Support for NOINLINE attribute

8 matches

Site Navigation

Mail list logo

Footer information