The fix for PR93924/5 has caused a regression for code such as given
in the present PR. This can be remedied by adjusting the check when
to invoke the implicit conversion of actual argument to an unlimited
polymorphic procedure argument.
Regtested on x86_64-pc-linux-gnu.
OK for mainline and
On Thu, May 20, 2021 at 04:11:10PM +0200, Marcel Vollweiler wrote:
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -1710,27 +1710,62 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
> && gfc_match ("map ( ") == MATCH_YES)
> {
>
Hi Jakub,
Am 20.05.2021 um 10:57 schrieb Jakub Jelinek:
On Thu, May 20, 2021 at 10:47:52AM +0200, Marcel Vollweiler wrote:
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1710,10 +1710,21 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
omp_mask mask,
&& gfc_match
On Thu, May 20, 2021 at 10:47:52AM +0200, Marcel Vollweiler wrote:
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -1710,10 +1710,21 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
> && gfc_match ("map ( ") == MATCH_YES)
> {
>
Hi,
This patch adds handling for the map-type-modifier 'close' in the map
clause in the Fortran parser (for C and C++ parsers the changes were
already committed).
'close' was introduced with OpenMP 5.0: "The close map-type-modifier is
a hint to the runtime to allocate memory close to the target
Hi Tobias,
> @All, Harald: Does the attached patch make sense?
first of all: sorry for the really badly designed testcase.
The best solution has already been discussed in this thread,
which is to replace
integer(16), parameter :: m1 = 9007199254740992_16!2**53
