Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
Hi Abid!
(Remember to CC for 'gcc/fortran/' etc. changes.)
On 2022-01-11T22:31:54+, Hafiz Abid Qadeer wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/allocate-2.f90
> @@ -0,0 +1,45 @@
> +! { dg-do compile }
> +
> +module omp_lib_kinds
> + use iso_c_binding, only: c_int, c_intptr_t
> + implicit none
> + private :: c_int, c_intptr_t
> + integer, parameter :: omp_allocator_handle_kind = c_intptr_t
> +
> +end module
> +
> +subroutine foo(x)
> + use omp_lib_kinds
> + implicit none
> + integer :: x
> +
> + !$omp task allocate (x) ! { dg-error "'x' specified in 'allocate' clause
> at .1. but not in an explicit privatization clause" }
> + x=1
> + !$omp end task
> +
> + !$omp parallel allocate (x) ! { dg-error "'x' specified in 'allocate'
> clause at .1. but not in an explicit privatization clause" }
> + x=2
> + !$omp end parallel
> +
> + !$omp parallel allocate (x) shared (x) ! { dg-error "'x' specified in
> 'allocate' clause at .1. but not in an explicit privatization clause" }
> + x=3
> + !$omp end parallel
> +
> + !$omp parallel private (x) allocate (x) allocate (x) ! { dg-warning "'x'
> appears more than once in 'allocate' clauses at .1." }
> + x=4
> + !$omp end parallel
> +
> + !$omp parallel private (x) allocate (x, x) ! { dg-warning "'x' appears
> more than once in 'allocate' clauses at .1." }
> + x=5
> + !$omp end parallel
> +
> + !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected integer
> expression of the 'omp_allocator_handle_kind' kind at .1." }
We do for x86_64 default '-m64', but for '-m32' and '-mx32' compilation,
we're not seeing this latter diagnostic:
PASS: gfortran.dg/gomp/allocate-1.f90 -O (test for excess errors)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 16)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 20)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 24)
FAIL: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 36)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 40)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for warnings, line 28)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for warnings, line 32)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for excess errors)
I suppose the reason is unintended congruence of data types? Would it
work to make 'x' a floating-point data type, for example -- or is this
meant to explicitly check certain integer data type characteristics?
Grüße
Thomas
> + x=6
> + !$omp end parallel
> +
> + !$omp parallel private (x) allocate (0.1 : x) ! { dg-error "Expected
> integer expression of the 'omp_allocator_handle_kind' kind at .1." }
> + x=7
> + !$omp end parallel
> +
> +end subroutine
-
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
[committed] libgfortran: Partly revert my r12-6498 change to fix Solaris build [PR104006]
Hi! In r12-6498 I've added $(version_dep) to BUILT_SOURCES, previously version_dep on Linux used to be a file in $(srcdir), but with my changes it is a generated file in the object directory (preprocessed version of the $(srcdir) file) and I thought generated files belong to BUILT_SOURCES so that they are cleaned up etc. For Linux that is fine, but it broke parallel builds on Solaris. BUILT_SOURCES is a special variable for automake where automake ensures that for make all, make check and make install all those $(BUILT_SOURCES) are generated before actually starting building in parallel the various object files. That way we can avoid hacks like: $(patsubst %.F90,%.lo,$(notdir $(filter %.F90,$(prereq_SRC: kinds.inc c99_protos.inc $(patsubst %.c,%.lo,$(notdir $(filter %.c,$(prereq_SRC: kinds.h $(patsubst %.f90,%.lo,selected_real_kind.f90): selected_real_kind.inc $(patsubst %.f90,%.lo,selected_int_kind.f90): selected_int_kind.inc $(patsubst %.F90,%.lo,ieee_exceptions.F90): fpu-target.inc $(patsubst %.F90,%.lo,ieee_arithmetic.F90): fpu-target.inc ieee_exceptions.lo $(patsubst %.c,%.lo,fpu.c): fpu-target.h which makes those dependencies explicit but hides it from automake, so that it doesn't throw away its rules for those object files. On Solaris, $(version_dep) contains gfortran.ver and gfortran.ver-sun. gfortran.ver is like on Linux, it can be in $(BUILT_SOURCES), but unfortunately gfortran.ver-sun depends on all the object files being compiled already, so if gfortran.ver-sun appears in $(BUILT_SOURCES), the BUILT_SOURCES function of ensuring the generated files are generated before building object files is gone, almost everything is built before all-am is entered and there are no explicit dependencies that e.g. *.F90 files depend on kinds.inc etc. So, this change reverts that mistake and instead adds $(version_dep) to what is removed during make clean (clean-local in particular). The reversion committed under the reversion of our own patches policy, the clean-local change considered obvious, committed to trunk. 2022-01-14 Jakub Jelinek PR libfortran/104006 * Makefile.am (BUILT_SOURCES): Don't include $(version_dep). (clean-local): Remove $(version_dep). * Makefile.in: Regenerated. --- libgfortran/Makefile.am.jj 2022-01-13 17:44:40.503962317 +0100 +++ libgfortran/Makefile.am 2022-01-13 23:37:52.876004924 +0100 @@ -1118,7 +1118,7 @@ ieee_arithmetic.mod: ieee_arithmetic.lo : BUILT_SOURCES=$(gfor_built_src) $(gfor_built_specific_src) \ - $(gfor_built_specific2_src) $(gfor_misc_specifics) $(version_dep) + $(gfor_built_specific2_src) $(gfor_misc_specifics) prereq_SRC = $(gfor_src) $(gfor_built_src) $(gfor_io_src) \ $(gfor_helper_src) $(gfor_ieee_src) $(gfor_io_headers) $(gfor_specific_src) @@ -1356,7 +1356,7 @@ $(gfor_misc_specifics): m4/misc_specific endif clean-local: - -rm -rf include + -rm -rf include $(version_dep) EXTRA_DIST = $(m4_files) --- libgfortran/Makefile.in.jj 2022-01-13 17:44:51.468807363 +0100 +++ libgfortran/Makefile.in 2022-01-13 23:37:58.729923341 +0100 @@ -1652,7 +1652,7 @@ intrinsics/random_init.f90 BUILT_SOURCES = $(gfor_built_src) $(gfor_built_specific_src) \ $(gfor_built_specific2_src) $(gfor_misc_specifics) \ - $(version_dep) $(am__append_7) + $(am__append_7) prereq_SRC = $(gfor_src) $(gfor_built_src) $(gfor_io_src) \ $(gfor_helper_src) $(gfor_ieee_src) $(gfor_io_headers) $(gfor_specific_src) @@ -7857,7 +7857,7 @@ include/ISO_Fortran_binding.h: $(srcdir) @MAINTAINER_MODE_TRUE@ $(M4) -Dfile=$@ -I$(srcdir)/m4 misc_specifics.m4 > $@ clean-local: - -rm -rf include + -rm -rf include $(version_dep) # target overrides -include $(tmake_file) Jakub
Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
Hi all,
On 14.01.22 10:10, Thomas Schwinge wrote:
+ integer :: x
...
+ !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected integer
expression of the 'omp_allocator_handle_kind' kind at .1." }
We do for x86_64 default '-m64', but for '-m32' and '-mx32' compilation,
we're not seeing this latter diagnostic:
FAIL: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 36)
I suppose the reason is unintended congruence of data types? Would it
work to make 'x' a floating-point data type, for example -- or is this
meant to explicitly check certain integer data type characteristics?
Alternatively, you could use 'integer(kind=1)' (which is a 1-byte/8-bits
type.) I assume we do not have any platform which still uses 8-bit
pointers and supports libgomp :-)
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
Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
On Fri, Jan 14, 2022 at 12:45:54PM +0100, Tobias Burnus wrote:
> On 14.01.22 10:10, Thomas Schwinge wrote:
> > > + integer :: x
> > > ...
> > > + !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected
> > > integer expression of the 'omp_allocator_handle_kind' kind at .1." }
> > We do for x86_64 default '-m64', but for '-m32' and '-mx32' compilation,
> > we're not seeing this latter diagnostic:
> > FAIL: gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 36)
> >
> > I suppose the reason is unintended congruence of data types? Would it
> > work to make 'x' a floating-point data type, for example -- or is this
> > meant to explicitly check certain integer data type characteristics?
>
> Alternatively, you could use 'integer(kind=1)' (which is a 1-byte/8-bits
> type.) I assume we do not have any platform which still uses 8-bit
> pointers and supports libgomp :-)
If we want to check intptr_t, we should guard the dg-error with
"" { target { lp64 || llp64 } }
or so.
Otherwise yes, we can add some other kind and hope it is not the
same as omp_allocator_handle_kind. Or we can do both,
keep the current one with the target lp64 || llp64 and
add another one with some integer(kind=1).
Jakub
Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
On 14.01.22 12:55, Jakub Jelinek via Fortran wrote:
If we want to check intptr_t, we should guard the dg-error with
"" { target { lp64 || llp64 } }
or so.
Well, if we want to use intptr_t, we could use be explicitly as with:
use iso_c_binding, only: c_intptr_t
! use omp_lib, only: omp_allocator_handle_kind
... ('implicit none' etc.)
integer, parameter :: omp_allocator_handle_kind = c_intptr_t
...
integer(kind=omp_allocator_handle_kind)
(@Abid: The 'use omp_lib' line is commented as in gcc/testsuite/*/gomp/,
the OpenMP module/header from libgomp is not available - and then a
stub parameter is created.)
Otherwise yes, we can add some other kind and hope it is not the
same as omp_allocator_handle_kind. Or we can do both,
keep the current one with the target lp64 || llp64 and
add another one with some integer(kind=1).
For just testing something invalid, I think it makes more sense to just
set it to kind=1.
For checking the valid value, using c_intptr_t seems to make more sense
than restricting it to (l)l64.
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
Re: [PATCH] git-backport: support renamed .cc files in commit message.
On 1/14/22 08:44, Bernhard Reutner-Fischer wrote:
On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška wrote:
+def replace_file_in_changelog(lines, filename):
+if not filename.endswith('.cc'):
+return
+
+# consider all componenets of a path: gcc/ipa-icf.cc
+while filename:
+for i, line in enumerate(lines):
+if filename in line:
+line = line.replace(filename, filename[:-1])
+lines[i] = line
+return
+parts = filename.split('/')
+if len(parts) == 1:
+return
+filename = '/'.join(parts[1:])
+
I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join
Hello.
Well, these are all paths from a git commit message. And we require unix-style
of paths for all ChangeLog entries. So it should be correct.
Martin
thanks,
[PATCH, committed] PR fortran/99256 - ICE in variable_check, at fortran/check.c:1012
Dear all,
this is a rather satisfying mini-patch which removes code to fix a bug.
The intrinsics MOVE_ALLOC, C_F_POINTER, and C_F_PROCPOINTER require
deferred checks of part of their actual argument types which may be of
"any" type. This however excludes alternate return specifiers which
therefore must be unconditionally rejected for all standard intrinsics.
OK'ed by Steve (see PR), and committed to mainline as obvious after
regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
From 70e24c9682ddbcade0301665bccd8e7f928d0082 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Fri, 14 Jan 2022 21:48:15 +0100
Subject: [PATCH] Fortran: always reject alternate return specifier as argument
of intrinsics
The intrinsics MOVE_ALLOC, C_F_POINTER, and C_F_PROCPOINTER require
deferred checks of part of their actual argument types which may be of
"any" type. This however excludes alternate return specifiers which
therefore must be unconditionally rejected for all standard intrinsics.
gcc/fortran/ChangeLog:
PR fortran/99256
* intrinsic.c: Do not check formal argument type when checking
arguments of intrinsics for alternate return specifiers.
gcc/testsuite/ChangeLog:
PR fortran/99256
* gfortran.dg/altreturn_11.f90: New test.
---
gcc/fortran/intrinsic.c| 2 +-
gcc/testsuite/gfortran.dg/altreturn_11.f90 | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/altreturn_11.f90
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index a7ecdb401ef..9746cd5ddb6 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -4420,7 +4420,7 @@ do_sort:
FOR_EACH_VEC_ELT (dummy_args, idx, f)
{
a = ordered_actual_args[idx];
- if (a && a->label != NULL && f->ts.type)
+ if (a && a->label != NULL)
{
gfc_error ("ALTERNATE RETURN not permitted at %L", where);
return false;
diff --git a/gcc/testsuite/gfortran.dg/altreturn_11.f90 b/gcc/testsuite/gfortran.dg/altreturn_11.f90
new file mode 100644
index 000..be42971d781
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/altreturn_11.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-prune-output "Obsolescent feature: Alternate-return argument" }
+! PR fortran/99256 - ICE in variable_check
+! Contributed by G.Steimetz
+
+program test
+ use iso_c_binding
+ type(c_ptr):: i
+ type(c_funptr) :: p
+ call move_alloc (*1, *2) ! { dg-error "ALTERNATE RETURN" }
+ call c_f_pointer (i, *1) ! { dg-error "ALTERNATE RETURN" }
+ call c_f_procpointer (p, *2) ! { dg-error "ALTERNATE RETURN" }
+1 continue
+2 stop
+end
--
2.31.1
