Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args
Hi Tobias,
Replying to your last two messages here and attaching revised patches.
On 16/12/2024 22:34, Tobias Burnus wrote:
I have not looked in depth at the patch, but managed to
write C-ism code, which caused a segfault (due to a missing "call"),
after gfortran issued a reasonable error. Can you fix it
and, just to make sure, add it as another testcase?
foo.f90:18:7:
18 | g(a,b,c)
| 1
Error: ‘g’ at (1) is not a variable
foo.f90:20:3:
20 | end
| 1
Error: Unexpected END statement at (1)
Segmentation fault
* * *
The problem seems to be that during parsing,
the location data is NULL, which the error diagnostic
does not like:
(gdb) p gfc_current_locus
$33 = {nextc = 0x0, u = {lb = 0x0, location = 0}}
(gdb) p gfc_at_eof()
$36 = true
and st == ST_NONE.
I think the simplest is to check for the last one,
and then return early. This will then print:
foo.f90:18:7:
18 | g(a,b,c)
| 1
Error: ‘g’ at (1) is not a variable
foo.f90:20:3:
20 | end
| 1
Error: Unexpected END statement at (1)
f951: Error: Unexpected end of file in ‘foo.f90’
When the if st is ST_NONE then return check is added:
+static gfc_statement
+parse_omp_dispatch (void)
+{
...
+ st = next_statement ();
+ if (st == ST_NONE)
+return st;
+ if (st == ST_CALL || st == ST_ASSIGNMENT)
+accept_statement (st);
+ else
Fixed as suggested. Added testcase.
* * *
Handling of `adjust_args` across translation units is missing due to
PR115271.
Namely, https://gcc.gnu.org/PR115271 is about not storing 'declare variant'
inside
module files; when repeating the decl in an interface, it obviously works as
* * *
I think the patch is now okay, but I want to re-read it tomorrow - thus, please
hold off for a couple of ours.
Possibly, others have comments as well :-)
* * *
TODO: We need to handle 'type(C), dimension(:)' - but I wonder
whether that shouldn't be handled as part of 'use_device_addr'
and we need to check whether the spec has to be updated.
I filed the OpenMP lang-spec Issue #4443.
... and we eventually have to handle 'need_device_addr'/'has_device_addr', but
those are follow-up topics.
Keeping an eye on the open issue.
On 17/12/2024 14:11, Tobias Burnus wrote:
Additional comments: Can you hoist the condition out of the loop in:
+ for (gfc_omp_namelist *n = *head; n != NULL; n = n->next) + if
(need_device_ptr_p) + n->u.need_device_ptr = true;
Sure.
* * *
I was about to complain that it didn't handle VALUE + OPTIONAL
correctly, but that's a generic gfortran bug (or two):
->https://gcc.gnu.org/PR118080
* * *
There is a bug - 'nowait' is not propagated. Trying:
!$omp dispatch depend(inout:x) nowait
call g(a)
!$omp end dispatch
gives (-fdump-tree-gimple): #pragma omp taskwait depend(inout:&x) nowait
but doing the equivalent !$omp dispatch depend(inout:x) call g(a) !$omp
end dispatch nowait gives: #pragma omp taskwait depend(inout:&x) i.e.
the 'nowait' got lost. * * *
Fixed and added testcase.
Similar the original C code, which to my knowledge is now
fixed + tested for, there is an issue related to handling nested
function calls.
I think the attached testcase is fine, but it segfaults unless
the default device is the initial device. The problem is that
the pointer conversion also happens for the inner function but
it should only do so for the outer one.
See attached testcase. – I think it can be seen by looking at the
dump (and adding an -fdump-tree-gimple + scan test probably won't
harm, as not everyone has a GPU and we might implement map as
selfmap on APUs).
This is actually not specific to the Fortran FE. So I had to modify the
middle end and the C++ parser as well. See attached pactches.
Otherwise LGTM.
Tobias
Thanks,
--
PAFrom e470fc10269d9bb0a4b263c18f03e289973807c4 Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras
Date: Fri, 24 May 2024 19:13:50 +0200
Subject: [PATCH 1/4] OpenMP: Fortran front-end support for dispatch +
adjust_args
This patch adds support for the `dispatch` construct and the `adjust_args`
clause to the Fortran front-end.
Handling of `adjust_args` across translation units is missing due to PR115271.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_clauses): Handle novariants and nocontext
clauses.
(show_omp_node): Handle EXEC_OMP_DISPATCH.
(show_code_node): Likewise.
* frontend-passes.cc (gfc_code_walker): Handle novariants and nocontext.
* gfortran.h (enum gfc_statement): Add ST_OMP_DISPATCH.
(symbol_attribute): Add omp_declare_variant_need_device_ptr.
(gfc_omp_clauses): Add novariants and nocontext.
(gfc_omp_declare_variant): Add need_device_ptr_arg_list.
(enum gfc_exec_op): Add EXEC_OMP_DISPATCH.
* match.h (gfc_match_omp_dispatch): Declare.
* openmp.cc (gfc_free_omp_clauses): Free novariants and nocontext
clauses.
(gfc_free_omp_declare_variant_list): Free need_device_ptr_arg_list
namelist.
(enum omp_mask2): Add OMP_CLAUSE_NOVARIANTS and OMP_CLAUSE_NOCONTEX
Re: [r15-6415 Regression] FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 on Linu
Hi Andre,
It looks good to me.
Thanks
Paul
On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
> Hi all,
>
> I did an ooppsie with the patch for 107635. Attached is a patch that fixes
> this. Essentially the regexp was to complicated for what was needed. So
> now we
> just count the number of occurrences of caf_get_by_ct, which has to be
> four.
>
> Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
>
> Regards,
> Andre
>
> On Mon, 23 Dec 2024 04:52:50 +0800
> "haochen.jiang" wrote:
>
> > On Linux/x86_64,
> >
> > 586477d67bf2e320e8ec41f82b194259c1dcc43a is the first bad commit
> > commit 586477d67bf2e320e8ec41f82b194259c1dcc43a
> > Author: Andre Vehreschild
> > Date: Fri Dec 6 08:57:34 2024 +0100
> >
> > Fortran: Replace getting of coarray data with accessor-based version.
> > [PR107635]
> >
> > caused
> >
> > FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O0 scan-tree-dump-times
> > original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned
> > long\\) atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90
> -O1
> > scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token..,
> 0B,
> > 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 FAIL:
> > gfortran.dg/coarray_lib_comm_1.f90 -O2 scan-tree-dump-times original
> > "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\)
> > atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O3
> > -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions
> > scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token..,
> 0B,
> > 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 FAIL:
> > gfortran.dg/coarray_lib_comm_1.f90 -O3 -g scan-tree-dump-times
> original
> > "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\)
> > atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os
> > scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token..,
> 0B,
> > 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4
> >
> > with GCC configured with
> >
> > ../../gcc/configure
> > --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6415/usr
> > --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
> > --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet
> --without-isl
> > --enable-libmpx x86_64-linux --disable-bootstrap
> >
> > To reproduce:
> >
> > $ cd {build_dir}/gcc && make check
> > RUNTESTFLAGS="dg.exp=gfortran.dg/coarray_lib_comm_1.f90
> > --target_board='unix{-m32}'" $ cd {build_dir}/gcc && make check
> > RUNTESTFLAGS="dg.exp=gfortran.dg/coarray_lib_comm_1.f90
> > --target_board='unix{-m32\ -march=cascadelake}'"
> >
> > (Please do not reply to this email, for question about this report,
> contact
> > me at haochen dot jiang at intel.com.) (If you met problems with
> cascadelake
> > related, disabling AVX512F in command line might save that.) (However,
> please
> > make sure that there is no potential problems with AVX512.)
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>
Re: [r15-6415 Regression] FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 on Li
Hi all,
I did an ooppsie with the patch for 107635. Attached is a patch that fixes
this. Essentially the regexp was to complicated for what was needed. So now we
just count the number of occurrences of caf_get_by_ct, which has to be four.
Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
Regards,
Andre
On Mon, 23 Dec 2024 04:52:50 +0800
"haochen.jiang" wrote:
> On Linux/x86_64,
>
> 586477d67bf2e320e8ec41f82b194259c1dcc43a is the first bad commit
> commit 586477d67bf2e320e8ec41f82b194259c1dcc43a
> Author: Andre Vehreschild
> Date: Fri Dec 6 08:57:34 2024 +0100
>
> Fortran: Replace getting of coarray data with accessor-based version.
> [PR107635]
>
> caused
>
> FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O0 scan-tree-dump-times
> original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned
> long\\) atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O1
> scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B,
> 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 FAIL:
> gfortran.dg/coarray_lib_comm_1.f90 -O2 scan-tree-dump-times original
> "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\)
> atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O3
> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
> scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B,
> 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 FAIL:
> gfortran.dg/coarray_lib_comm_1.f90 -O3 -g scan-tree-dump-times original
> "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\)
> atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os
> scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B,
> 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4
>
> with GCC configured with
>
> ../../gcc/configure
> --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6415/usr
> --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
> --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
> --enable-libmpx x86_64-linux --disable-bootstrap
>
> To reproduce:
>
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="dg.exp=gfortran.dg/coarray_lib_comm_1.f90
> --target_board='unix{-m32}'" $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="dg.exp=gfortran.dg/coarray_lib_comm_1.f90
> --target_board='unix{-m32\ -march=cascadelake}'"
>
> (Please do not reply to this email, for question about this report, contact
> me at haochen dot jiang at intel.com.) (If you met problems with cascadelake
> related, disabling AVX512F in command line might save that.) (However, please
> make sure that there is no potential problems with AVX512.)
--
Andre Vehreschild * Email: vehre ad gmx dot de
From b64c97530fc46b9c750a035925e14c77b2574d65 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Mon, 23 Dec 2024 15:01:30 +0100
Subject: [PATCH] Fortran: Fixup broken build on 32bit after r15-6415
[PR107635]
gcc/testsuite/ChangeLog:
PR fortran/107635
* gfortran.dg/coarray_lib_comm_1.f90: Use less complicated
pattern, because all we need is the right count.
---
gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
index 68aa47ecd32..609f3c10cef 100644
--- a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
@@ -38,6 +38,6 @@ B(1:5) = B(3:7)
if (any (A-B /= 0)) STOP 4
end
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get_by_ct \\\(caf_token.., 0B, 0B, 1, \\\(unsigned long\\\) atmp.\[0-9\]+.span" 4 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get_by_ct" 4 "original" } }
! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.., \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, caf_token.., \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, 4, 4, 1, 0B\\\);" 1 "original" } }
--
2.47.1
Re: [Patch, fortran] PR116254/118059 -[15 Regression] Bugs triggered by class_transformational_1/2.f90
Hi Paul, please run the style-checker on the patch before pushing. Furthermore, shouldn't that +changed, the dtype updating and the correct rank used. */ rather be +changed, the dtype updated and the correct rank used. */ ^^ Besides that the patch looks good to me. Ok for mainline. The best seasons greeting to you and everyone else, too. Thanks for the patch, Andre On Mon, 23 Dec 2024 07:50:18 + Paul Richard Thomas wrote: > Hi All, > > These bugs were tricky to find because neither were detected by regression > testing on my platform. > > PR116254: This bug was sporadic even where the regression was detected. > Richard Sandiford found "Conditional jump or move depends on uninitialised > value" errors in the library, triggered by the test for for spread in > class_transformational_2.f90. Mea culpa, I had failed to notice this. > It turned out that, alone of the rank changing intrinsic functions, spread > was going through the wrong code path. This is fixed by the > explicit condition in the patch. > > Richard also noted that spread results are being copied from uninitialised > memory. This was not quite correct because the library function was doing > the job on detection of the NULL descriptor data field. Nevertheless, I > have refactored slightly to ensure that the temporary descriptor has its > dtype field set correctly before the class data is pointed at it. Valgrind > shows both class_transformational tests to now be as clean as a whistle. > > PR118059: The reporter found, with an ubsan instrumented gcc, that > class_transformational_1.f90 was generating an invalid value for type > 'expr_t' in gcc/fortran/trans-expr.cc. The offending statement is; B = > reshape (chr, [5, 1, 2]), where 'B' is unlimited polymorphic. This requires > a trivial fix since the assignment of a character array valued function to > an unlimited polymorphic variable unconditionally requires a temporary. > > Regression tests without errors - OK for mainline? > > Seasons greetings to one and all. > > Paul -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [r15-6415 Regression] FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 on Linu
Hi Paul,
thanks for the quick review. Pushed as gcc-15-6425-gdae506f73bd
Thanks again,
Andre
On Mon, 23 Dec 2024 15:13:50 +
Paul Richard Thomas wrote:
> Hi Andre,
>
> It looks good to me.
>
> Thanks
>
> Paul
>
>
> On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote:
>
> > Hi all,
> >
> > I did an ooppsie with the patch for 107635. Attached is a patch that fixes
> > this. Essentially the regexp was to complicated for what was needed. So
> > now we
> > just count the number of occurrences of caf_get_by_ct, which has to be
> > four.
> >
> > Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
> >
> > Regards,
> > Andre
> >
> > On Mon, 23 Dec 2024 04:52:50 +0800
> > "haochen.jiang" wrote:
> >
> > > On Linux/x86_64,
> > >
> > > 586477d67bf2e320e8ec41f82b194259c1dcc43a is the first bad commit
> > > commit 586477d67bf2e320e8ec41f82b194259c1dcc43a
> > > Author: Andre Vehreschild
> > > Date: Fri Dec 6 08:57:34 2024 +0100
> > >
> > > Fortran: Replace getting of coarray data with accessor-based version.
> > > [PR107635]
> > >
> > > caused
> > >
> > > FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O0 scan-tree-dump-times
> > > original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned
> > > long\\) atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90
> > -O1
> > > scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token..,
> > 0B,
> > > 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 FAIL:
> > > gfortran.dg/coarray_lib_comm_1.f90 -O2 scan-tree-dump-times original
> > > "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\)
> > > atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -O3
> > > -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> > -finline-functions
> > > scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token..,
> > 0B,
> > > 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 FAIL:
> > > gfortran.dg/coarray_lib_comm_1.f90 -O3 -g scan-tree-dump-times
> > original
> > > "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\)
> > > atmp.[0-9]+.span" 4 FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os
> > > scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token..,
> > 0B,
> > > 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4
> > >
> > > with GCC configured with
> > >
> > > ../../gcc/configure
> > > --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-6415/usr
> > > --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
> > > --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet
> > --without-isl
> > > --enable-libmpx x86_64-linux --disable-bootstrap
> > >
> > > To reproduce:
> > >
> > > $ cd {build_dir}/gcc && make check
> > > RUNTESTFLAGS="dg.exp=gfortran.dg/coarray_lib_comm_1.f90
> > > --target_board='unix{-m32}'" $ cd {build_dir}/gcc && make check
> > > RUNTESTFLAGS="dg.exp=gfortran.dg/coarray_lib_comm_1.f90
> > > --target_board='unix{-m32\ -march=cascadelake}'"
> > >
> > > (Please do not reply to this email, for question about this report,
> > contact
> > > me at haochen dot jiang at intel.com.) (If you met problems with
> > cascadelake
> > > related, disabling AVX512F in command line might save that.) (However,
> > please
> > > make sure that there is no potential problems with AVX512.)
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
> >
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer dummy [PR118179]
On 12/23/24 9:19 AM, Harald Anlauf wrote: Dear all, while preparing the testcase null_actual_7.f90 for commit r15-6408, I overlooked a corner case, leading to a regression (PR118179). The obvious solution is to extend the suppression of copying back the pointer also for NULL actual arguments to pointer dummies with no specified intent. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald OK, and thanks for the fix. Jerry
[PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer dummy [PR118179]
Dear all, while preparing the testcase null_actual_7.f90 for commit r15-6408, I overlooked a corner case, leading to a regression (PR118179). The obvious solution is to extend the suppression of copying back the pointer also for NULL actual arguments to pointer dummies with no specified intent. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From 49754a5acc6ca4c0927d54c3c00cc3f93f1ce4dd Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Mon, 23 Dec 2024 17:56:46 +0100 Subject: [PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer dummy [PR118179] Commit r15-6408 overlooked the case of passing NULL without MOLD argument to a derived type pointer dummy argument without specified intent. Since it is prohibited to modify the dummy argument, we treat it as if intent(in) were specified and suppress copying back of the pointer address. PR fortran/118179 gcc/fortran/ChangeLog: * trans-expr.cc (conv_null_actual): Suppress copying back of pointer address for unspecified intent. gcc/testsuite/ChangeLog: * gfortran.dg/null_actual_7.f90: Extend testcase to also cover scalar variants with pointer or allocatable dummy with or without specified intent. --- gcc/fortran/trans-expr.cc | 3 +- gcc/testsuite/gfortran.dg/null_actual_7.f90 | 77 + 2 files changed, 79 insertions(+), 1 deletion(-) diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index 9aedecb9780..4b022989e6f 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -6488,7 +6488,8 @@ conv_null_actual (gfc_se * parmse, gfc_expr * e, gfc_symbol * fsym) int dummy_rank; tree tmp = parmse->expr; - if (fsym->attr.allocatable && fsym->attr.intent == INTENT_UNKNOWN) + if ((fsym->attr.allocatable || fsym->attr.pointer) + && fsym->attr.intent == INTENT_UNKNOWN) fsym->attr.intent = INTENT_IN; tmp = gfc_conv_scalar_to_descriptor (parmse, tmp, fsym->attr); dummy_rank = fsym->as ? fsym->as->rank : 0; diff --git a/gcc/testsuite/gfortran.dg/null_actual_7.f90 b/gcc/testsuite/gfortran.dg/null_actual_7.f90 index ba3cd10f21b..8891a3620ce 100644 --- a/gcc/testsuite/gfortran.dg/null_actual_7.f90 +++ b/gcc/testsuite/gfortran.dg/null_actual_7.f90 @@ -10,6 +10,8 @@ program null_actual end type t type(t), pointer :: p2(:,:) => NULL() type(t), allocatable :: a2(:,:) + type(t), pointer :: p0 => NULL () + type(t), allocatable :: a0 ! Basic tests passing unallocated allocatable / disassociated pointer stop_base = 0 @@ -27,6 +29,16 @@ program null_actual call chk2_t_p (p2) call opt2_t_a (a2) call opt2_t_p (p2) + ! ... to rank-0 dummy: + stop_base = 60 + call chk0_t_a (a0) + call chk0_t_p (p0) + call opt0_t_a (a0) + call opt0_t_p (p0) + call chk0_t_a_i (a0) + call chk0_t_p_i (p0) + call opt0_t_a_i (a0) + call opt0_t_p_i (p0) ! Test NULL with MOLD argument stop_base = 20 @@ -43,6 +55,16 @@ program null_actual call opt2_t_a (null(a2)) call opt2_t_p (null(p2)) + stop_base = 80 + call chk0_t_a (null(a0)) + call chk0_t_p (null(p0)) + call opt0_t_a (null(a0)) + call opt0_t_p (null(p0)) + call chk0_t_a_i (null(a0)) + call chk0_t_p_i (null(p0)) + call opt0_t_a_i (null(a0)) + call opt0_t_p_i (null(p0)) + ! Test NULL without MOLD argument stop_base = 40 call chk2_t_a (null()) @@ -50,6 +72,16 @@ program null_actual call opt2_t_a (null()) call opt2_t_p (null()) + stop_base = 100 + call chk0_t_a (null()) + call chk0_t_p (null()) + call opt0_t_a (null()) + call opt0_t_p (null()) + call chk0_t_a_i (null()) + call chk0_t_p_i (null()) + call opt0_t_a_i (null()) + call opt0_t_p_i (null()) + contains ! Check assumed-rank dummy: subroutine chk_t_a (x) @@ -120,4 +152,49 @@ contains if (.not. present (x)) stop stop_base + 19 if (associated (x))stop stop_base + 20 end subroutine opt2_t_p + + ! Checks for rank-0 dummy: + subroutine chk0_t_p (x) +type(t), pointer :: x +if (associated (x)) stop stop_base + 1 + end subroutine chk0_t_p + + subroutine chk0_t_p_i (x) +type(t), pointer, intent(in) :: x +if (associated (x)) stop stop_base + 2 + end subroutine chk0_t_p_i + + subroutine opt0_t_p (x) +type(t), pointer, optional :: x +if (.not. present (x)) stop stop_base + 3 +if (associated (x))stop stop_base + 4 + end subroutine opt0_t_p + + subroutine opt0_t_p_i (x) +type(t), pointer, optional, intent(in) :: x +if (.not. present (x)) stop stop_base + 5 +if (associated (x))stop stop_base + 6 + end subroutine opt0_t_p_i + + subroutine chk0_t_a (x) +type(t), allocatable :: x +if (allocated (x)) stop stop_base + 7 + end subroutine chk0_t_a + + subroutine chk0_t_a_i (x) +type(t), allocatable, intent(in) :: x +if (allocated (x)) stop stop_base + 8 + end subroutine chk0_t_a_i + + subroutine opt0_t_a (x) +type(t), allocatable, optional :: x +if (.not. present (x)) stop stop_bas
Re: [PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer dummy [PR118179]
Am 23.12.24 um 18:51 schrieb Jerry D: On 12/23/24 9:19 AM, Harald Anlauf wrote: Dear all, while preparing the testcase null_actual_7.f90 for commit r15-6408, I overlooked a corner case, leading to a regression (PR118179). The obvious solution is to extend the suppression of copying back the pointer also for NULL actual arguments to pointer dummies with no specified intent. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald OK, and thanks for the fix. Thanks, Jerry, for the incredibly fast review! Pushed: r15-6426 I'll leave the PR open to see if Jürgen can confirm that I did not miss another corner case... Cheers, Harald Jerry
Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args
Hi PA,
(next try, for some reasons, my original email disappeared.)
Paul-Antoine Arras wrote:
Replying to your last two messages here and attaching revised patches.
Regarding the C++ and ME patches:
==> 0003-C-fix.patch <==
Subject: [PATCH 3/4] C++ fix
==> 0004-ME-fixes.patch <==
Subject: [PATCH 4/4] ME fixes
I think it is best to fold them into the Fortran patch; otherwise, they
would clearly need a better subject line.
And for both changes and in either case, both need a ChangeLog entry.
Additionally, the middle-end patch does not apply as it doesn't honor my
Dec 18 change to gimplify.cc.
* * *
==> 0001-OpenMP-Fortran-front-end-support-for-dispatch-adjust.patch <==
Subject: [PATCH 1/4] OpenMP: Fortran front-end support for dispatch +
adjust_args
The following two patches do not work (at least with some testsuite
testing) as in gcc/testsuite/ neither omp_lib nor libgomp.{so,a} is
available.
For gcc/testsuite/gfortran.dg/gomp/adjust-args-10.f90, you can just
remove the 'omp_lib'.
And as gcc/testsuite/gfortran.dg/gomp/declare-variant-21.f90 contains !
{ dg-do run }
... I'd suggest to move it to libgomp (including its aux-21.f90 file).
For adjust-args-10.f90, I wonder whether it is sufficient as
compile-time only or whether it makes more sense to have a "dg-do run"
to check that type(C_ptr) value vs. not-value works. I think either is
fine, but if it stays in gcc/, can you manually run it once to re-check
that it works? (I think I did check it and it worked.)
* * *
Note that gcc/testsuite/gfortran.dg/gomp/adjust-args-9.f90 and
...-10.f90 are missing a ChangeLog entry.
Likewise for dispatch-9a.f90.
BTW: If you have applied (committed) the patch locally, run
./contrib/gcc-changelog/git_check_commit.py -v -p — the '-v' will output
new files that have not been listed as warning and -p shows the patch
log for checking it. Additionally, it has the usual "git push" checks of
GCC.
* * *
Otherwise, LGTM. Thanks!
[As gimplify.cc couldn't be applied, I have not played with the patch
but I believe that it should be okay, based on past playing and looking
at the patch.]
Tobias
PS: Besides fixing the minor issues above, I think you have a
follow-up/cleanup patch available addressing some issues related to the
C/C++ FE, including where the '#pragma' is handled etc. I am looking
forward to that follow-up patch as well :-)
[COMMITTED] libgfortran: Fix build for targets with int32_t=long int
Not many newlib targets (IIRC the only targets where
int32_t is a typedef of long int) build libgfortran.
Building and testing fortran testsuite is usually a cheap
way to get additional coverage for a port, except that a
couple of times a year, there are these silly type-related
breakages.
Maybe change to building libgfortran as C++? 1/2 :-)
Committed as obvious after a build of libgfortran for
cris-elf succeeded with this patch.
-- >8 --
Without this, after r15-6415-g586477d67bf2e3, you'll see,
for targets where int32_t is a typedef of long int (beware
of artificially broken lines):
/x/gcc/libgfortran/caf/single.c: In function '_gfortran_caf_get_by_ct':
/x/gcc/libgfortran/caf/single.c:2943:56: error: passing argument 2 of '\
(accessor_hash_table + (sizetype)((unsigned int)getter_index * 12))->ac\
cessor' from incompatible pointer type [-Wincompatible-pointer-types]
2943 | accessor_hash_table[getter_index].accessor (dst_ptr, &free_bu\
ffer, src_ptr,
|^~~~\
||
|int *
/x/gcc/libgfortran/caf/single.c:2943:56: note: expected 'int32_t *' {ak\
a 'long int *'} but argument is of type 'int *'
libgfortran:
* caf/single.c (_gfortran_caf_get_by_ct): Correct type of free_buffer
to int32_t.
---
libgfortran/caf/single.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
index f5414ff1f7ef..23ad44e1c162 100644
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -2927,7 +2927,7 @@ _gfortran_caf_get_by_ct (
{
caf_single_token_t single_token = TOKEN (token);
void *src_ptr = opt_src_desc ? (void *) opt_src_desc : single_token->memptr;
- int free_buffer;
+ int32_t free_buffer;
void *dst_ptr = opt_dst_desc ? (void *)opt_dst_desc : dst_data;
void *old_dst_data_ptr = NULL;
--
2.30.2
